The State of Web Image Optimization 2026
·44 sites tested
We loaded 44 popular websites in a real headless browser and measured every image's natural (file) size against its rendered (on-screen) size — the same measurement our scanner runs. The picture is consistent with what we see on individual scans every day: oversized images are the norm, not the exception.
Key findings
- 68% of the 44 sites we tested shipped at least one image whose file is 4× or more the area it actually renders at — beyond any reasonable retina (2×) allowance.
- 45% of all measurable images (visible images with known natural dimensions) were oversized by that same bar.
- The median site's worst single image overshot its display size by 15× in area — often the hero or banner, which is frequently the Largest Contentful Paint element.
- Pages carry a median of 58 images, so a handful of oversized ones is easy to miss without a per-image audit — which is why it is worth wiring one into the build to catch oversized images in CI rather than finding them later.
Oversized images by segment
Share of sites in each category that shipped at least one oversized image. Smaller segments (shown with their site count) are indicative only.
Government and media/blog sites fared worst. Both tend to publish image-heavy pages through CMSes that upload at full camera/source resolution and resize only with CSS — the exact pattern that produces oversized images.
Format adoption (by file extension)
Across every image we collected, by the extension in the URL:
Methodology caveat: format is counted by file extension, which undercounts WebP and AVIF served via CDN content negotiation (where the URL has no extension — the "other / extensionless" bucket). Read the modern-format numbers as a floor, not a ceiling. The oversized-image figures, by contrast, are measured directly in the browser and are not subject to this limitation.
Even read generously, legacy JPG and PNG still dominate explicit URLs, and AVIF — the most efficient widely-supported format — is essentially absent from extension-declared images. There is a large, unclaimed bandwidth saving sitting in format choice alone.
When to use each format
Adoption numbers say what sites do, not what they should do. The choice is more settled than the spread above suggests — most images have one obviously correct format, and the decision takes a few seconds once it is framed as a question about content rather than about compression.
| Format | Use it for | Size vs JPG | Watch out for |
|---|---|---|---|
| AVIF | Photographs and gradients, where the saving is largest | About 20% below WebP | Slower to encode; keep a fallback in your picture element |
| WebP | The general-purpose default, for photos and flat colour alike | 25–35% smaller | Lossless WebP is large — use lossy unless you need exactness |
| JPG | Photographs where maximum compatibility still matters | Baseline | No transparency; visible artefacts on text and line art |
| PNG | Screenshots, UI, flat colour, anything needing transparency | Much larger for photos | The most common wrong choice — a PNG photograph is the classic oversized file |
| SVG | Logos, icons, diagrams, anything drawn rather than photographed | Resolution-independent, usually tiny | Not for photographs; sanitise any SVG a user uploaded |
| GIF | Legacy animation only | Far larger than video | 256 colours per frame and no audio — MP4 is better for anything photographic |
The one-line rule: drawn artwork goes to SVG, everything else goes to WebP, and AVIF is worth the extra encode time on large photographs. PNG earns its place when you need transparency or pixel-exact flat colour, and almost nowhere else. Note that format choice only ever compresses the pixels you decided to keep — it does not rescue an image that is four times larger than its slot, which is the problem the rest of this report measures.
Why this matters
An image downloaded much larger than it displays costs transfer, decode time, and memory — and when it is the LCP element, it directly drags Core Web Vitals on mobile.
Largest Contentful Paint is the specific vital at stake, and on a homepage or landing page the LCP element is almost always an image. Google treats LCP as "good" when it completes within 2.5 seconds for 75% of visits, and an oversized hero costs against that twice over: a larger file takes longer to arrive, and then takes longer to decode once it has. The decode half is easy to forget, and it is the half that hurts most on a mid-range phone.
Layout shift is the quieter cost. An image without width and height attributes gives the browser nothing to reserve space with, so everything below it moves when the image finally arrives. Those two attributes are a ratio, not a display size, so setting them does not conflict with CSS sizing.
The fix is mechanical: right-size to the actual display dimensions, add srcset, and convert to a modern format. We cover the full workflow in this writeup and the image optimization checklist.
Wondering what size things should actually be? The best image sizes for websites guide gives recommended dimensions and file-weight budgets by use case — hero, blog header, in-article, thumbnail, favicon — which is the prescriptive companion to the measurements here.
Companion study: What 883 Real Image Audits Found covers 883 sites and 25,546 images — a much larger but self-selected field sample. This report is a deliberately curated benchmark of popular sites with segment breakdowns; the two use different sampling and their numbers are not interchangeable.
Methodology
- 60 popular websites were selected across eight segments; 44 returned usable data (the remainder timed out or returned bot-challenge pages and were excluded).
- Each homepage was loaded in a real headless Chrome at 1366×900. We recorded every
<img>and CSS background image with its natural and rendered dimensions. - "Oversized" means natural area ≥ 4× rendered area (roughly 2× per dimension — beyond a 2×-retina allowance). Only visible images with known natural dimensions are counted as "measurable."
- All figures are aggregate. No individual site is named, and detectable oversizing is a performance observation, not a judgment of any specific site.
Curious how your own site compares? Run the same measurement on any URL.
Scan your site →Citing this report? Please attribute to "Image Dimensions Analyzer (2026)" and link to this page. Every figure is "of the 44 sites we tested."