Nature Images journal
The image that made the page slow
A single hero photograph is usually the whole performance problem, and usually for one of four reasons.
Almost every slow image-heavy page is slow for one of four reasons. None of them are subtle, and all four are usually present at once.
One: the original was uploaded
A six-thousand-pixel photograph rendered into a four-hundred-pixel card is roughly two hundred times more data than the layout needs.
This is by far the commonest cause and it is the easiest to fix. Resize to the widths you actually display, generate three or four of them, and let the browser choose with srcset and sizes.
The tell is a page that is fast on a desktop connection and unusable on a phone. Mobile users are getting the same enormous files over a worse connection.
Two: no dimensions
Without width and height attributes, or an aspect-ratio in CSS, the browser cannot reserve space before the image arrives. Every picture that loads shoves the content below it downward.
That shove is measured directly by Cumulative Layout Shift, and it is the failure users complain about without being able to describe: they go to tap something and it moves.
Two attributes fix it permanently.
Three: the hero is lazy-loaded
Someone adds loading="lazy" to every image on the site, which is correct for everything except the one that decides the score.
The hero is almost always the Largest Contentful Paint element. Lazy-loading it delays exactly the thing being measured, which is why the page feels slower after an optimisation pass than before it.
The hero gets eager loading and, ideally, fetchpriority="high". Everything below the fold gets lazy.
Four: JPEG everywhere
WebP is supported by every browser in current use and is typically 25 to 35 per cent smaller at matched quality. AVIF is smaller again.
Serve them through a picture element with a JPEG fallback and the whole page gets a third lighter for an afternoon of work.
Tuning the quality setting
One nature-specific note. Compression quality should be tuned against the smoothest region of the frame, not the busiest.
Sky and water gradients band at settings where foliage still looks perfect. If a frame is mostly sky, go higher than you think; if it is mostly forest, you can go considerably lower than you would guess and nobody will see it.
Measure the first load
Test in a private window, on a throttled connection, with the cache empty. A second load tells you nothing about a first visitor, and a first visitor is who you are optimising for.