Modern Image Optimization for the Web
Images are almost always the heaviest chunk on a web page — often more than half of the total page weight. That’s exactly why they’re the biggest single lever for load time and Core Web Vitals. A poorly optimised hero graphic can ruin the Largest Contentful Paint; an image with no reserved space makes the layout jump and drives up CLS. Whoever has images under control has half the performance battle won.
Modern image optimization isn’t a single trick but a bundle of interacting measures: the right format, the right size per device, the right loading behaviour, and reserved space in the layout. This article walks through all four — and shows the traps that do more harm than good.
The formats: AVIF and WebP beat JPEG/PNG
The old standards — JPEG for photos, PNG for graphics with transparency — are universally supported but inefficient. The modern formats compress much better:
- WebP is about 25–35% smaller than JPEG at comparable quality and is supported practically everywhere today (over 97% of browsers, as of early 2026). The safe default.
- AVIF goes further: up to about 50% smaller than JPEG, with better quality especially at low bitrates. Support sits at around 92% (early 2026) — good, but not quite universal.
The clean strategy: serve AVIF as the best option, with WebP (and JPEG as a last resort) as fallback for browsers that can’t do AVIF. That’s exactly what the <picture> element is for. More on the formats in the glossary under Image Optimization with WebP/AVIF.
Responsive images: the right size per device
Sending a 2000-pixel image to a 400-pixel smartphone display wastes bandwidth massively. Responsive images solve this by offering the browser several sizes and letting it choose the right one.
srcsetandsizes. Withsrcsetyou provide several resolutions of the same image; withsizesyou tell the browser how wide the image will be displayed in the layout. The browser then picks the smallest variant that’s still sharp enough — depending on display size and pixel density.<picture>element. For art direction (a different image crop per viewport) or for format fallback (AVIF → WebP → JPEG). Here you define explicit<source>alternatives that the browser checks in order.
Rule of thumb: srcset/sizes for „the same image in different sizes”, <picture> for „different images or formats”.
Lazy-loading — but not on the LCP image
loading="lazy" tells the browser to load an image only when it scrolls near the visible area. This saves bandwidth and speeds up the initial page build, because the browser focuses first on the critical elements. Native browser support sits at around 95% in 2026.
The crucial trap: never lazy-load the LCP image. Lazy-loading on the hero graphic, the logo or the above-the-fold image delays exactly the element that determines the LCP — the browser discovers it late and loads it late. Measurement data shows the effect dramatically: lazy-loading the LCP image shifted the LCP value (75th percentile) from 364 ms to 720 ms and pushed the share of „good” pages from 79% down to 52%.
For the LCP image the opposite applies: no lazy, but often fetchpriority="high" so it loads as early as possible. Lazy-loading belongs on the images below the fold, not on the most important image at the top. More on the mechanism in the glossary under Lazy Loading.
width/height against layout shift
An image without specified dimensions is a classic CLS culprit: the browser doesn’t know how much space it will need, renders the surrounding text — and then pushes everything down once the image loads. That’s the jarring jump everyone knows.
The solution is in every web.dev recommendation: always set width and height on images. Modern browsers compute the aspect ratio from them automatically and reserve the correct space before the image loads. For responsive layouts you combine the HTML width/height attributes with CSS width: 100%; height: auto; — the browser keeps the ratio and computes the height proportionally. Important with srcset: all variants should use the same aspect ratio, otherwise the layout shifts when switching. The lexikon entry Eliminate Cumulative Layout Shift goes deeper.
Compression and tooling
Beyond format and size, the quality level matters: for web photos a quality of 75–85% is usually enough, the difference from the original is barely visible but the savings are large. Doing all this by hand doesn’t scale — modern build tools and frameworks generate the formats, sizes and srcset attributes automatically at build time, and image CDNs deliver images optimised per device. The clean way is to put this optimization into the pipeline rather than handling it per image manually.
FAQ
Should I use AVIF or WebP?
Best both: AVIF as first choice (best compression) with WebP as fallback via the <picture> element. WebP is near-universally supported (over 97%), AVIF a bit less (around 92%, early 2026) but compresses even harder. Both clearly beat JPEG and PNG.
What’s the difference between srcset and the picture element?
srcset/sizes serves the same image in different sizes, and the browser picks the right one for display and pixel density. You use the <picture> element when you want to show a different image per viewport (art direction) or need format fallbacks like AVIF → WebP → JPEG.
Why must I not lazy-load the LCP image?
Because lazy-loading delays loading — and the LCP image is precisely the element that determines the Largest Contentful Paint. Lazy-loading it delays the LCP measurably (in one analysis from 364 to 720 ms). Above-the-fold images you load eagerly, often with fetchpriority="high"; lazy belongs on images below the fold.
How do I prevent images from making the layout jump?
Always set width and height on every image. The browser computes the aspect ratio from them and reserves the space before the image loads — no jump. For responsive images you combine the attributes with CSS height: auto; width: 100%.
How strongly does image optimization affect Core Web Vitals? Very strongly. Images often make up the largest part of page weight, so optimising them is one of the most effective LCP levers — format, size and delivery together can cut page weight by 50–70%. Correct dimensions additionally prevent CLS. Two of the three Core Web Vitals hang directly on images.
Entdecke mehr
Reducing Supabase Egress: How We Found the Root Cause After Two DB Moves
Every tiny edit pushed hundreds of kilobytes through the wire. After two full database moves, we finally treated the architecture instead of the symptoms.
LexikonRendering Strategies for Fast Websites
Static, SSR, ISR, edge rendering and hydration from a dev angle: what each strategy means for TTFB, LCP, and maintainability — and when each fits.
BlogThe Editor Won't Save — And the Limit Is on the Read Side, Not the Write
A growing JSONB blob froze our editor. The suspect was harmless, the real cause counterintuitive: reading failed, not saving. A debugging detective story.