Why the top of the page is where speed work starts
The big image at the top of a page decides how fast a site feels. Here is how we got it on screen twice as fast, and the mistake we made along the way.
6 min read
Earlier this year I worked with an agency team on the website of a national tourism organisation. It serves visitors in more than 20 countries, and most of them arrive on a phone. The first thing each of them sees is the hero: the large image and headline across the top of the page, the bit that's meant to make someone want to book a trip.
On mobile, that hero was taking up to four seconds to appear. That matters more than it sounds. Google judges how fast a page loads largely by when its biggest visible element shows up, and on almost every page of this site, that was the hero. A slow hero meant a slow site in Google's eyes, and an impatient visitor in real life.
We were asked to fix it without changing how anything looked. Here's how we did it, and what it taught me about where speed work should start.
The biggest picture was waiting for everything else
When we traced what the hero was waiting for, the answer was: everything. The site hid every section of the page until the code behind it had downloaded and started up. The hero image often arrived early, but it stayed hidden until the rest of the site was ready.
It was like a shop with its shelves fully stocked but the shutters kept down until every till had been switched on. On top of that, the image was requested late and at normal priority. In some places a full-size original photo was sent where a smaller version would have looked identical. And other start-up jobs, like working out the visitor's location and loading analytics, all ran before anything appeared.
[IMAGE: two simple loading timelines, one above the other. Before: download code, run start-up jobs, then show the hero. After: show the hero first, with code and start-up jobs running behind it — alt text: Two timelines comparing a hero that waits for all the code with one that appears first]
Five changes, one goal: draw the hero first
None of what we did was exotic. It came down to putting the hero at the front of the queue and getting everything else out of its way.
Let the hero show itself. We exempted the hero from the hide-until-ready rule, so it appears as soon as the page arrives instead of waiting for the code.
Send its styling with the page. The instructions that control how the hero looks now travel inside the page itself, rather than in a separate file the browser has to fetch first.
Fetch its image first. We told the browser this one image is top priority and had it connect to the image server early. Only the first visible image gets this treatment; the rest wait their turn.
Reserve its space. The browser now knows the exact size of the hero before the image arrives (taller on phones, wider on bigger screens), so nothing below it gets pushed down.
Move everything else out of the way. The location lookup, analytics and video player now wait until the page has appeared, and every image is sized to the screen it's shown on.
One hero at a time, and one mistake along the way
"The hero" turned out to be many heroes. The site had a different design for the homepage, destinations, attractions, campaigns, travel advice, video-led pages and more. Each one was built differently, so each needed checking on its own.
In the first release we covered the twelve types we could change safely. A few we deliberately held back. Some intro sections had a "read more" panel that only folded itself shut once the code had loaded. Showing those early would have meant the page visibly jumping as they closed. On pages that relied on them, test scores even fell by comparison: one destination page dropped from 67 to 42.
Then real-visitor data showed us a mistake. On several destination pages, the content had started moving as it loaded. On Google's stability scale, under 0.1 is good. These pages had been at or near zero, and they were now scoring between 0.25 and 0.34. We had made one type of header appear early before reserving the right amount of space for its picture. Before our change the code had hidden that jump; now visitors could see it.
The second release did the groundwork first. The "read more" panels start closed from the moment the page appears, the header pictures have their correct space reserved, and the remaining six hero types were brought into line. The jumping pages went back to zero.
Whatever a visitor sees first should be the first thing the page is allowed to draw.
What it added up to
On the UK homepage, the hero now appears in 1.6 seconds on mobile, down from 3.9, and the page holds still while it loads. Every homepage we tracked now passes Google's mobile thresholds for both speed and stability. One campaign page's test score went from 11 to 61 out of 100. And nothing about the design changed: visitors simply see the page sooner.
What I do differently now
I start with the top of the page. Before optimising anything else, I find the largest thing on the first screen and trace exactly what it's waiting for.
I list every hero type before touching one. Then I roll changes out in batches, starting with the ones that are safe to change, so no page is made worse while others get better.
Nothing appears early until its final shape is known. Reserving space and settling the layout are part of the same change, not a follow-up.
I judge results by hero type, not by page address. Two pages of the same kind behaved in opposite ways depending on what sat at the top.
If you'd like the technical detail behind each of these changes, it's all in the full case study: [LINK: Core Web Vitals Case Study: 2x Faster Tourism Site].