What the Image Delivery Optimizer does
This checker reads a public page, downloads the images its HTML references and audits how each one is delivered: its real format and transfer size, its pixel dimensions against the width the page declares, whether it is lazy-loaded (and whether it should be), whether it has width and height to prevent layout shift, and how long browsers may cache it. For every image it lists the fixes and an estimated byte saving, with the basis of each estimate stated.
The measurements are real - our server downloads each file and reads its header for format and dimensions - but they come from one server, not your visitors' browsers. Nothing is re-encoded; the savings are estimates, not compressed files.
How to use it
- Enter the full URL of a public page, such as a product, article or landing page.
- Press Check images. The server reads the HTML and fetches up to 60 referenced images, which can take up to 30 seconds on image-heavy pages.
- Start with the findings at the top: images marked as problems (errors, a lazy-loaded image near the top, no-store caching) come first, then the largest savings.
- Use the table to sort by size or saving, and download the CSV to share the list with whoever manages the images.
- After fixing, check again - and confirm the effect on LCP with field data or the LCP Element Analyzer.
Reading the results
Format savings use Google's published WebP figures at the low end: lossy WebP about 25% smaller than JPEG, lossless WebP about 26% smaller than PNG. AVIF is often smaller still, but its saving varies too much to state a single number.
The resize estimate applies only when the <img> declares a width and has no srcset. An image wider than twice that width (enough for 2x screens) is assumed to shrink in proportion to its pixel area when resized - an A2Z heuristic, since real savings depend on content.
Lazy-loading is good for images further down the page and harmful for the first ones, which may be the LCP image. Images among the first two in the HTML with loading="lazy" are reported as problems.
Cache lifetime comes from Cache-Control. Without a max-age, browsers fall back to heuristic freshness; with no-store, every visit downloads the image again.
Worked example: a recipe page with a heavy hero and an oversized avatar
The recorded sample page references eight images totalling 1.19 MB. The hero is a 612 KB JPEG, 2,400 px wide, with loading="lazy", no width or height and a one-hour cache - a problem on four counts. Converting it to WebP alone saves about 25%, or 153 KB.
A step photo is a 380 KB PNG that is 1,400 px wide but declared at 400 px. Serving 800 px (enough for 2x screens) keeps (800 / 1,400)^2 = 33% of the pixels, and WebP saves a further 26%: 1 - 0.74 x 0.33 = about 76%, or 288 KB.
The author photo is 1,000 x 1,000 px for a 64 px avatar and has no cache lifetime; one image returns 404. Across the page the estimated saving is 536 KB - about 44% of the image bytes - before any change to compression quality.
Formulas and scoring rules
- Format saving
JPEG -> WebP: 25%; PNG -> WebP: 26%; GIF: 26%Low end of Google's published WebP comparisons.- Resize saving
resize = 1 - (2 x declared_width / intrinsic_width)^2, when intrinsic > 2 x declared and there is no srcset- Combined
saving = bytes x (1 - (1 - format) x (1 - resize))Rounded to whole bytes; savings are added across images.
The image fixes that matter most for LCP
The hero or product image is usually the LCP element on image-led pages. Make sure it is an <img> in the HTML (not a CSS background or script-set URL), is not lazy-loaded, has fetchpriority="high", has width and height, and is served in a modern format at a size close to its displayed size. The LCP Element Analyzer checks those points for the single most important image.
For every other image, the wins are bytes and bandwidth: srcset and sizes so phones do not download desktop images, lazy-loading below the fold, and long cache lifetimes with versioned file names.
Limitations: what the result does not prove
- Only images in the HTML are checked:
<img>,<picture>sources, video posters and inline style backgrounds. Images added by JavaScript or referenced only in external CSS files are not seen. - Our server downloads the files from one location and may receive different formats or sizes than a browser that advertises AVIF or WebP support, or a CDN that resizes per device.
- Declared widths come from the width attribute; CSS may display the image at a different size, which static HTML cannot reveal.
- Savings are estimates from stated rules. Re-encode the images and compare real file sizes before reporting results.
Privacy: where your data goes
a2z.tools requests the public address you enter with an ordinary read-only GET, the way a browser would, and analyses the response. Private and internal addresses are refused. Nothing is stored. Session recording and tag-manager scripts are switched off on this page.
Standards and sources
- web.dev - Optimize Largest Contentful Paint - checked 19 Sep 2026
- HTML - img srcset and sizes - checked 19 Sep 2026
- Google for Developers - An image format for the Web (WebP)
- web.dev - Browser-level image lazy loading
- RFC 9111 - HTTP Caching
Frequently asked questions
Should I convert all my images to WebP or AVIF?
For photos and most graphics, yes: both are supported by current browsers and are usually much smaller than JPEG and PNG at the same visual quality. Use <picture> with a JPEG fallback if you still support very old browsers.
Why is my image flagged as larger than it is displayed?
Its pixel width is more than twice the width the page declares, so even high-density screens do not need all those pixels. Provide smaller versions through srcset and sizes, or resize the file to about twice the displayed width.
Is lazy loading always good for performance?
No. It helps images below the fold by postponing their download, but it delays images at the top of the page - including the likely LCP image - because the browser waits for layout before requesting them.
Why do width and height attributes matter if CSS sets the size?
The browser uses the width and height attributes to compute the aspect ratio before the file arrives, so it can reserve the right amount of space. Without them the image pops in and pushes content down, which counts as layout shift.
What Cache-Control should images have?
Images with versioned file names can use public, max-age=31536000, immutable, so repeat visitors never download them again. If file names do not change when images change, use a shorter max-age with revalidation.
Why can a page's images be unavailable in the check?
Our server could not read the page or its files - for example because of bot protection, a login, geo-blocking or a timeout. The result then says unavailable instead of showing a clean report, because nothing was assessed.
Last reviewed by the A2Z.Tools team against the sources listed above.
