How to Fix "Improve Image Delivery" in WordPress Without a Plugin

Five terms this guide uses

Everything below rests on five words. If you know them, skip ahead.

• PageSpeed Insights (PSI) and Lighthouse. Lighthouse is Google's page-testing engine; PageSpeed Insights is the web page at pagespeed.web.dev that runs it for you. The advice rows PSI shows are Lighthouse's, so the two names mean the same report.

• Format. The kind of image file. JPEG and PNG are the old universal ones. WebP (2010) and AVIF (2019) store the same picture in a smaller file, which is why speed tests ask for them. Switching format changes nothing about the picture, only how it is packed.

• Sub-sizes. The smaller copies WordPress makes of every image you upload (thumbnail, medium, large and so on). The file you uploaded is kept; the copies are what your posts mostly show.

• LCP (Largest Contentful Paint). How long the biggest thing in the first screen takes to appear. Google's "good" line is 2.5 seconds for most visitors (web.dev). On most WordPress pages the biggest thing is an image, which is why image rows sit next to LCP in the report.

• Bytes per pixel. File size divided by the number of pixels in the picture. A 300 KB photo that is 1,024 by 768 pixels is 0.38 bytes per pixel. PageSpeed thinks in this unit, and once you do too, the report stops being mysterious.

"Improve image delivery" is the warning that used to say "Serve images in next-gen formats"

In October 2025 Google's Lighthouse 13 removed four separate image audits from its report, "Serve images in next-gen formats" among them, and replaced them with a single insight called Improve image delivery, with PageSpeed Insights due to follow within the week (Lighthouse 13 release notes). The Chrome documentation for the old audit now opens with a banner saying it has moved into the new insight. If you are following a tutorial that tells you to look for "next-gen formats" in the Opportunities list, that list no longer exists; look for "Improve image delivery" in the report's Insights section instead.

The new insight is the four old ones in one row, and each image it lists carries one of four messages. You will see them verbatim in PSI, so here they are with what each one means for a WordPress site:

The row that fixes most of the page is almost always the first one, and this guide is mostly about it. The third one is about size rather than format, and it matters just as much; it is why "convert everything to WebP" alone often leaves the row in place.

How PageSpeed decides an image is too big

PageSpeed does not convert your image and measure the result. It applies a yardstick: about 0.167 bytes per pixel, the size it assumes a good AVIF encoder would reach, and it reports the gap between your file and that figure as the "estimated savings". Anything under 4 KiB of estimated saving is left off the list. That is the whole mechanism, and knowing it changes how you read the report.

The yardstick comes straight from the insight's source code in Chrome DevTools, which Lighthouse shares (ImageDelivery.ts). The target is written as 2 bytes per pixel (a plain bitmap with 4:2:2 color) divided by 12, a 12:1 compression ratio, and the estimate for each image is simply its size minus 0.167 times its width times its height, where width and height are the image file's own pixels, not the space it fills on the page. A JPEG or PNG above the target gets the "modern format or compression" message; a WebP or AVIF above it gets the "compression" message. Three more rules from the same file are worth knowing:

• The 4 KiB floor. Images whose estimated saving is 4,096 bytes or less are not shown at all. Small icons and thumbnails fall out of the report on their own.

• A 12 KiB allowance for responsive images. The "larger than it needs to be" check ignores up to 12 KiB of waste when the image has a srcset or sits in a <picture>, because an effort was made. WordPress adds srcset to the images it serves from the Image block, so a WordPress post gets this allowance; a hard-coded theme banner does not.

• GIFs are judged by size alone. Anything over 100 KiB is flagged for video, whatever its pixels.

Two consequences follow. First, the "estimated savings" figure is the file's distance from a 12:1 ideal, not a measurement of what any particular conversion will save you; a detailed photograph compressed to a quality you would be happy to publish will often land above 0.167 and stay on the list, smaller than before. Second, pixels are the lever the formula rewards most. Halving the width quarters the pixel count and quarters the target along with it, which is why the step order later in this guide is size first, encoder second, format third, the same order the insight's own documentation gives (Improve image delivery).

Work it on a real number. A 1,024 by 768 photo is 786,432 pixels, so the target is about 131 KB. WordPress's own quality-82 copy of a busy garden photo at that size is 296 KB (0.38 bytes per pixel), and PSI would show roughly 165 KB of estimated savings next to it. Convert the same copy to AVIF at an automatic quality and it becomes 178 KB; the row shrinks to about 47 KB but does not vanish. Take the AVIF down to quality 45 and it is 96 KB, under the target, and the row goes. Whether you want the row gone or the page fast is a decision this guide comes back to in the benchmark section.

What WordPress does with your images by itself

WordPress accepts WebP and AVIF uploads, makes JPEG copies of JPEGs at a fixed quality, and converts nothing to a new format unless code tells it to. Here is the current behavior, version by version, so you know what you are working with and what the plugins are selling.

It accepts WebP (since 5.8) and AVIF (since 6.5). From WordPress 5.8 you can upload and use WebP images like any JPEG (WordPress 5.8 adds WebP support); from 6.5 the same is true of AVIF, provided your host's image library can decode it (WordPress 6.5 adds AVIF support). You can check your own server under Tools → Site Health → Info → Media Handling, where the supported formats are listed. Many hosts still run an ImageMagick or GD without AVIF; on those, an AVIF upload is refused or arrives without its sub-sizes, which is one reason WebP remains the safer "just upload it" format.

It keeps the format you upload. The 5.8 announcement says it plainly: by default WordPress creates the sub-sized copies "of the same type as the uploaded file". Upload a JPEG, get JPEG copies; upload a WebP, get WebP copies. There is a developer filter (image_editor_output_format) that can turn JPEG uploads into WebP or AVIF copies, and a plan to switch it on by default was reverted before WordPress 6.1 shipped in 2022 (the Make WordPress thread). Nothing in core has changed that since. This is the fact the plugin market rests on, and the fact that makes the plugin-free route work: if you upload the modern format, you get the modern format.

It makes several copies at quality 82. A default install generates a thumbnail (150 pixels), medium (300), medium_large (768 wide), large (1,024), and, since 5.3, two larger copies at 1,536 and 2,048 pixels for high-density screens. Any JPEG wider or taller than 2,560 pixels is also scaled down to 2,560 and saved with a -scaled suffix, and that scaled copy is what "Full Size" means in your posts; the file you uploaded is kept on disk untouched (big image handling in 5.3). Every JPEG copy is written at quality 82, WordPress's default since 4.5. That quality is reasonable; the encoder behind it is the limiting factor, as the benchmark below shows.

Since 7.1 it does the resizing in your browser. WordPress 7.1 (August 2026) moved resizing, compression and sub-size generation to the browser on Chrome and Edge, falling back to the server on other browsers. The JPEGs it writes are about 15% smaller than the old server-side ones, HEIC photos from an iPhone are converted to JPEG before upload with the original kept alongside, and AVIF uploads work even on hosts whose server cannot decode AVIF (client-side media processing dev note). Format conversion still happens "only if image_editor_output_format says so", so 7.1 changed where the work happens, not what it produces. Our Quick Answer on what WordPress 7.1 optimizes natively without a plugin covers the full list, including what it still decides for you.

It never touches what is already in your library. No WordPress version re-encodes existing uploads. Whatever you change today applies to new uploads; the two-year-old hero on your home page stays exactly as it was until you replace it. That is also true of the first-party conversion plugin (section 10), which is why the manual route is usually the right one for a live site: the images PageSpeed names are the ones worth your time.

Which file your visitors actually get

Your visitors almost never download the file you uploaded. They get one of WordPress's copies, chosen by the Image block's Resolution setting and the browser's screen width, and the fix has to land on that copy.

Open any post, click an image, and look at the block sidebar (the Settings button next to Save or Publish opens it if it is hidden). Under the Settings tab there is a Resolution choice, with "options that may include Full Size, Large, Medium and Thumbnail depending on what your theme supports and the size of the originally uploaded image" (Image block documentation). Pick Large and the post embeds the 1,024-pixel copy; pick Full Size and it embeds the scaled 2,560-pixel one. WordPress then adds a srcset listing the smaller copies so a phone can take the 768 or 300 instead. Theme header images, sliders and page-builder backgrounds usually bypass all of this and load whatever file they were given, which is why they are so often the biggest row in the report.

So when PSI lists garden-1024x768.jpg, it is telling you three things at once: the post uses the large copy, the copy is a JPEG because the upload was, and the copy is heavier than it needs to be. Replacing the upload with an AVIF or WebP of the right width replaces every copy below it, because WordPress makes the new copies in the new format. Replacing a theme image replaces one file. Either way, the filename in the report tells you which it is: a -WIDTHxHEIGHT suffix is a WordPress copy, -scaled is the 2,560 version, and a name with neither is the original file or a theme asset.

One photo through WordPress: the numbers

We took one iPhone photo, made the copies a default WordPress install would make of it, and converted each copy before upload. The result is that WordPress's copies run at roughly double PageSpeed's yardstick, conversion removes a third to nearly half of the bytes, and a well-encoded JPEG did as well as AVIF on this photo. Here is the run in full, so you can judge it against your own images.

The photo is a 2,576 by 1,932 pixel garden shot, 1.79 MB, full of leaves and twigs: the kind of detail that compresses worst, so these are conservative numbers. We produced the -scaled, 1536, large and medium_large copies as JPEG at quality 82, the WordPress default, then sent each copy to Mochify's API with no quality setting (automatic) and no resizing, once per output format. The "PSI gap" column is the file's distance from the insight's 0.167 bytes-per-pixel target, which is the figure PageSpeed would show as estimated savings.

Four things in that table are worth more than the percentages:

1. WordPress's copies sit at 0.32 to 0.38 bytes per pixel, about twice the 0.167 PageSpeed treats as efficient. A default WordPress photo is flagged at every size, however carefully you set the quality, because the encoder behind it is a general-purpose libjpeg or ImageMagick at a fixed setting. WordPress 7.1's browser-side encoder closes some of that gap (about 15% by the project's own figure), not most of it.

2. The encoder mattered more than the format. Mochify's JPEG output uses Google's jpegli encoder, and on this photo it beat WebP at every size (177 KB against 205 KB at 1,024 wide) and came within a kilobyte of AVIF. It is still a plain .jpg that every browser, crawler and email client has opened since the 1990s. If the compatibility questions in section 8 give you pause, this is the way out: a smaller JPEG is most of the win and none of the risk.

3. A busy photo stays on the list at automatic quality. Every converted file in the table is still above 0.167 bytes per pixel, so PSI would still show the row, with the figure cut by 70 to 80%. Dropping the 1,024 AVIF to quality 45 took it to 96 KB, 68% below WordPress's copy and under the target, and in a side-by-side crop of the busiest foliage we could not tell the four versions apart. That is one photo, one region and our eyes, so treat it as a demonstration rather than a rule: lower the quality until you can see it, then step back one notch. On a product shot against a plain background the automatic encode is usually already under the target.

4. Pixels did more than any format. The large copy is 5.4 times smaller than the -scaled one before anything is converted. If a 2,560-pixel file is being sent to a 700-pixel column, no format change competes with fixing that first.

The whole run is recorded in our research notes with the exact byte counts; the numbers above are for this photo, on this day, and your photos will differ in degree but not in shape.

Try the same comparison on one of your own images in Mochify: drop the file in, ask for "convert to AVIF" and then "convert to JPG", and compare the sizes against what is in your uploads folder.

The plugin-free fix, step by step

The fix is five steps for each image PageSpeed names: find the file, decide its width, convert it, upload the new one in place of the old, and give the hero image its priority. Done for the handful of images on your most-visited pages, it removes most of the row and most of the LCP problem without touching your plugin stack.

Step 1: list the images PageSpeed names

Run PageSpeed Insights on the exact URL (the mobile tab first; that is the one Google weights). In the report's Insights section, open Improve image delivery. Each row is one image: its URL (with a small preview), the estimated saving in KiB and the message from the table in section 2. Copy the URLs. If the page passes, the insight is listed among the passed checks and you can stop; this guide is only needed for pages where it does not.

Read the filenames before you do anything else. hero-scaled.jpg is the 2,560-pixel copy of an upload, which means the page is embedding "Full Size". garden-1024x768.jpg is the large copy. header-bg.png with no suffix is a theme or page-builder asset, not a Media Library copy. A row that says "larger than it needs to be (2560 x 1920) for its displayed dimensions (720 x 540)" is a size problem first and a format problem second.

Step 2: decide the width each image needs

An image needs to be as wide as the widest space it fills, times two at most for high-density screens. A photo in a blog column that is 720 pixels wide needs a 1,440-pixel file at the outside and is well served by WordPress's 1,024 large copy. A full-width hero on a 1,920-pixel desktop needs about 1,920. Nothing on a normal page needs 2,560, and nothing needs the 4,032 pixels an iPhone shoots. For the hero specifically, our guide to hero image size and LCP walks through the three sizes that matter and why "under 200 KB" is a quality decision rather than a format property.

The simplest version: upload images at the largest width the page will show them, and let WordPress make the smaller copies. The full version, for a hero that must be fast on phones too, is a 1,920-wide file plus a separate 800-wide crop served through <picture>, which section 9 covers.

Step 3: convert the image before it goes into WordPress

Convert the original file, not the copy PageSpeed listed. The original is in your Media Library: open the image's attachment details and use its File URL (for a photo over 2,560 pixels that link points at the -scaled copy, and the untouched original has the same name without the suffix). Theme assets live in the theme's own folder or settings. Resize it to the width from step 2 and save it as AVIF or WebP, or as a jpegli-encoded JPEG if you want zero compatibility questions. Section 13 shows the Mochify prompts for this; any converter that lets you set a width and a format will do the job.

Two rules while you are there. Strip the metadata unless you need it: a phone photo carries a few hundred kilobytes of thumbnail, GPS and camera data that no visitor sees, and WordPress keeps everything in the original file (our Quick Answer on stripping EXIF data from WordPress uploads covers what that does and does not do for SEO). And if the photo came from an iPhone as HEIC, convert it yourself rather than letting WordPress 7.1 turn it into a JPEG at upload; HEIC to JPEG or WebP for WordPress explains which target to pick.

Step 4: upload the new file and point the page at it

WordPress does not overwrite the file you already uploaded; you add the new one and swap it in. In the block editor, click the Image block, click Replace in its toolbar, choose Upload, pick the converted file, and set the block's Resolution to Large (or Full Size if the column really is that wide). For a featured image, remove it in the post sidebar and set the new upload. For a theme header or background, use the theme's own control (the Customizer, the Site Editor or the page-builder's image field) and give it the new file. The old file stays in your uploads folder, which costs you nothing; delete it from the Media Library later if you like.

If your host's server cannot encode AVIF (section 4), an AVIF upload may arrive without its smaller copies, or be refused outright. On WordPress 7.1 in Chrome or Edge the upload goes through regardless, because the browser does the work; on older versions or other browsers, use WebP for the upload or ask your host to enable AVIF in ImageMagick. Site Health tells you which case you are in before you try.

Step 5: give the LCP image its priority

Converting the hero makes it small; telling the browser to fetch it first makes it early. Since 6.3, WordPress adds fetchpriority="high" to the image it judges most likely to be the largest in the first screen and keeps loading="lazy" off the first images it outputs (image performance in WordPress 6.3). Check that your hero got the first and not the second (section 11 shows how to look), and if a theme or builder has lazy-loaded the hero, fix that before anything else. Our explainer on fetchpriority versus preload for the LCP image covers the choice, and preloading an AVIF hero in WordPress covers the preload tag for the hero you have just converted.

That is the whole fix for the pages that matter. For a site with thousands of images and a theme that pulls from the uploads folder directly, the same idea scales as a command: our guide to converting a site's images to WebP and AVIF in one command does the batch and keeps new files converted.

AVIF, WebP or a better JPEG for WordPress?

For an image you upload straight into the Image block, choose WebP or a well-encoded JPEG; reserve AVIF for the hero and other large photos where its extra savings are worth a fallback. The reasoning is about who cannot open what, and in 2026 the gap is small but not zero.

In caniuse's September 2026 data, 97.18% of global users have a browser that opens WebP and 96.35% one that opens AVIF (caniuse WebP, caniuse AVIF). AVIF arrived in Safari with iOS 16, so the 3 or 4 visitors in 100 who cannot open it are typically on phones that stopped updating around 2022, on televisions and in locked-down office browsers (an illustration of the kind of browser, not a measured breakdown). If you upload an AVIF and put it in the Image block, those visitors see a broken image. If you upload a WebP, a slightly smaller group sees a broken image. If you upload a JPEG, nobody does.

That gives three honest positions:

The jpegli row surprises people. The format comparison most guides reprint, WebP 25-34% smaller than JPEG and AVIF up to 50% smaller, is measured against a 1990s JPEG encoder; against a modern one the gap closes, and on our garden photo it closed completely. For the full picture of what each format does well, including transparency and the newly arrived JPEG XL, see our WebP vs AVIF vs JPEG XL comparison.

The <picture> route in the block editor, and when you do not need it

You need <picture> only when you want AVIF on a page that must still work for the last 4% of browsers, and in WordPress you get it either from the first-party plugin or from a Custom HTML block. For most images you do not need it at all: a WebP or a good JPEG in the ordinary Image block is the right amount of engineering.

When you do want it, this is the smallest markup that works, pasted into a Custom HTML block in place of the Image block:

<picture>
  <source srcset="/wp-content/uploads/2026/10/hero-1920.avif" type="image/avif">
  <img src="/wp-content/uploads/2026/10/hero-1920.jpg"
       alt="Describe the picture"
       width="1920" height="1080"
       fetchpriority="high" decoding="async">
</picture>

The browser takes the AVIF if it can open it and the JPEG if it cannot; it downloads one of the two, never both. Upload both files to the Media Library first and copy their URLs from the attachment details. The width and height stop the layout jumping, and fetchpriority="high" belongs only on the one image in the first screen. The trade is that a Custom HTML block has no Resolution setting and no automatic srcset, so the responsive sizing WordPress normally does for you is now yours to write; our guide to the HTML picture tag covers the full snippet with multiple widths, art direction and the four rules that make it render. If the image is a CSS background in your theme rather than an <img>, <picture> cannot reach it; WebP fallbacks for CSS background images is the route for those.

A broken case and its fix, because it is the one people hit: you paste the block, the page shows the JPEG everywhere, and PSI still lists it. Open the page source (right-click, View Page Source, search for <picture) and check the type attribute reads exactly image/avif and the AVIF URL returns a file when you open it in a new tab. A mistyped type or a 404 on the AVIF silently falls through to the JPEG, which is the fallback doing its job.

If you would rather WordPress did it: the first-party plugin

If you want every new upload converted automatically, the plugin to install is WordPress's own Modern Image Formats, published by the WordPress Performance Team. It adds WebP and AVIF output for media uploads inside WordPress, generates AVIF when your host supports it and WebP otherwise, lets you choose between the two under Settings → Media, and has an option to output fallback images in the original format alongside the modern ones (Modern Image Formats on wordpress.org). At the time of writing it is at version 2.7.1 with over 100,000 active installations and is tested up to WordPress 7.1.3.

Two things to know before you reach for it. It converts new uploads only; everything already in your library stays as it is unless you regenerate the sub-sizes with a tool like WP-CLI's wp media regenerate or a regenerate-thumbnails plugin, which on a large site is a long job with real disk-space consequences. And it converts at the server's or browser's quality setting, with a general-purpose encoder, so you get a WebP or AVIF version of the 0.3-bytes-per-pixel copies rather than a file you chose. It is a good, free, first-party answer to "make it automatic". It is not a reason to skip the manual fix on the pages that matter, because those images are already uploaded.

The commercial plugins the AI Overview recommends do the same conversion plus bulk re-encoding of the existing library, usually through a paid service with a monthly quota. The support threads ranking for this warning are a fair preview of the failure modes: images "not being converted" with no explanation, converted copies that exist in the database but not on disk after a staging-to-production move, and a bulk run that stops at "Your monthly limit has been exceeded" and leaves half the library done. None of that is an argument against plugins in general. It is an argument for knowing which images actually matter, fixing those by hand, and only automating what you can verify.

Check it worked, click by click

Verification is three checks: the browser is receiving the new file, PageSpeed agrees, and WordPress can keep doing it for the next upload. Do all three; the forum threads are full of people who did one.

The browser. Open the page in Chrome. Right-click anywhere, choose Inspect, click the Network tab, click the Img filter button, then reload the page. Each image appears as a row; the Type column reads avif, webp or jpeg, and the Size column is what was actually transferred. Right-click any column header, tick Priority to show that column, and check the hero's row reads High and that it loaded in the first few rows, not after a scroll. If the Type still says jpeg for an image you converted, the page is pointing at the old file: go back to step 4.

PageSpeed. Re-run the same URL on pagespeed.web.dev. PSI tests a fresh load, so there is no cache to clear on your side, but if your host or a caching plugin serves a stored copy of the page, purge it first or the test sees the old HTML. Open Improve image delivery again. The images you fixed should be gone from the list or carry a much smaller figure (for the reason in section 3). Check the LCP figure in the field data at the top of the report over the following weeks rather than the lab figure on the day; that is the one that comes from real visitors.

WordPress. Under Tools → Site Health → Info → Media Handling, confirm the image library and the formats it supports, so you know whether the next AVIF upload will get its sub-sizes. Then upload one more converted image into a draft post and check its sub-sizes exist in the Media Library's attachment details. If they do, your workflow is now the default for every future upload, which is the point.

When the warning will not go away

When the row persists after a conversion, the page is almost always still pointing at the old file, the file is bigger in pixels than its slot, or the image never went through the Media Library at all. Work down this list before changing anything else:

• The URL in PSI is not the file you uploaded. Compare the filename in the row with the one in your Media Library. A -scaled or -1024x768 suffix on a .jpg after you uploaded an .avif means the block is still embedding the old attachment. Replace it (step 4).

• The row says "larger than it needs to be". That is pixels, not format. Resize to the displayed width times two at most and re-upload. Converting a 2,560-pixel file to AVIF and serving it in a 700-pixel column will still be flagged.

• The image is not a Media Library image. Theme headers, sliders, page-builder backgrounds, logos baked into the theme and images injected by other plugins are files on disk that WordPress never processed. Find them in the theme or plugin settings and replace the file itself.

• A cache is serving the old page. Purge your caching plugin and your CDN after a replacement, then re-test. The page can be fixed while the test is still reading yesterday's HTML.

• The image is a lazy-loaded hero. A hero with loading="lazy" is late regardless of format and shows up as an LCP problem rather than an image row. Remove the lazy loading from the first-screen image; most themes allow it per image or per block.

• The file is a GIF. Replace an animated GIF over 100 KiB with a short MP4 or WebM, or with a still image if the animation was decorative. Our MP4 to WebM guide covers the video side.

• The row is now small and you want it gone. Lower the quality until you can see a difference in the areas you care about, then step back once. On a detailed photo that may mean an AVIF around quality 45 to 50; on a product shot the automatic setting is usually enough. Or accept a small row: the page is already fast, and the figure is a yardstick, not a verdict.

Mochify Workflow: converting WordPress images before upload

Mochify is built for the "give WordPress a finished image" route: you describe what you want in plain English, it converts, resizes and compresses in one pass, and you upload the result like any other file. Here is the workflow for the five steps above, on each of the surfaces that fit a WordPress job.

Privacy, for client sites and product photos: images sent to Mochify travel to api.mochify.app, are encoded in memory, and are wiped as soon as the result is returned; nothing is written to disk, no log holds file data, and nothing is used to train AI. That is true of the web app, the extension, the CLI and the API alike. (It is the video tools that never leave your browser at all; images and PDFs make the round trip.) A one-off library clean-up that outgrows the free allowance fits a $2 Day Pass: 100 uploads within 24 hours, 25 at a time, files up to 75 MB, no account needed.

Cheat Sheet

FAQ