Images are still the biggest single contributor to page weight on most websites, which makes image optimization one of the highest-leverage, lowest-risk changes a team can make to page speed. What's changed by 2026 isn't the underlying principle — compress images well, size them appropriately, load them smartly — it's the specifics of which format and technique deliver the best result, and those specifics have shifted meaningfully in the last couple of years.
Format choice: AVIF vs WebP vs JPEG
The format landscape has stabilized into a clear hierarchy, even if adoption hasn't fully caught up to what the compression numbers suggest it should be. AVIF delivers meaningfully better compression than WebP — roughly 50% smaller file sizes at equivalent visual quality — and 40–60% smaller than JPEG while preserving comparable or better detail. In practical terms, an AVIF image at quality 60–70 typically looks as good as a JPEG at quality 85, which is a real, usable file size win once you're serving images at any meaningful scale.
Browser support is no longer the blocker it once was: WebP sits at about 96.4% global browser support and AVIF at about 94.9% as of early 2026 — both comfortably past the threshold where you can serve either as a primary format with a fallback for the small remaining slice of older browsers. Despite AVIF's compression advantage, actual adoption across the web remains modest — it's grown roughly 386% over two years but still accounts for only about 1% of web images, up from a negligible 0.25% in 2022. That gap between "clearly the better format" and "actual usage" is mostly inertia: WebP tooling and workflows got broad adoption first, and many sites haven't revisited the decision since.
The practical recommendation Google and most performance guides converge on: serve AVIF first, WebP as the fallback, and JPEG as the last-resort safety net for anything ancient enough to support neither. Modern image tags and CDN image services handle this negotiation automatically via the <picture> element or Accept header content negotiation, so implementing this properly doesn't require maintaining three separate copies of every image by hand — most image CDNs and framework-level image components (Next.js's Image component, Cloudflare Images, Cloudinary, etc.) do this transformation on the fly.
It's not just about format anymore
Format selection is one of four overlapping disciplines that make up real image optimization in 2026, and treating it as the only lever tends to leave a lot of performance on the table:
Responsive variants (srcset and sizes). Serving the same full-resolution image to a phone and a 4K desktop monitor wastes bandwidth on the phone for no visual benefit — the extra pixels are invisible on a smaller viewport. srcset lets the browser choose the appropriately sized variant based on the actual rendered size and device pixel ratio, rather than downloading and then scaling down a much larger file.
Priority signals (fetchpriority and loading). Not every image on a page matters equally for perceived load speed. The largest, most visually prominent image above the fold — often what determines your Largest Contentful Paint (LCP) score — should be marked with fetchpriority="high" so the browser fetches it before less critical images. Conversely, everything below the fold should generally use loading="lazy" so it doesn't compete for bandwidth with content the user can actually see immediately.
Layout reservation (explicit width/height). Missing width and height attributes on an image tag mean the browser doesn't know how much space to reserve for it before it loads, which causes layout shift as the page jumps once the image arrives — a direct hit to Cumulative Layout Shift, one of the Core Web Vitals. This is a near-zero-cost fix (just add the attributes) that's still surprisingly common to see missing.
Getting LCP right specifically
Since the Largest Contentful Paint metric is so often driven by a hero image, it's worth treating that one image differently from the rest of the page's images:
- Don't lazy-load it — lazy loading an LCP-critical image actively delays the metric it's supposed to help.
- Preload it explicitly with a
<link rel="preload">if it's not immediately discoverable by the browser's preload scanner (which can happen if it's set via CSSbackground-imageor loaded via JavaScript rather than a plain<img>tag). - Serve it in AVIF/WebP at the smallest file size that doesn't visibly degrade quality — this is the single image where the format compression gains matter most, since it's directly on the critical path to a measured performance score.
A practical checklist
- Convert your image pipeline to output AVIF with WebP fallback (JPEG as final fallback), rather than sticking with JPEG or PNG defaults.
- Use
srcset/sizesor a framework's built-in responsive image component instead of serving one fixed size to every device. - Add explicit width/height to every image tag to prevent layout shift.
- Lazy-load everything below the fold; never lazy-load your LCP candidate image.
- Preload your LCP image explicitly if it's not a straightforward
<img>tag the browser can discover on its own. - Re-audit periodically — image optimization tooling (CDN transformation services, framework image components) keeps improving, and a pipeline built two years ago is often leaving easy gains on the table today.
None of this requires exotic infrastructure — most of it is available through configuration in whatever CDN or framework a site already uses. The gap between sites that do this well and sites that don't is rarely a tooling gap; it's usually just that nobody revisited the image pipeline since it was first set up, and formats and best practices have moved on since then.
Sources: Elementor: AVIF vs WebP 2026, Logos Web Designs: Image Optimization for Website Speed 2026, ImgCruncher: AVIF vs WebP in 2026
Get new posts as they publish
No spam — just the next post, straight to your inbox.