Last reviewed:
On this page
Why your images carry extra bytes
A product photo often leaves the camera about 3,000 pixels wide. You upload it, and the platform keeps the original while generating six or eight smaller versions. That part works as intended.
The extra weight appears at delivery. A theme may choose a 1,536-pixel image for an 800-pixel slot. Format adds another gap: across 14 images from two real stores, WebP was 21.8% lighter than JPEG at the median when perceived quality was held at the same point. WebP won in 11 of those 14 comparisons. Your visitor downloads every extra byte.
On September 3, 2026, we measured the home pages of 41 stores across 14 platforms. The WordPress and WooCommerce stores served between 2.5 and 2.7 times more bytes per pixel than the Shopify stores. This was a small, uneven sample: 7 WordPress stores and 12 Shopify stores. Treat it as a measured signal, not a census.
Where those extra bytes land
Image weight has three direct costs.
| Where | What happens |
|---|---|
| Your visitor's phone | It downloads bytes the screen does not use. |
| Your server | It sends those extra bytes again with each image request. |
| Your time | You resize, compress, and export files by hand. |
LCP measures the time until the largest image or text block is rendered in the viewport, as the web.dev documentation explains. On a product page, that block is often an image. This checker measures image bytes. It does not measure page-load time or diagnose hosting, theme, or checkout performance.
Why a fixed percentage misses the result
Multiplying today's weight by one percentage is quick. It also treats every photograph, illustration, size, and format as if they compressed alike.
We tested that baseline on 8 stores held out from the model. Its median image-by-image error was 59.4%. The estimator on this page reduced that error, but its output remains a prediction and is labeled estimated.
Lighthouse, the Chrome tool behind the audit on next-gen image formats, documents two limits: it converts images to WebP but estimates AVIF size, and it omits images with potential savings below 8 KiB (developer.chrome.com). Measured bytes and estimated output need different labels.
How this checker measures image weight
The checker opens the page you provide in a real browser, sees the images your visitors see, and counts the bytes that were actually downloaded. It then resizes and encodes those images as WebP to estimate what they would weigh when delivered at the needed width.
- We read one page. We open it in a real browser, so we see the images your visitors see — including the ones JavaScript inserts and the ones that load as you scroll. We do not crawl the rest of the site.
- We weigh each image. We count the response bytes and read its real width and height from the file header.
- We encode the image. The browser decodes it, reduces it to the width used by the page, and encodes a WebP file. Nothing about your site is changed.
Measured now, estimated after conversion
The current weight is measured: those bytes came from your server. The WebP weight is estimated. It comes from a real encode of every image we could read, then receives a small correction because the browser's encoder is not byte-identical to the delivery encoder. The corrected value is still a prediction, so estimated items keep that label in the report.
What the report includes
The total is backed by an image-by-image breakdown.
- Current and estimated totals, in kilobytes and as a percentage.
- Weight, dimensions, and format for every image the page downloads.
- An estimated label wherever the result is a model output rather than measured bytes.
- A report by email, available when you ask us to send it.
- The files the checker could convert to WebP, available to download for two days.
What the WebP result means
The main result uses WebP because that is the format included in the free plan. It estimates WebP at the width used by the page. In a separate test, AVIF was 21.8% lighter than WebP at the median across 16 derivatives from one real store, at the same width and perceived quality. That AVIF figure is a reference for the paid plan, not an estimate for the page analyzed here.
One file does not represent every screen
When a site provides responsive images, a browser downloads the larger source only when needed, as the web.dev documentation explains. The report lists the dimensions and format retrieved in this scan. A different screen may receive a different source from the same site.
How far the estimate can vary
We measured this checker against NimboCDN's own delivery: four sites we control, running the connector, with every image compared one by one against the bytes the network actually served. 256 images.
| Measure | Result |
|---|---|
| Delivered width predicted correctly | 164 of 166 |
| Headline error per site | within 3 points |
| Worst site observed | 2.8 points |
| Image-by-image spread | 0.94x to 1.01x |
The image-by-image spread is the number to be careful with. Errors average out across a page, so the total is dependable and a single row is not — which is why the report labels per-image figures as estimated and the headline is what we stand behind.
The remaining gap is the encoder: a browser's WebP is not byte-identical to the one that delivers your images, and the correction for it depends on the kind of photography a site publishes. It is now a single constant of 1.035: the earlier version mixed the encoder with the resizing error, and that second error was removed.
This does not measure page-load time. It measures image bytes. Hosting, theme code, scripts, network conditions, and the rest of the page also affect how long a page takes to load.
From a measurement to lighter delivery
If you only want to fix one photo right now, the free compress image tool runs in your browser and uploads nothing. The report shows where the image bytes are. NimboCDN is the optional next step: it resizes, converts, and delivers images while leaving the originals unchanged.
NimboCDN is an image CDN for WordPress. Install the connector and activate it. Each image is then prepared once at the size and format needed by the visitor and delivered through our network of 335 cities in more than 125 countries. The original files stay on your server.
The free plan covers up to 50 new images a month on your home page in WebP. It does not expire, and there is no credit card. Traffic does not change the price. The paid plan covers the full site in AVIF for $9.90 a month.
- Original files stay intact. Nothing is recompressed, moved, or deleted.
- Turn it off in one click. Disable the connector and the original image URLs return right away.
- Automatic fallback. If the service cannot deliver an image, the connector serves the original.
- Fixed traffic cost. There is no charge per visit, per bandwidth, or for overage.
For a product-by-product comparison, see the alternatives to Optimole and ShortPixel versus Imagify. The first also covers what happens when an Optimole visit limit runs out.
What this page stores
We store the report and the page address included in it. Converted images stay available for download for two days and are then deleted. Files on your server are never changed.
This page uses Google Analytics and its _ga cookie to measure aggregate usage. We also retain the connecting IP address for 24 hours to enforce scan limits, then delete it.
Questions
Does this change anything on my site?
No. The checker only requests the page and its image files. It does not write to your site or change the originals.
Do I need to install anything?
No. Measuring requires no account, no credit card, and no access to WordPress. The connector is only for applying the optimization afterward.
Which page should I test?
Test the page that matters: a home page, category, or product page. The checker handles one address at a time and does not crawl the whole site.
Can I measure a client's site?
Yes. Run the scan and request the report by email if you want to pass it on. Hourly and daily limits prevent automated scans of thousands of sites.
Why did the page return an error?
A firewall may reject an unfamiliar reader, and some sites answer a challenge page instead of their own. Pages that insert images only with JavaScript are read correctly, because the checker runs them in a real browser.
How accurate is the estimate?
Measured against NimboCDN's own delivery on four sites we control, 256 images compared one by one: the headline lands within 3 points, and 164 of 166 delivered widths were predicted correctly. Per-image figures spread much wider and are labeled estimated.
Do you keep my images?
We read and encode them to calculate the result. Converted files remain available to download for two days, then are deleted. The files on your server are untouched.
Can I use this without WordPress?
The checker works with any platform. The connector currently supports WordPress; BigCommerce and PrestaShop are planned without a release date.
Start with the page that matters most. If you want NimboCDN to handle the result, install the connector in two minutes. Your home page is free, with no credit card.