WordPress Images Not Optimized

Why images are the biggest speed lever

On most websites, images are the single heaviest thing the browser has to download, often more than all the code, fonts, and other assets combined. That makes them the highest-leverage place to speed a site up. Shave a few megabytes off the images on a page and you have done more for its load time than almost any other change, and you have done it without touching the design, the content, or the functionality. This is why image optimization is the first thing a good performance pass looks at: it is where the biggest, safest wins are.

The reason images are so often unoptimized is that the way they arrive on a site fights against it. A photo from a phone or a stock library is saved for quality and print, with far more data than a web page needs, and it is dropped into WordPress at full size. It looks fine, so nothing seems wrong, and the weight is invisible until you measure it. But every megabyte has to cross the network to each visitor, and on a phone on mobile data that is slow, so heavy images quietly drag down the experience and the Core Web Vitals score even when the page looks perfect.

The good news is that optimizing images is mechanical and reliable. It comes down to four levers, format, compression, dimensions, and delivery, and a properly optimized image is one that has had all four applied. WordPress handles some of these for you and leaves the most important one, format conversion, in your hands. The next section is exactly what WordPress does and does not do, because knowing the line is what tells you where your work begins.

What WordPress does and does not do for your images

WordPress has a real image pipeline that has grown over the years, and it does more than most people realize. Knowing the four things it does, and the one big thing it does not, saves you from both reinventing what is already handled and assuming a problem is solved when it is not.

The four image levers

A fully optimized image has had all four of these applied, and each maps to a specific PageSpeed audit. Missing any one leaves savings behind, which is why a page can still be flagged after you fixed only the obvious one.

One delivery note that belongs to the front end rather than the image file: the image at the top of the page, the LCP element, must never be lazy-loaded, because that delays the largest paint. Lazy loading is for images below the fold. The LCP image discovery question is covered in detail on the mobile speed fix, so this page stays on the image craft itself.

Which symptom matches yours

Find the row that matches what you see, usually a PageSpeed warning. Each one points to a specific lever and fix.

The six causes of heavy images

Unoptimized images on WordPress almost always come down to these six, often more than one at once.

WebP vs AVIF vs JPEG

The format choice is the biggest lever, so it is worth understanding the trade-off rather than guessing. The three formats sit on a scale of compression against compatibility.

The right approach is not to pick one but to serve a chain, AVIF first, then WebP, then JPEG, and let each browser take the best format it understands. A good optimization plugin generates the modern versions and serves the right one automatically, so you get AVIF where it works, WebP almost everywhere else, and JPEG as the safety net, with no broken images anywhere.

DIY vs hand it off

Installing one image plugin and bulk-optimizing is a reasonable self-fix. A page builder that strips srcset, a host without AVIF support, or a large library that must not break is where handing it off helps. If the left column matches you can likely do this. If the right column matches, get help.

How to diagnose it

Work in this order. The audits tell you which lever is failing before you change anything.

How to fix it

Each branch is one lever. Most sites need the first, and many need all three. Test with PageSpeed after each.

// Output generated sub-sizes as WebP instead of JPEG/PNG
add_filter( 'image_editor_output_format', function ( $formats ) {
    $formats['image/jpeg'] = 'image/webp';
    $formats['image/png']  = 'image/webp';
    return $formats;
} );

<picture>
  <source srcset="photo.avif" type="image/avif">
  <source srcset="photo.webp" type="image/webp">
  <img src="photo.jpg" width="1200" height="800" alt="...">
</picture>

// Lower the default image quality (82) for smaller files
add_filter( 'wp_editor_set_quality', function () {
    return 75;
} );

// Cap stored originals at 1920px instead of the 2560px default
add_filter( 'big_image_size_threshold', function () {
    return 1920;
} );

<!-- WordPress adds this automatically; a builder may strip it -->
<img src="photo-1024.webp"
     srcset="photo-480.webp 480w, photo-1024.webp 1024w, photo-1920.webp 1920w"
     sizes="(max-width: 600px) 480px, 1024px"
     width="1920" height="1080" loading="lazy" alt="...">

<!-- The top LCP image stays loading="eager", never lazy -->

A real image-optimization session

A composite from the image optimization work we do most weeks, with identifying details removed.

WordPress image optimization FAQ

Sources and further reading

Every technical claim on this page traces back to the WordPress core development notes or the web.dev image documentation.

• Make WordPress Core: WordPress 6.5 adds AVIF support (formats, requirements, no auto-conversion)
• Make WordPress Core: handling of big images in 5.3 (the 2560px threshold)
• Make WordPress Core: responsive images in 4.4 (automatic srcset)
• web.dev: Image performance (sizing, formats, lazy loading)
• web.dev: Choose the right image format