The payload nobody audits
Images are typically the largest thing a page downloads and the least examined. A single hero photograph exported at full camera resolution can outweigh every other asset on the page combined, and nobody notices because it looks fine.
Resize once, not per request
The common fix is a service that transforms images on demand at the URL. It works, and it introduces a per-request cost, a third-party dependency in your critical path, and a bill that scales with traffic. Generating the sizes once at build or upload and serving them as static files avoids all three.
Pay to resize an image once. Paying to resize it on every request is a subscription to a solved problem.
Snap to a ladder of widths
Rather than a bespoke size per layout, pick a small set of widths and round every image up to the nearest one. A handful of variants covers every breakpoint, keeps the cache hit rate high, and makes the whole thing predictable.
Always set dimensions
Width and height attributes let the browser reserve space before the image arrives. Without them the page reflows as images load, which users experience as slowness even when the measured load time is good.
Load below-the-fold images lazily — and only those
Lazy-loading everything including the hero image delays the largest paint and makes the number worse. Eager for what is visible, lazy for what isn’t; this is one of the few decisions that meaningfully moves what actually makes a site fast.
Then ask whether the image earns its place
Stock photography of people at laptops adds weight and communicates nothing. The fastest image is the one you deleted, and a page that says something specific rarely needs decoration to hold attention — the argument behind a confident page outconverting a comprehensive one.