Image audit
Every image a page loads, ranked by the bytes it could shed — format, size sent, size displayed — and the one thing to do first.
Enter any public URL. You’ll get every image the page loads, ranked by how many bytes it could shed, with the format, the size it is displayed at, and what to do first.
What the audit shows
For each image: the file name, its format, what it cost to download on a phone, the box it is drawn into, and Lighthouse’s estimate of what it could shed. The reason is named — older format, larger than displayed, under-compressed, or animated GIF — because the fix is different for each. The image that is the page’s largest element is marked LCP: that one delays the main paint directly, so it comes first whatever its rank.
The order that works
- Resize first. Export each image at twice the width it is displayed at. A 4000-pixel camera photo in an 800-pixel slot wastes more through size than any format can recover.
- Then convert. WebP at quality 80, or AVIF at 50–60 with a WebP fallback, in a
<picture>element. The image formats guide has the commands and the markup. - Then lazy-load everything below the fold — and never the LCP image.
What it does not do
It does not measure time; the Core Web Vitals check does, and shows whether the image bytes are actually what the visitor is waiting for. It does not see images loaded after the measurement window. And it cannot judge quality — Lighthouse’s reference encoding is a reasonable middle; if a photo needs to look pristine, raise the quality a notch and you will still be far smaller than the original.
Common questions
Where do the savings numbers come from?
From Lighthouse, the same engine behind PageSpeed Insights. For each image it compares the bytes sent against what the same image would weigh re-encoded at its reference quality (WebP at 85, roughly) and resized to the box it is displayed in. They are estimates — your encoder and quality setting will land somewhere nearby, not on the exact figure.
Why is an image 'larger than displayed' when it looks fine?
Because the browser downloaded the full file and then scaled it down. A 2000-pixel photo in a 400-pixel slot looks perfect and wastes about 90% of its bytes. Phones need roughly two device pixels per CSS pixel, so the honest target is twice the displayed width — 800 pixels here — not 2000.
Should I convert everything to AVIF?
WebP is the safe default: every current browser supports it and it cuts a JPEG by 25–40% at the same visible quality. AVIF goes further but encodes slowly and very old browsers skip it. The picture element lets you serve AVIF with a WebP fallback, so it is not an either/or.
The audit shows fewer images than my page has.
It lists what loaded during the Lighthouse run on a simulated phone. Images that are lazy-loaded far below the fold, or added by JavaScript after the measurement ended, do not appear. Test a page on its own if you want its specific images.
Does fixing images fix my speed score?
Only if images are what is slow. The audit measures bytes; the Core Web Vitals check measures time and shows which phase the time sits in. If the LCP image is flagged here, fixing it shortens the download phase directly. If the time is in the server or in render-blocking scripts, smaller images change little.