Images are almost always the heaviest thing on a WordPress page, and they're usually the reason a site feels slow. A single unoptimised hero photo can outweigh every script and stylesheet on the page combined. The good news is that fixing images is the highest-leverage speed work you can do, because your hero is typically the Largest Contentful Paint element Google actually measures. This guide is practical and WordPress-specific: what image optimization really means, why images dominate your load time, exactly how to clear the "serve scaled images" warning, an ordered step list, and an honest call on WebP versus AVIF and plugin versus manual.
What is WordPress image optimization?
WordPress image optimization means reducing image file size and serving images at the right dimensions and a modern format like WebP or AVIF, so pages load fast without looking blurry. It's usually the single biggest win for your Largest Contentful Paint.
There are really two separate jobs hiding inside that one phrase, and confusing them is where most people go wrong. The first is compression, which makes the file smaller in bytes. The second is sizing, which makes the image's actual pixel dimensions match the space it fills on screen. You need both. A perfectly compressed photo that's still 4000 pixels wide squeezed into an 800-pixel slot is wasteful, and so is a correctly sized image that nobody compressed. Do both and the page gets dramatically lighter.
Why do images slow down WordPress the most?
Because images are usually both the heaviest files on the page and the Largest Contentful Paint element. The browser has to download and paint your hero before LCP is recorded, so a multi-megabyte image directly sets your loading score, no matter how clean the rest of the page is.
This is the framing that most image posts miss, so it's worth stating plainly. LCP is the vital that measures when your biggest visible element finishes loading, and on the vast majority of WordPress pages that element is the hero image at the top. So when people ask why their LCP is stuck, the answer is nearly always sitting right there in the header. Fix the hero and you move the metric that ranks. That's why image work pays back faster than almost anything else.
Images touch a second vital too, which is easy to forget. Cumulative Layout Shift measures how much your page jumps around while it loads, and an image without declared width and height is a classic offender. The browser doesn't know how tall the image will be until it arrives, so it reserves no space, and when the image finally loads it shoves everything below it down the page. The reader who was about to tap a button suddenly taps an ad instead. Setting explicit dimensions on every image fixes that, so optimised images quietly help both LCP and CLS at once.
There's also a real business cost to ignoring this beyond the metric. A heavy hero on mobile data can take seconds to appear, and plenty of visitors leave before it does. For an Australian audience browsing on phones, that first image is often the difference between someone staying to read and someone bouncing back to the search results. So image work isn't just a technical box to tick, it's directly tied to whether your traffic converts.
What does "serve scaled images" mean, and how do you fix it?
"Serve scaled images" means you're loading an image larger than the size it displays at, so the browser downloads extra pixels it then throws away. Fix it by resizing the image to its display dimensions and letting WordPress serve responsive srcset sizes so phones get a smaller file.
Should you lazy load your hero image?
No, and this trips up a lot of people who read "lazy load everything." Lazy loading delays an image until it's about to scroll into view, which is perfect for images below the fold. But your hero is on screen immediately and it's your LCP element, so lazy loading it actively delays the metric you most want to improve. Lazy load the gallery further down the page, never the image at the top. To be precise about the warning itself: "serve scaled images" and "properly size images" are sizing problems, not compression ones. The fix is dimensions, plus srcset so the right size goes to the right device.
Our WordPress speed optimization service compresses, converts and correctly sizes your media, with a guaranteed 90+ PageSpeed result or your money back.
How do you optimise images in WordPress step by step?
Resize each image to its display dimensions, compress it, convert to WebP or AVIF, enable responsive srcset sizes, and lazy load everything except the hero. Each step trims weight off your LCP element and the rest of the page, so re-test after you've worked through them.
- Resize before upload. Don't upload a 4000-pixel camera photo for an 800-pixel slot. Resize to the largest size it'll actually display at. (Cuts LCP.)
- Compress. Apply smart lossy compression to strip the file size down with no visible quality loss. (Cuts LCP and total page weight.)
- Convert to WebP or AVIF. Modern formats make the same image weigh far less than a JPEG or PNG. (Cuts LCP.)
- Enable responsive sizes. Let WordPress serve srcset variants so a phone downloads a small file and a desktop a larger one. This is what clears "serve scaled images." (Cuts LCP on mobile.)
- Lazy load below the fold only. Defer off-screen images so they load on demand, but leave the hero loading eagerly. (Cuts total weight without hurting LCP.)
That ordered approach mirrors the wider front-end work in our speed up WordPress guide, where images sit right at the top of the priority list precisely because they move LCP the most.
WebP vs AVIF, and plugin vs manual: which should you use?
AVIF makes smaller files at the same quality, but WebP has wider support, so the best setup serves AVIF where browsers accept it and WebP elsewhere. Manual conversion works for small sites, but a plugin that automates compression, conversion and sizing is the practical pick for most owners.
| Format | File size | Browser support | Best use |
|---|---|---|---|
| WebP | Smaller than JPEG/PNG | Very wide | Safe default for every site |
| AVIF | Smaller than WebP | Wide and growing | Maximum savings with a WebP fallback |
On the plugin question, there's no shame in automating this. A good optimisation plugin handles compression, format conversion and responsive sizing in the background every time you upload, which is far more reliable than remembering to do it by hand. Pair that with a properly configured cache and you've covered the two biggest loading wins on WordPress. Our caching plugin comparison covers the other half of that pairing.
Key takeaways
- Your hero is usually the LCP element, so image work is the biggest loading win.
- "Serve scaled images" is a sizing fix, not a compression one: resize plus srcset.
- Never lazy load the hero, because it delays the very metric you're improving.
- AVIF is smaller, WebP is more supported, so serve AVIF with a WebP fallback.