A large JPEG, PNG or GIF has no modern-format alternative

Why it matters

The web.dev guide to Largest Contentful Paint includes modern image formats and compression among the ways to reduce resource transfer time. It also cautions that this is not a significant bottleneck for most sites: when rendering is delayed by other work, a smaller file can leave Largest Contentful Paint unchanged.

This check therefore reports a recorded size and format for review. It does not establish that the image is the largest element on any page, or that another format would change what visitors experience.

What to do

Open the finding: it shows the image address, the format read from the first bytes of the file, the encoded bytes received (exact, or a lower bound when the transfer was not complete), the recorded budget, the format returned to the negotiation request, and every declaring page that was read, with the state of each embedding.
Decide whether this image should be this large in this format. Where a smaller file is appropriate, publish a WebP or AVIF version and declare it for the embedding in a picture element whose source has type="image/webp" or type="image/avif", or have the server return a modern format for this address when the request accepts one.
Alternatively bring the file at or below the budget by resizing or compressing it. Compare the result by eye: the audit does not judge image quality.
For a GIF, the finding records how many image blocks a complete file contains. If you know that the image is animated, a video file is an option to consider; the block count alone does not prove animation.
Correct each affected embedding, then run a new full audit.

When to leave it as it is: You can leave the image as it is when its size and format are deliberate, for example a detailed photograph or a file that other systems must receive as JPEG or PNG. The budget is a review setting, not a requirement.

What we read

We read each selected page's original HTML as the server returned it, without running JavaScript. For every img element outside head, script, style, noscript and template content we take the addresses in src and srcset, together with the source elements that precede it as direct children of the same picture. Images set in CSS or added by scripts are not read.

A source with type="image/webp" or type="image/avif", a usable srcset and no media condition counts as a declared modern alternative for that one embedding. It is a declaration, not proof that the file is available. For srcset candidates without a type, the format comes from the captured bytes of each candidate; a file name ending is never used.

The format of the image comes from the first bytes of the captured file: JPEG, PNG and GIF are treated as legacy formats, WebP and AVIF as modern ones. Its size is the encoded response-body bytes that our reader measured; Content-Length and the decoded length are not substitutes. Only a size above the budget recorded with the audit settings counts, and an audit without a recorded budget does not borrow the default.

For an eligible image we make one further request for the same address with Accept: image/avif,image/webp and record the format of the response. A complete, qualified modern-format response can show that this image needs no change for the check. Reporting a legacy image requires both responses to qualify: HTTP 200, headers that agree with the bytes, and no bot-challenge marker in the response headers.

One finding covers one image address, including its query string, and lists the pages that embed it. A page is listed as affected only when its own embedding is confirmed; other pages that declare the same address stay in the evidence with their own state.

Example & evidence

Illustrative example — schematic declarations and recorded counters, not a live audit.

Two pages of https://bakery.example/ embed the same image address. The recorded budget is 102,400 bytes.

<!-- https://bakery.example/cakes/ -->
<img src="/img/cake.jpg" width="1600" height="900" alt="Lemon cake">

<!-- https://bakery.example/menu/ -->
<picture>
  <source type="image/webp" srcset="/img/cake.webp">
  <img src="/img/cake.jpg" width="1600" height="900" alt="Lemon cake">
</picture>

https://bakery.example/img/cake.jpg
Format from file bytes: JPEG
Encoded bytes received: 348160 (exact)
Recorded budget: 102400 bytes
Request with Accept: image/avif,image/webp returned: JPEG

The address is reported for /cakes/, whose embedding declares no modern alternative. /menu/ declares a WebP source for its own embedding, so it is recorded as a declaring page but not as an affected page.

A possible correction: declare the WebP alternative on /cakes/ as well, or bring the file at or below the budget. The next full audit can close the finding when it reads every recorded declaring page in full and finds each embedding clean or removed. A page it cannot read keeps the finding open.

Confirm & check again

Check for yourself: Open a page that embeds the image with the browser's Network panel and note the transferred size and the Content-Type of the image response. To repeat the negotiation, request the image address with a command-line client and the header Accept: image/avif,image/webp, save the body and open it in an image tool to see its format. A browser sends its own Accept value, so its result can differ from the recorded request.

Check again: Full audit — Run a new full audit after the change is live. The finding closes only when every retained declaring page and every current possible declaring page is checked completely and the original image is clean or removed from each embedding. An unread page, an incomplete image inventory or uncertain resource evidence keeps the finding open. Removing the embedding requires complete original HTML; a remaining untyped image also needs the applicable captured response evidence and recorded budget. A closed finding returns only when a later audit reports this image address again.

Limits & sources

This is a comparison of recorded bytes with a recorded budget. We do not render pages, so displayed size, the source a browser would select, visual quality and loading time are not measured, and the check does not identify the Largest Contentful Paint element.

A format read from the first bytes does not prove that the whole file is a valid image. For GIF, the image-block count of a complete file is recorded; it does not prove animation or timing.

The negotiation result describes one response to one request made by the audit. A server, CDN or cache can answer other clients differently, and the result does not show what a server can do in general.

Only the original HTML is read. A source with a media condition, a malformed srcset, an img that cannot be tied to its picture, and HTML cut short by the audit's reading limits leave the embedding unconfirmed, not clean.

Image and negotiation requests share the audit’s request limits, robots.txt rules and pacing. An incomplete transfer or retained prefix can show that an image is above the budget, but cannot prove that it is below it. When a response is needed to decide this check, a missing or failed request, a challenge response, or headers that disagree with the bytes leave the image unconfirmed.

No saving is promised. How much smaller a WebP or AVIF version would be depends on the image.

Confidence: High The format, byte counts and negotiation response are read directly from recorded responses, and the declarations from the original HTML. Whether the image matters to visitors, or whether another format would serve them better, is a judgment the audit does not make.

Sources

web.dev, Optimize Largest Contentful Paint — Explains reducing the LCP resource's size, including modern image formats and compression, as a way to reduce transfer time. Warns that transfer time is not a significant bottleneck for most sites and gives an example where a smaller image leaves LCP unchanged because rendering is delayed. It does not establish our 100 KiB budget, negotiation procedure, GIF interpretation or any expected saving. Checked 2026-10-13.

Editorial review: 15 October 2026