# A Third of WordPress Images Are Too Wide for Any Phone in 2026, and They Carry 73% of the Bytes

> We fetched 3,870 images from 368 WordPress homepages twice, with two different Accept headers. Format adoption is 42% or 28% depending on what you ask for.

- Published: 2026-10-03
- Updated: 2026-10-04
- Author: xSpeed Cache Team
- Tags: Images, WebP, Page Weight, Research, Performance, check:A3
- Canonical: https://xspeedcache.com/blog/webp-avif-adoption-page-weight/

---

Updated October 2026

A live probe of 368 WordPress homepages on 3 October 2026 found that 42.3% of the images they serve are WebP or AVIF, and those modern files account for only 29.3% of the bytes that actually arrive. The same probe, run minutes later against the identical URLs with a plain `Accept: */*` header, put modern-format adoption at 27.9%. Nothing changed on those sites in between. The number moved because the question did.

The census everybody wants is "what share of WordPress has adopted WebP". That number does not exist as a property of a site, because a growing share of sites decide the format per request. The census that survives contact with the data is a decomposition: of the image bytes a phone actually downloads, how many are legacy format, and how many are simply too many pixels.

## Quick Summary

| If you want… | Do this | Why |
|:---|:---|:---|
| To know whether your images are the problem | Run the scan and read check A3 | It measures transferred bytes, not plugin settings |
| The biggest single win | Resize, do not convert | Oversized files hold 73.2% of delivered image bytes |
| To finish the format job | Convert what is left | Legacy formats are 67.0% of bytes, worth about 25.7% back |
| To stop the problem recurring | Cap upload dimensions | 81.4% of images declare the file's own width as their display width |
| To audit a fleet | Probe with two Accept headers | 21.9% of sites answer the same URL with a different format |
| A number you can quote | Quote the instrument with it | Adoption reads 42.1% or 27.9% on identical images |

Across 2,951 raster images carrying 361.8 MB, the finding that decides where to spend an afternoon is this: **26.0% of all delivered image bytes are already in a modern format and still wider than any phone can use.** Those are bytes the conversion work was spent on and did not reach.

## How This Was Measured, and the Four Limits on Every Number Below

The method comes before the results here, because every figure below is bounded by it.

The sampling frame is our own scan archive. On 3 October 2026 the report sitemap at `/scan/r/sitemap.xml` listed 3,011 reports, one per distinct hostname. All 3,011 were fetched as structured JSON from `/api/scan/{scanId}`, with zero fetch errors, and 2,022 of them carry `platform.wordpress: true`.

| Probe parameter | Value |
|:---|:---|
| Frame | 2,022 distinct WordPress hosts in the scan archive |
| Sample | 400 hosts, fixed seed 20261003 |
| Reached | 368; 12 HTTP errors, 20 connection failures |
| Per host | homepage HTML, first 15 unique image URLs in document order |
| Lazy images | `src`, `data-src`, `data-lazy-src`, `data-original` all followed |
| Per image | two `Range: bytes=0-4095` requests, differing only in `Accept` |
| Format and pixel size | read from the file's magic bytes |
| Byte size | read from the `Content-Range` response header |
| Yield | 3,870 images probed, 3,391 parsed, 3,268 with a known size |

Reading the magic bytes rather than trusting `Content-Type` was not fussiness. The two agreed on 3,358 of 3,376 images, and **17 of the 18 disagreements were AVIF files served as `Content-Type: text/plain`**. A census that trusted the header would have recorded those as not-images.

Now the limitations, all four of them load-bearing.

1. **The frame is sites somebody scanned, not WordPress.** Every host in the archive is there because a person or an agent submitted it to our scanner. That population is more performance-aware than the web, and 991 of the 2,022 WordPress reports detect our own plugin, which tilts it further. Treat every figure as descriptive of this sample.
2. **Fifteen images per homepage, and homepages only.** Document order approximates what loads first, and it does not capture a gallery, an archive page or anything below the first 15 elements.
3. **CSS background images are invisible to this method.** They carry no `<img>` element, so a site whose hero is a background image contributes nothing for that slot. Our own fix guide named this route as one of the three that bypass the `srcset` chain, and it bounds this study the same way.
4. **A "slot" cannot be read from HTML, which turns out to be the finding rather than the caveat.** The honest proxy used below is a fixed ceiling, stated before it is used.

### The 824-pixel ceiling, and why it is a floor on the waste

A Pixel-class phone is 412 CSS pixels wide. At a device pixel ratio of 2, an image spanning the full width of that viewport needs 824 device pixels and no more. So 824px is the widest any full-bleed image on a phone can use.

That makes every count below a **lower bound on waste, not an estimate of it.** Most images are not full-bleed. An image in a 700px content column with a sidebar, or in a three-up card grid, needs far fewer than 824 pixels, so a file that clears the ceiling is wasteful by more than the ceiling implies, never less.

### The instrument was checked by probing twice, on purpose

Yesterday's redirect study got its noise floor by accident and could only publish population medians as a result. This one built the repeat in deliberately: 150 of the 400 hosts were probed a second time, minutes after the first pass.

| Repeat measurement | Result |
|:---|:---|
| Images fetched under the same URL in both passes | 1,247 |
| Format identical | 1,247 of 1,247 (100%) |
| Intrinsic width identical | 1,247 of 1,247 (100%) |
| Byte size identical | 1,216 of 1,216 with a known size (100%) |
| Modern-format share on those images | 43.79% in both passes |
| Hosts reachable in one pass and not the other | 5 of 150 |

Bytes and pixel dimensions are exactly reproducible, which is the opposite of what we found measuring time. **Per-site figures are therefore publishable here**, and the only unstable thing in the whole method is whether a host answers at all.

## The Two-Accept Census: Format Is a Property of the Request

Here is the original framework, and it is the reason a single adoption figure is not worth quoting. Request the same image URL twice, changing only the `Accept` header, and record whether the format comes back different.

Of 3,326 images that answered under both headers, **472 (14.2%) returned a different format depending on what was asked for.**

| Legacy response | Modern response | Images |
|:---|:---|---:|
| PNG | WebP | 249 |
| JPEG | WebP | 185 |
| JPEG | AVIF | 30 |
| PNG | AVIF | 8 |

On those 472 images the modern answer was a median 41.2% smaller, taking 147.8 MB down to 53.1 MB. 73 of 334 hosts, **21.9%**, served at least one negotiated image.

So the headline adoption figure depends entirely on the crawler's manners:

| Instrument | Modern-format share of the same 3,326 images |
|:---|---:|
| Chrome's `Accept` header (AVIF and WebP offered) | 42.1% |
| `Accept: */*` | 27.9% |

Fourteen points, same images, same minute. According to the [Lighthouse documentation for the modern image formats audit](https://developer.chrome.com/docs/lighthouse/performance/uses-webp-images), that audit runs in Chrome, so it sees the upgraded view. Our own archive agrees and still fails most sites: across the 1,642 WordPress reports where check A3 produced a verdict, 843 failed outright, 556 came back partial and only 243 passed. That is **14.8% passing the format audit in the view most favourable to the site.**

The practical consequence is small and worth stating plainly. If a report tells you your images are fine, check which headers it sent. If a vendor quotes you a WebP adoption rate, the rate describes their crawler.

## What 368 Homepages Actually Ship

Measured with Chrome's `Accept` header, which is the generous view:

| Format | Images | Share of images | Share of bytes |
|:---|---:|---:|---:|
| WebP | 1,308 | 38.6% | 21.8% |
| PNG | 939 | 27.7% | 38.8% |
| JPEG | 751 | 22.1% | 28.2% |
| SVG | 255 | 7.5% | 0.9% |
| AVIF | 125 | 3.7% | 7.4% |
| GIF | 13 | 0.4% | 2.8% |

WebP is now the most common single format by count. It is nowhere near the most common by weight, and PNG at 27.7% of images and 38.8% of bytes is the line that matters: PNG is where the heavy files are hiding, and converting a photographic PNG is the one conversion that reliably pays.

Site by site, counting raster images only, 328 hosts carried at least one:

- 🟢 89 hosts (27.1%) serve every raster image as WebP or AVIF
- 🟡 115 hosts (35.1%) serve a mix
- 🔴 124 hosts (37.8%) serve no modern format at all
- 📊 204 hosts (62.2%) serve at least one

![Format adoption measured two ways on the same images: 42.1% modern under Chrome's Accept header against 27.9% under Accept colon star-slash-star, with 472 of 3,326 images changing format between the two requests](https://xspeedcache.com/images/blog/image-format-two-accept-census.webp)

## A Third of the Images, Three Quarters of the Bytes

The width distribution is where the weight actually lives. Across 2,951 raster images with both a readable width and a known size, the median delivered image is 604 pixels wide, the upper quartile is 1,024, and the widest single file is 9,000.

| Delivered width | Images | Share of images | Bytes | Share of bytes |
|:---|---:|---:|---:|---:|
| Under 400px | 1,004 | 34.0% | 12.3 MB | 3.4% |
| 400 to 823px | 916 | 31.0% | 84.7 MB | 23.4% |
| 824 to 1,199px | 473 | 16.0% | 65.8 MB | 18.2% |
| 1,200 to 1,599px | 226 | 7.7% | 69.4 MB | 19.2% |
| 1,600 to 2,047px | 196 | 6.6% | 49.4 MB | 13.7% |
| 2,048px and wider | 136 | 4.6% | 80.2 MB | 22.2% |

Read the two ends against each other. The 1,004 images under 400 pixels are a third of everything served and 3.4% of the weight. The 136 images at 2,048 pixels and wider are 4.6% of the count and **22.2% of the weight**, nearly five times their share. In total, 1,033 images clear the 824-pixel ceiling: 34.8% of the files, carrying **73.2% of every image byte delivered.**

![Width bands across 2,951 raster images: files under 400px are 34% of images and 3.4% of bytes, while files over 2,048px are 4.6% of images and 22.2% of bytes](https://xspeedcache.com/images/blog/image-width-bands-bytes.webp)

### The decomposition, using measured savings rather than a model

Our own fix guide on this symptom encoded twelve photographs four ways and published what each lever actually returned: converting to WebP saved a median 38.4%, resizing to a sensible width saved 92.8%. Applying those measured constants to the 361.8 MB this probe pulled down:

| Lever | Bytes it applies to | Measured saving | Recovered |
|:---|---:|---:|---:|
| Convert the legacy formats | 242.5 MB (67.0%) | 38.4% | 93.1 MB, or 25.7% of all image bytes |
| Resize the over-ceiling files | 264.8 MB (73.2%) | 92.8% | 245.7 MB, or 67.9% of all image bytes |

The two overlap, and the overlap is the point: **26.0% of all delivered image bytes, 94.2 MB, sit in files that are already WebP or AVIF and still wider than any phone can use.** Of the 89 hosts serving nothing but modern formats, **62 of them (69.7%) still ship at least one file over the ceiling.** Finishing the conversion job completely does not touch the dimension job.

![The byte decomposition: 73.2% of delivered image bytes sit in files wider than 824px against 67.0% in legacy formats, with 26.0% in the overlap that is already modern and still oversized](https://xspeedcache.com/images/blog/image-bytes-decomposition.webp)

## WordPress Writes the File's Own Width Into Your Page

The reason the waste survives conversion is in WordPress core, and this probe measures the consequence at population scale.

Of 2,225 images whose HTML states a width, the median ratio of delivered pixels to declared width is **exactly 1.00**, and **1,811 of them (81.4%) declare precisely the width of the file that arrived.** The document is not describing a layout slot. It is reading the file's dimensions back to you.

That is `wp_calculate_image_sizes()` behaving as documented. The function reference for [`wp_calculate_image_sizes()`](https://developer.wordpress.org/reference/functions/wp_calculate_image_sizes/) builds the `sizes` attribute from the image's own width, so a 2,560-pixel upload announces that it occupies the full viewport below 2,560 pixels. In a 700-pixel column that statement is wrong by a factor of three or four, and nothing in the browser checks it. The core default for [`big_image_size_threshold`](https://developer.wordpress.org/reference/hooks/big_image_size_threshold/) is 2,560 pixels, which is the outer bound a stock install allows an original to keep.

**Three numbers follow from it, and each one breaks a different assumption.**

- **25.0% of raster images carry no `width` attribute at all** (741 of 2,951), and 33.7% of those are over the ceiling. No attribute means no declared slot, so the browser has nothing to reason about before layout.
- **Only 59.5% of images carry a `srcset`.** The other 40.5% offer the browser exactly one file, whatever its size.
- **47.6% set `loading="lazy"`.** Deferring a download does not make it smaller, and a lazy 2,048-pixel hero is still a 2,048-pixel hero when it arrives.

The pathological cases make the mechanism concrete. One host delivers a 9,000 by 5,063 PNG weighing 2.4 MB with a declared width of **1**. Another serves a 7,952-pixel JPEG at 5.4 MB whose declared width is, faithfully, 7,952. The heaviest single file is a 12.7 MB PNG, the second a 10.7 MB animated GIF. For the fix order on one site, our guide on [why every image is WebP and the page weight did not move](https://xspeedcache.com/blog/webp-images-page-still-heavy/) walks the `srcset` chain, and the [350 KB page-weight study](https://xspeedcache.com/blog/page-weight-vs-lcp-wordpress/) covers what that weight does to mobile LCP.

## Our Own Sites, Measured the Same Way

The archive records which cache plugin each scanned site runs, so the sample splits cleanly, and the split does not flatter us. xSpeed Cache is ours, built by WPDeveloper.

| Group | Sites | Images | Modern by image | Modern by bytes | Over the 824px ceiling |
|:---|---:|---:|---:|---:|---:|
| Running xSpeed Cache | 168 | 1,595 | 44.6% | 26.7% | 35.0% |
| Running something else or nothing | 160 | 1,541 | 46.8% | 32.7% | 34.7% |

Sites running our plugin serve **fewer** modern images than the rest of the sample, by 2.2 points on count and 6.0 points on bytes, and their oversizing rate is indistinguishable at 35.0% against 34.7%. Published because it is what the data says.

Two honest readings, and this study cannot separate them. Our format converter is a Pro feature, so a sample weighted toward free installs would look exactly like this. And the sample is not random with respect to the plugin: these are sites somebody scanned, often because they were already slow. Either way the oversizing row is the one that matters, because it is flat across both groups. Dimension waste is not a plugin's doing and no plugin we or anyone else ships resizes what is already in a media library.

## Doing This to a Media Library of 4,000 Attachments

One homepage is a browser job. Three hundred of them is a script, and a media library with 4,000 attachments is neither.

The honest division of labour is the one our own CLI already reports: `wp xspeed optimize` names what it could not reach, page weight and hotlinked images among them, rather than claiming a win it did not make. Our WebP and AVIF converter is a Pro feature, and it addresses the 25.7% column in the decomposition above. It does not address the 67.9% one, and this article is not going to pretend otherwise.

- On the free tier xSpeed Cache lazy-loads images, resolves remote image dimensions so the preloader does not skip them, and serves media through a CDN; the [features list](https://xspeedcache.com/features/) and [Free vs Pro](https://xspeedcache.com/free-vs-pro/) mark which side each item falls on
- [How the checks are graded](https://xspeedcache.com/docs/speed-scan/) documents check A3 and the rest of the rubric
- Across a fleet, [xSpeed Hub](https://xspeedcache.com/xspeed-hub/) scans every connected site, and the [scan MCP documentation](https://xspeedcache.com/docs/scan-mcp/) covers driving it from an agent, which is how the 3,011 reports behind this study were read
- Hosting sets the floor underneath all of it. xCloud is ours too, a Startise company like WPDeveloper, and [xcloud.host](https://xcloud.host/) gives the cache an origin tuned for it. It will not make a 9,000-pixel PNG smaller
- Builders are where the missing `width` attributes concentrate, so see [page builder sites](https://xspeedcache.com/use-cases/page-builder-sites/), and [WooCommerce stores](https://xspeedcache.com/use-cases/woocommerce/) for catalogues where product galleries multiply every mistake above

Run the free xSpeed Scan on your own site: [xspeedcache.com/scan/](https://xspeedcache.com/scan/) reads transferred bytes rather than settings, so it catches the images no dashboard knows about.

## Common Mistakes People Make Reading an Image Audit

- 🔁 **Treating a passing format audit as a finished job.** 62 of the 89 all-modern hosts here still ship an over-ceiling file.
- 📏 **Trusting the `width` attribute as a layout fact.** 81.4% of the time it is the file's own width, copied.
- 🧪 **Quoting an adoption rate without its instrument.** The same images read 42.1% or 27.9%.
- 💤 **Reaching for lazy loading first.** It changes when bytes arrive, not how many.
- 🗂️ **Converting a 4,000-pixel original and stopping.** Format buys a better constant, width buys a square.
- 🔍 **Trusting `Content-Type`.** 17 AVIF files in this sample were served as `text/plain`.

## Frequently Asked Questions

### I converted my whole media library to WebP and my page weight barely moved. What did I do wrong?

Probably nothing, and this sample says the outcome is normal. Converting legacy bytes returns a measured median of 38.4%, while 73.2% of delivered image bytes are in files too wide for the slot they land in. If the files were oversized before the conversion they are oversized after it, in a better format.

### How do I know whether my images are too wide without checking every one by hand?

Run the scan and read check A3, then compare any image's rendered size in browser devtools against its intrinsic size. The scan reads transferred bytes, so it sees what arrived rather than what a plugin intended.

### My images all have srcset. Why would the browser still pick a big one?

Because `sizes` tells it how much space the image occupies, and in a stock WordPress install that string is built from the file's own width rather than your layout. The browser believes the document. 81.4% of the images measured here declare exactly the width of the file that arrived.

### Is AVIF worth it over WebP?

By these numbers it is not the decision to agonise over. AVIF is 3.7% of images in this sample, and the gap between it and WebP is a fraction of the gap between either one and an unresized original. Convert to WebP, resize properly, and revisit AVIF afterwards.

### Why did my audit tool and your figures disagree about my site?

Check what `Accept` header each one sent. 21.9% of the hosts here answer the same image URL with a different format depending on that header, so two tools can both be right and report different formats for one file.

### I cannot find the oversized images because my page builder inserts them. Where do I look?

Builder-inserted images are the ones most likely to carry no `width` attribute at all, which is 25.0% of the raster images here. Look at the delivered file's intrinsic dimensions rather than the markup, because the markup may not state a size for you to compare against.

### Should I cap uploads, or fix what is already in the library?

Both, and cap first because it is one setting and it stops the problem growing. WordPress will scale an original down above `big_image_size_threshold`, which defaults to 2,560 pixels, and that default is still far wider than most layouts need.

### Does a caching plugin fix page weight?

Not on its own, and ours says so in its own CLI output. A cache changes how fast the same bytes arrive. Image weight is a media-library problem, and the only plugin feature that genuinely moves it is format conversion, which this study puts at about a quarter of the available saving.

### What is a reasonable width to target for a full-width image?

824 pixels covers a full-bleed image on a 412-pixel phone at 2x, which is the ceiling used throughout this article. For an image in a content column or a card grid, considerably less. Measure the slot in devtools and double it.

### My PNGs are the heaviest files on the page. Is that normal?

It is the most common shape here. PNG is 27.7% of images and 38.8% of bytes, the largest single block of weight in the sample. A photograph stored as PNG is the single conversion that reliably pays.

### Can I reproduce these numbers myself?

Yes, and the method section above is written so you can. The sampling frame is a public sitemap, the per-report JSON is public, and the measurement is two range requests per image with different `Accept` headers. The seed was 20261003.

### How often is this worth re-running?

The archive grew by 46 reports the day before this run, so the frame shifts slowly and a quarterly re-run is enough. The two-Accept gap is the part worth watching, because it widens as more hosts add negotiation.

## What This Changes About the Order You Work In

Three findings, in the order they should change your afternoon.

**Resize before you convert.** Oversized files hold 73.2% of delivered image bytes against 67.0% in legacy formats, and the measured saving on the first is 92.8% against 38.4% on the second. The 26.0% overlap is bytes already converted and still wasted.

**Cap the upload, or the library refills.** 81.4% of images declare the file's own width because that is what core does with a `sizes` attribute, so every oversized upload keeps announcing itself as full-width forever.

**Never quote an adoption number without its instrument.** 42.1% and 27.9% are both true of the same 3,326 images on the same day. That applies to the figures in this article as much as anyone else's, which is why the method, the seed and the limitations are above the results rather than below them.

**What to do this week:**

1. Open your three heaviest pages and compare each image's rendered size against its intrinsic size.
2. Set an upload cap and a maximum content width, so the library stops growing the problem.
3. Resize the files above that cap, oldest heaviest first, keeping the format they already have.
4. Convert what remains to WebP, which is worth roughly a quarter of the total.
5. Run [the free scan](https://xspeedcache.com/scan/) and read check A3 before and after, so the change is measured rather than assumed.

For the resize-and-convert work on a single site, our [image format fix guide](https://xspeedcache.com/blog/webp-images-page-still-heavy/) has the per-image order. If you decide a plugin should do the conversion half, the [80-capability comparison](https://xspeedcache.com/comparison/) shows which tools ship a converter and which charge for it; xSpeed Cache is one of them, at a $29/yr founding price with a 14-day money-back guarantee, and its converter addresses the smaller half of the problem this study measured.

Run the same probe on your own site and tell us what the two Accept headers return. The gap is the part nobody is measuring.