The cheapest performance win nobody ships
Most sites lose more time to one unoptimized hero image than to any JS framework choice.
On most marketing sites, the single largest performance problem is one image. The hero sits at the top of the page, so it is almost always the Largest Contentful Paint element, and it is almost always shipped as a full-resolution JPEG or PNG with no responsive variants, no explicit dimensions, and no priority hint. Fixing it takes under an hour: convert to WebP or AVIF, generate a srcset so a 360px phone downloads a 360px file, set width and height so the browser reserves the space, add fetchpriority="high", and preload it. That sequence routinely removes more load time than a month of framework tuning, costs a fraction as much, and does not require anybody to agree on an architecture. It is the cheapest thing on the bill and it is still the thing most teams ship last.
Why is the hero image always the problem?
Because nothing else on a typical page has the same combination of size, position and priority. It is large by design, it is above the fold by definition, and it is usually the one asset handed over by someone outside the engineering team — a designer exporting at 2× for retina, or a client uploading straight from a phone camera through the CMS.
The result is predictable. We audited the images across our own site recently and found 32 files over 100 KB, the largest a single JPEG at 868 KB, with zero WebP and zero srcset anywhere. That is not an unusual state for a site that has been maintained carefully in every other respect. Image weight is the failure mode that survives good engineering, because it enters through a door engineering does not guard.
What does the fix actually look like?
In order, because the order matters:
Serve the right format. WebP is supported everywhere that matters and typically lands 25–35% smaller than an equivalent-quality JPEG. AVIF goes further again at the cost of slower encoding. Use <picture> with a JPEG fallback if you support anything unusual.
Serve the right size. This is the bigger mobile win and the one most often skipped. Without srcset, a phone downloads the desktop asset in full — the same 1200×800 file the 27-inch monitor gets. Generating three or four widths and letting the browser choose is a build-step change, not a redesign.
Reserve the space. Explicit width and height attributes let the browser compute the aspect ratio before the bytes arrive, which is what stops the page jumping as it loads. CSS still controls the rendered size; the attributes exist purely to prevent the shift.
Prioritise it. Mark the hero fetchpriority="high" and preload it. Equally important: do not mark it loading="lazy". Lazy-loading the LCP element is a common own goal — the attribute is correct for everything below the fold and actively harmful on the one image above it.
What do you measure, and in what order?
On every project we benchmark four numbers before touching anything: LCP, CLS, INP and TTFB. The order we attack them is almost always the same — image weight first, then late-loading JavaScript, then layout shift, then server latency — because that sequence runs from cheapest to most invasive, and because each step changes the measurement of the ones after it.
Server latency comes last for a reason. A 1-second TTFB on a static file is worth fixing, but it is usually a hosting or caching decision rather than a code one, and it is pointless to negotiate a CDN contract while the page is still shipping four megabytes of images. Get the payload right and you often discover the server was never the constraint.
Does any of this survive the next six months?
Only if it is enforced somewhere. An optimised hero is one deploy away from being replaced by a 4 MB upload through the CMS, and the person who does it will have no idea they undid a week of work.
Two things make it stick. First, an automated image pipeline — conversion, resizing and srcset generation at build time — so correctness is the default rather than a discipline. Second, a page-weight budget checked before release, with a number rather than a feeling attached to it. If a change pushes a page past the ceiling, that is a conversation before launch instead of a mystery three months later.
Where does this sit against everything else?
It is the highest ratio of outcome to effort in front-end work, which is exactly why it is unsatisfying to put on a roadmap. There is no architecture decision to defend and nothing to announce. There is just a page that paints in under two seconds instead of five, on the connection most of your audience is actually using.
If you want the fuller picture — the thresholds, what INP really measures, and how to keep the numbers from drifting — that is the Core Web Vitals post. If you want it done rather than explained, it lives inside our front-end development and web development work, and it is part of the technical groundwork in any SEO engagement.