Making the First Screen Appear Sooner

The only part that has to be fast

A visitor forms a judgement from what fills the top of the window in the first second or two.

Whether the rest of the page took four seconds or eleven is largely invisible to them, because they were reading the top of it while the remainder arrived.

This is the most useful reframing available in performance work, because it turns an impossible goal, making everything fast, into a manageable one: making a specific small part fast and letting the rest follow.

What counts as the first screen

What is visible without scrolling, which is smaller than people expect on a phone.

Typically a logo, a headline, perhaps a line of supporting text, one image, and a way to make contact.

That is a handful of elements and a small amount of data. There is no technical reason it cannot appear almost immediately.

When it does not, it is nearly always because it is queued behind something that belongs further down, or behind something nobody looks at at all.

The largest thing in the first screen

Google's loading measurement watches specifically for the largest element in the visible area, which on most business sites is a banner image or a headline.

That focus is sensible: the biggest visible thing is what makes a page look present rather than half-built.

So a practical target is to identify that element and make sure nothing unnecessary sits in front of it.

A common failure is a banner image that is both very large and loaded after four scripts, which makes the single most important pixel on the page the last thing to arrive.

Do not lazy-load the top of the page

A specific mistake worth naming, because it comes from applying good advice indiscriminately.

Deferring images until they are needed is excellent for everything below the visible area.

Applied to the banner image, it does the opposite of what is wanted: the browser deliberately waits before requesting the one image that determines how quickly the page looks finished.

Plugins that lazy-load every image on a site do this by default, and it is a common reason a performance change made things measurably worse.

Exclude the first screen. Most tools have a setting for skipping the first image or two, and it should be used.

What to defer

• Images below the visible area, loaded as they approach.
• Embedded maps and video players, until clicked.
• Chat widgets, which almost never need to be immediate.
• Social feeds and review widgets.
• Analytics and tracking, which can run afterwards.
• Anything in the footer.

None of these affects what the visitor sees in the first two seconds, and collectively they are usually most of a page's weight.

Ask for the important things early

The other half of the job, and the one people skip.

Deferring the unimportant helps. Explicitly prioritising the important helps as well, and the two together are more than either alone.

A browser can be told to fetch a specific file early, before it would otherwise discover it, which is useful for a banner image referenced in a stylesheet rather than in the page, or for a web font needed by the headline.

Use it sparingly. Marking many things as high priority is the same as marking none, since everything then competes and the browser's own ordering was probably better.

One or two per page, aimed at the largest visible element and the font it uses, is the useful application.

A worked example

A hotel had a homepage whose banner photograph took about six seconds to appear on a throttled mobile connection, leaving a grey block above the headline.

Three things were happening at once.

The image was four thousand pixels wide, being displayed at under eight hundred. It was being lazy-loaded, because a plugin had applied that to every image. And it was referenced in the stylesheet, so the browser did not learn it existed until the stylesheet had been parsed.

They resized it, excluded the first screen from lazy loading, and preloaded it explicitly.

It began appearing in just over one second.

Total page weight fell by about a fifth, almost all from the resize, and the perceived difference was far larger than that figure suggests, because the change was concentrated on the part people look at.

Order the code as well as the content

A smaller point that compounds with the rest.

Styles needed for the visible area can be placed directly in the page, so the browser has them without fetching a separate file, with the remainder loaded afterwards.

This is standard practice on fast sites and is available as a setting in most performance plugins, described as inlining critical styles or something similar.

It is worth checking before treating it as developer work, and worth testing carefully afterwards, since an incomplete extraction produces a briefly unstyled page that looks worse than a slower one.

Measure the right moment

The number to watch is when the largest visible element appeared, not when loading finished.

Browser tools report this directly, and it is the figure that corresponds to what a visitor experiences.

Watching total load time leads to effort spent on things below the fold that nobody was waiting for, which is how sites end up meaningfully lighter and no faster to use.

Record the load on a throttled connection and note the second at which the page looks present. That is the number to improve.

The counter-case

Deferring aggressively has costs and they show up in specific places.

Images that load as they approach can arrive visibly late for somebody scrolling quickly, producing a page that assembles itself just ahead of the reader, which some people find worse than waiting.

Anything deferred is also invisible until it loads, so content that matters to a search engine or a reader who scans quickly should not be pushed too far back.

And on a genuinely small site, none of this is necessary. A page with three images and no widgets does not need a priority strategy, and adding plugins to manage loading on a site that already loads in two seconds adds complexity in exchange for nothing.

The approach

1. Identify the largest element in the first screen.
2. Resize it properly for the space it occupies.
3. Exclude it from lazy loading.
4. Preload it if it is referenced in a stylesheet.
5. Defer everything below the fold, including widgets.
6. Time when the page looks present, not when it finishes.

Steps two and three between them fix most homepages, and neither requires a developer.

What arrives first is covered in what loads first and why it matters.

Frequently asked questions

West Coast Media Solutions Inc. provides web design, web development, hosting, digital marketing, and business consulting to organisations across Canada, drawing on more than twenty-five years in the field.