Image URLs use older formats (jpg/png)
image_legacy_formatShort answer
Three or more images on the page are served from .jpg or .png addresses. At equal quality WebP is about 25–34% smaller than JPEG and about 26% smaller than PNG (Google's own numbers); AVIF often smaller still. Lighter images mean faster LCP. Serve WebP/AVIF with a <picture> element or a CDN that converts on the fly. If your server already sends WebP to browsers at the .jpg URL (content negotiation), you can ignore this row.
Why it matters
Images are usually the largest share of a page's bytes, and the LCP element is usually an image. Format alone can cut that weight by a third without visible loss. This is informational: the rule looks at the URL's extension, so a server that negotiates formats behind .jpg URLs is counted here although it is already fine.
How Glimana detects it
The rule fires when at least three images on the page have .jpg, .jpeg or .png extensions; the evidence shows the count.
How to fix it
- Find the affected pages in Glimana. Open Issues › Image URLs use older formats (jpg/png). Every affected page is a row; open one to see the evidence Glimana recorded for it (the measured value, the offending element or the target URL). The same list sits on the task card under Tasks, and the page's own detail view under Pages shows its full signals.
-
Apply the fix on your platform.
Enable WebP/AVIF conversion in your image plugin (ShortPixel, Imagify, EWWW, or the host's CDN). WordPress 6+ can generate WebP on upload; existing images need a bulk conversion.
Shopify's CDN already serves WebP/AVIF to supporting browsers when you use
image_url/image_tag; URLs still end in.jpg, so ignore this row for Shopify-hosted images.Build pipeline: generate WebP/AVIF variants and use
<picture><source type="image/avif"><source type="image/webp"><img></picture>; or put a transforming CDN (Cloudflare Images, imgix) in front. -
Publish and clear caches. Save and publish, then make sure the crawler will see the new version: WordPress — clear the page cache in your cache plugin and purge the CDN; Shopify — theme and content changes go live on save, but purge any CDN in front of the store; custom code — deploy and purge the edge cache. Check in a private window or with
curl -s https://your-domain/page | grep -i '<title\|canonical\|robots'that the live HTML has changed; Glimana reads what the server sends, not what your browser has cached. - Verify in Glimana. Open the task under Tasks and click Mark as done. The affected pages are queued for a verification crawl within a few hours, and the task closes when the page's images are served in a modern format (WebP/AVIF). If the check still fails, the task returns to New with a note; when it passes, the task is listed under Resolved technical issues on Impact reports. To check sooner, use Re-crawl affected pages on the issue.
How the fix is verified
Re-crawl; the task closes when the page's images are served in a modern format (WebP/AVIF).