Lazy loading defers images until a visitor scrolls near them. Applying it to the first image on screen delays the very thing being measured, so exclude anything visible without scrolling.

A good technique, misapplied

Lazy loading tells the browser not to fetch an image until the visitor is close to scrolling it into view.

On a page with twenty photographs, that is a substantial saving: the visitor downloads three instead of twenty, and the rest arrive only if they are needed.

It is one of the better improvements available and most platforms now apply it automatically.

The problem is that automatic application is usually blanket, and the one image it should never apply to is the first one on screen.

Why the top image is different

Because it is the thing being measured.

The measurement of how quickly a page becomes useful looks at when the largest piece of content in the visible area appears, and on most business sites that is the main image at the top.

Lazy loading deliberately delays fetching an image until the browser has worked out that it is needed.

Applied to the top image, that inserts a delay into the exact moment the measurement is watching.

So a technique that improves the page overall makes the headline number worse, which is why this shows up as an unexplained regression after somebody enables an optimisation plugin.

How it happens

The fourth is common and doubly costly, since a slider frequently defers its first slide and also waits for a script before showing anything at all.

What to defer and what not to

The rule is simple once stated.

Anything visible without scrolling should load normally: the main banner, a logo, a product's main photograph.

Everything below that point should be lazy loaded, which on a long page is nearly all of the images.

Since what is visible without scrolling differs between a phone and a desktop, err toward loading the first one or two images normally.

Most optimisation plugins have a setting for this, usually described as skipping the first image or excluding above-the-fold images, and it is off by default more often than not.

Tell the browser it is coming

The step beyond simply not deferring it.

A preload instruction tells the browser to begin fetching a specific image immediately, before it has finished reading the rest of the page.

For the main image at the top, that can start the download noticeably earlier, particularly where the image is referenced from a stylesheet rather than directly in the page.

It is one line, and it should be used sparingly: preloading several things competes for the same connection and makes everything slower.

One image, the one being measured, is the correct amount.

A worked example

A business installed an optimisation plugin and their measurement for how quickly the main content appeared got worse rather than better.

Everything else improved: fewer requests, less transferred, a better test score overall.

The plugin had applied lazy loading to every image including the homepage banner, which was the largest visible element and therefore the thing being timed.

The banner was now being fetched later than before, so the page took longer to look finished even though it was doing less work.

They enabled the plugin's setting to skip the first image and added a preload instruction for the banner.

The measurement improved past where it had started, and everything the plugin had gained elsewhere was kept.

The plugin had not been wrong. The blanket setting had been.

Reserve the space either way

A related point, since the two problems usually appear together.

An image without width and height specified has no reserved space, so the page lays out without it and rearranges when it arrives.

That is the layout shift measurement, and lazy loading makes it worse by delaying the arrival.

Specifying dimensions on every image, including lazy loaded ones, means the space is held from the start and nothing moves.

Most platforms do this automatically for uploaded images and not for images placed by a page builder or written into content by hand.

It costs nothing and it is the cheapest fix available for the stability measurement.

Check what your plugin is doing

Since most of this is decided by a setting rather than by anybody's intention.

View the page source and look at the first image in the markup, checking whether it carries a lazy loading attribute.

If it does, that is the problem, and the fix is a setting rather than a code change.

Check on a phone-sized view as well, since what counts as the top image differs by screen.

And recheck after any plugin update, since these settings occasionally reset or gain new defaults.

The sizes actually being sent

Worth checking at the same time, since the two settings live in the same plugin and solve different halves of the problem.

Deferring an image controls when it is fetched. It does nothing about how large the file is when it arrives.

A banner sent at full desktop width to a phone is downloading several times the pixels the screen can display, and lazy loading it merely delays that.

Modern platforms generate several sizes of each uploaded image and let the browser choose, and images placed by a page builder or written into content by hand frequently bypass that entirely.

Check what is actually being delivered on a phone view, since a correctly deferred oversized image is still an oversized image.

The counter-case

Lazy loading itself is worth having and should not be abandoned over this.

Turning it off entirely to avoid the top-image problem gives back a real saving on every long page, which is a poor trade for fixing one image.

Preloading is also easy to overdo: preloading four images, a font, and a script means everything competes and nothing arrives sooner.

And on a text-heavy page with no large image at the top, the largest visible element may be a block of text, in which case none of this applies and fonts matter more.

Keep lazy loading, exclude the first image, preload that one, and leave the rest alone.

The check

  1. View source and find the first image.
  2. Check whether it is marked for lazy loading.
  3. Enable the skip-first setting in your plugin.
  4. Preload that one image, and only that one.
  5. Specify width and height on every image.
  6. Check the phone view separately.
  7. Recheck after plugin updates.

Step three is usually the whole fix, and it is a checkbox that is off by default in most optimisation plugins.

Getting the files themselves right is covered in images uploaded at camera resolution.


Frequently asked questions

What does lazy loading do?

It tells the browser not to fetch an image until the visitor is close to scrolling it into view, so a page with twenty photographs downloads three instead.

Why is the top image a problem?

Because the measurement of how quickly a page becomes useful watches when the largest visible element appears, which is usually that image. Deferring it delays exactly what is being timed.

How does it happen?

A plugin, theme setting, or platform default applying it to every image, or a slider deferring its first slide while also waiting for a script.

What should I defer?

Everything below the point visible without scrolling, which on a long page is nearly all the images. Load the first one or two normally, since screens differ.

Should I preload the top image?

Yes, and only that one. Preloading several things makes them compete for the same connection and everything arrives later.

Should I specify image dimensions?

Always. Without them the page lays out and then rearranges when the image arrives, which is the layout shift measurement, and lazy loading makes it worse.

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.

Installed an optimisation plugin and the score got worse?

View source and check whether your banner image is marked for lazy loading. That one setting explains it.

Start a Conversation