If you've run a site through PageSpeed Insights lately, you may have noticed the old image warnings are gone. "Properly size images", "Serve images in next-gen formats" and "Efficiently encode images" don't show up on their own anymore. Since Lighthouse 13 in October 2025, they're rolled into one insight called Improve image delivery.
Most guides online still use the old names. The fixes haven't changed, though.
What the insight checks
For every image on the page, PageSpeed Insights compares the file you sent with what an efficiently encoded image of the same displayed size would weigh. The difference is the estimated saving listed next to it. Anything that would save less than 4 KiB isn't listed.
A big saving almost always comes down to one of four things:
- The image is bigger than it displays, like a 2400 px photo in a 768 px column. (This used to be "Properly size images".)
- It's in an older format: a JPEG or PNG where WebP or AVIF would be much smaller. (Formerly "Serve images in next-gen formats".)
- It's barely compressed, such as a JPEG saved at quality 100 or a photo saved as PNG. (Formerly "Efficiently encode images".)
- It's an animated GIF. Video formats are far smaller for animation.
Two other old audits went elsewhere. Missing width and height attributes now show up under Layout shift culprits. "Defer offscreen images" was dropped completely, since browsers already give offscreen images low priority.
Find out which problem each image has
Expand Improve image delivery to see each flagged image with its file size and estimated saving. Why it was flagged comes down to two numbers: how wide the image displays, and how wide the file actually is.
In Chrome, right-click the image, choose Inspect, and hover over the <img> element in the Elements panel. The tooltip shows both the rendered size and the intrinsic size. If the intrinsic width is more than about twice the rendered width, the image is oversized. If the two are close and the saving is still large, it's the format or the compression.
Fix 1: serve images at the size they display
Someone on a phone doesn't need the same file as someone on a 27 inch monitor. Give the browser a few sizes to choose from with srcset, and tell it how wide the image will display with sizes:
<img
src="hero-768.jpg"
srcset="hero-480.jpg 480w, hero-768.jpg 768w, hero-1200.jpg 1200w, hero-1600.jpg 1600w"
sizes="(max-width: 768px) 100vw, 768px"
width="1600" height="900"
alt="Mountain trail at sunrise">The browser picks the smallest file that will still look sharp on that screen. A phone 390 px wide with a 3x display needs about 1170 pixels, so it takes the 1200 px file. A desktop showing the image at 768 px takes the 768 px one. If srcset and sizes are new to you, srcset and sizes explained walks through how the browser decides.
You'll need the files first. The responsive image converter turns one image into every width you need (480, 768, 1200 and 1600 px by default) and writes this markup for you. It never enlarges an image, so any width bigger than your original gets skipped.
Fix 2: use WebP or AVIF
WebP files are typically 25 to 35 percent smaller than JPEGs of similar quality, and AVIF often saves another 20 to 50 percent on top of WebP. Every current major browser supports both. iPhones before iOS 16 can't display AVIF, so keep a JPEG fallback.
That's what the <picture> element is for. The browser uses the first <source> it supports and falls back to the <img>:
<picture>
<source type="image/avif"
srcset="hero-480.avif 480w, hero-768.avif 768w, hero-1200.avif 1200w, hero-1600.avif 1600w"
sizes="(max-width: 768px) 100vw, 768px">
<source type="image/webp"
srcset="hero-480.webp 480w, hero-768.webp 768w, hero-1200.webp 1200w, hero-1600.webp 1600w"
sizes="(max-width: 768px) 100vw, 768px">
<img src="hero-768.jpg"
srcset="hero-480.jpg 480w, hero-768.jpg 768w, hero-1200.jpg 1200w, hero-1600.jpg 1600w"
sizes="(max-width: 768px) 100vw, 768px"
width="1600" height="900" alt="Mountain trail at sunrise">
</picture>Repeat sizes on every <source>. It's easy to forget, and without it the browser assumes the image fills the whole screen.
Fix 3: compress properly
For photos, a quality setting between 75 and 82 is usually impossible to tell apart from the original. Large background images can often go down to 60 or 70. Screenshots and images with text or sharp edges need more, around 85 to 90, or a lossless format.
Two more easy savings. Don't save photos as PNG: it's lossless, which suits logos and screenshots and wastes space on photos. And strip the metadata. Camera files carry EXIF data, sometimes including GPS coordinates, and re-encoding the image removes it.
Fix 4: replace animated GIFs with video
A few seconds of animated GIF can weigh several megabytes. The same clip as MP4 or WebM is usually a small fraction of that, and a muted, looping video behaves just like a GIF:
<video autoplay loop muted playsinline width="640" height="360">
<source src="demo.webm" type="video/webm">
<source src="demo.mp4" type="video/mp4">
</video>Browsers only autoplay muted video, and playsinline keeps iPhones from opening it full screen.
If your site runs on WordPress
WordPress already handles a lot of this for images in your posts and pages. It creates several sizes of every upload and adds srcset and sizes automatically. It has accepted WebP uploads since version 5.8, and AVIF since 6.5. When PageSpeed Insights still flags images on a WordPress site, it's usually one of these:
- Images inserted at "Full size". Pick Large in the image block settings unless the image really fills the screen.
- Background images set in CSS. Hero sections from themes and page builders often use
background-image, which can't usesrcset. Use an image block where you can, or upload a version that's already the right size. - Huge originals. WordPress scales uploads down to 2560 px, which is still far bigger than most layouts need. Resize before you upload.
Check your fix
Run PageSpeed Insights again. The lab test at the top updates right away. The field data, the section about what your real users are experiencing, is a 28 day rolling average, so it takes a few weeks to catch up.
One caution: don't lazy-load the main image at the top of the page. If PageSpeed Insights lists it under LCP request discovery, remove loading="lazy" from that image and add fetchpriority="high" instead.
To fix a batch of images in one go, drop them into the responsive image converter. It makes WebP, AVIF and JPEG at every width, lets you set the quality, and writes the <picture> markup. Your images never leave your device.