No, we’re not talking about images of disgusting things, like moldy bread, or rotten milk. Rather, we want to unpack the impact of poorly optimized images, and what you can do about them. When you look at the “weight” of a page, images are usually the biggest slice of the pie, and cannot be ignored. When I first released EWWW Image Optimizer back in 2012, most folks were focused on image compression. But today, there are a lot of things you can do, some things you maybe shouldn’t, and it can be difficult to make sense of it all.
ATF and LCP
Before we get too far, let’s explain a few important terms. You’ll see these commonly if you run your site through an online speed test like GTmetrix or PageSpeed Insights. The first is “above the fold”, which is the portion of the newspaper above the fold, of course! Okay, okay, that’s not really what it means with websites, but that’s where we get the term from. “Above the fold” refers to the portion of your web page that a visitor sees without scrolling.
Another term that ties into that is LCP, or Largest Contentful Paint (element). This is the biggest piece of content that is above the fold, and can be a container element like a ‘div’ or a paragraph or an image. Testing sites measure how long this takes to be loaded and rendered, or “painted”, as it typically reflects when the majority of the above the fold content is ready for the visitor to read or view.
Common Recommendations
Like I said before, back in the day, most sites had one recommendation, “properly encode images”. Now, you’ll probably see a whole slew of things related to images. We also need to properly size images, use explicit with/height on images, preload our LCP image, serve images in next-gen formats, and don’t lazy load the LCP image. Whew!
If that’s a bit overwhelming, don’t fret! We’ll tackle the most common recommendations, why each one matters, and how you can solve it–if it’s even worth solving.
Squeezing Every Last Drop (Efficiently encode images)
I’ve talked before about how image compression works, but here’s the short version. All web-friendly images are compressed. That is, if you use JPG, PNG, GIF, WebP or even AVIF, the image is being compressed. However, most images are not saved with the ideal settings, or with the best algorithm. Thus they are not “efficiently encoded”. With some rare exceptions, a photo taken by a camera (or phone) can be trimmed by at least 30% without changing the size, and without any noticeable loss in quality.
There are two types of image compression: lossy and lossless. The latter makes an image smaller without changing any of the visual data, no pixels are harmed in the process. On the other hand, lossy compression techniques are all over the map. You’ll see everything from “visually lossless”, where advanced algorithms tweak the visual data to make it easier to compress, to visual hacksaws that just toss quality out the window. Certain testing sites, who shall remain nameless, have even advocated re-saving your JPG images at quality level 50, gross…
Why should you care?
Making your images smaller makes your web page load faster, though this can be somewhat mitigated by lazy loading. We’ll talk more about that in a moment, but you still need above the fold images to be as efficient as possible so they don’t bog down the page. You should also compress other images so that when they ARE lazy loaded, they load quickly and the user doesn’t scroll past large blank sections thinking “Huh, I wonder what was supposed to be there?”
How to do it?
There are a ton of image optimization plugins for WordPress, and though I could just tell you to use EWWW IO, I want you to have the whole picture. One feature that several of the IO plugins have is an image-optimizing CDN. Basically, this allows you to compress and speed up your images (on the fly) without altering any of the originals stored on your web server. EWWW IO has the Easy IO CDN, and a couple other options are ShortPixel and Optimole. Jetpack even has a free “image accelerator” (formerly Photon, and they keep renaming it), though it has some weaknesses we’ve fixed in Easy IO, so you get what you pay for.
For local image optimization–that is, compressing the images that live on your server–nearly all image optimization plugins have a lossless option, except Resmushit, which merely re-compresses images with jpegoptim. You can usually get 8-10% savings with lossless compression, but if you want the best quality/size ratio (50% or better), use the premium/lossy compression in EWWW Image Optimizer, TinyPNG, Imagify, or Shortpixel.
They all feature a bulk tool that will help you compress your existing images, but there’s an important thing to keep in mind. If you decide to use one of the above image-optimizing CDNs: you only really need to compress your local images to save storage space. That’s the beauty of the CDN-based solutions, one click and you’re done… at least with compression. For the rest of the image optimization steps, it all depends on the plugin, as we’ll see moving forward.
Sleepin’ on the Job (Lazy Load)
Lazy loading simply means telling the browser not to load images until they are visible on the page. Why? Since we want the above-the-fold part of your page to load quickly, and images are the heavy-weights of the page, we should tell the browser to wait and download offscreen images later. Lazy loading is now built into most browsers, and WordPress has built-in support for this browser-native lazy loading, so… I guess we’re done?
Unfortunately, there are a few things that we have to look out for with lazy load. Remember how we wanted the browser to download offscreen images later? That means we want above the fold images to load right away, or at the very least, if an image is the LCP element, we should load that right away. However, keep in mind that the browser renders the page before it loads images (normally), so other elements might get shifted around when the images do load. Thus we have this precarious balancing game between showing images ASAP to improve user experience, but those same images might move things around and drive your visitors crazy.
Is there a better way?
To solve those issues, EWWW Image Optimizer has one of the few (only?) lazy loaders that will replace your images with right-sized placeholders. The placeholders are the same size as the initial image, and thus allow the browser to instantly render the page as it should be, with no layout shifts when the images actually load. WP Rocket’s lazy loader can use SVG placeholders that are similar, but we’ve seen some issues with that approach, so EWWW IO uses inlined PNG placeholders instead.
EWWW IO also has auto-scaling built into the lazy loader, so that you don’t accidentally load an image that is 3x too large for the space (or worse). So, if you’re absolutely certain you have your images the right size (for all device sizes), and don’t mind tagging all your LCP or above the fold images with the ‘skip-lazy’ class, have at it. As a bit of a teaser, we’re planning to add a tool to help you target your LCP images and make sure they are properly scaled, to make all of this a bit easier. Stay tuned!
Tipping the Scales (Properly Size Images)
Well, since we’re talking about scaling images, we might as well tackle this behemoth. At the root, this seems simple enough. If we have a 300 x 300 px (pixel) space for an image, then we should make sure the image is 300×300, so we aren’t wasting time downloading extra pixels. It gets more complicated when we add in high-dpi devices, like most mobile devices that have 2x or 3x the pixels available. So now we need a 600×600 image, right? But we don’t want to load that for everyone do we? Especially not, given that such a 600×600 image actually has 4x more pixels than the 300×300 px image.
Fortunately, img elements have had responsive support for a long time via the srcset & sizes attributes. When used properly, this should put an end to our woes, but alas, it isn’t easy to get right. Worse, Google’s PageSpeed Insights will yell at you for giving their simulated 2x device a 2x image. Yes, really… at least it is still that way in early 2026. But they’ve stumbled onto something–and I do mean really stumbled, because this wasn’t their intent–which is that mobile devices often have the slowest connections of anything out there. So why are we shoving 4x (sometimes 9x) the pixels down a mobile connection?
What to do, what to do?!
There are a few things, the first of which is to select the proper size when adding an image to a post or page. When you’ve added an image to your site, WordPress generates various scaled-down versions. That way, you can select large, medium, or thumbnail, whichever fits the space best without being distorted.
Second, if you’re a developer, and/or building your own theme, you can customize the srcset markup for your images manually. We’ve done this for our own site (example below), but only for above the fold images. If you’ve got the time, you can certainly do that for your whole site, and that would be ideal. You can also use the Resize Detection feature to highlight improperly scaled images on the front-end of your site (for admins only).
wp_get_attachment_image( $image_id, 'full', false, array( 'loading' => 'eager', 'sizes' => '(max-width: 991px) 90vw, (max-width: 1200px) 600px, (max-width: 1300px) 768px, 845px' ) );For everyone who isn’t an actual developer, there’s one last trick up our sleeves.
Okay, it’s not really up our sleeves, because I already talked about it. When you enable EWWW IO’s lazy load feature, you also have access to our exclusive auto-scaling option. In the free version, this modifies the aforementioned ‘sizes’ attribute to ‘auto’, so that the lazy loader can tell the browser exactly which image to load from the srcset listing. For images that don’t have srcset/sizes markup, you can activate the premium Easy IO CDN and it will work with the lazy loader to generate exact-sized images for every image on any display size.
We still haven’t addressed that 4x/9x issue though, have we? Well, actually we have. By default, browsers look at a srcset and choose an image based on the size of the space multiplied by the DPR ratio (2x or 3x). But our lazy loader will divide the sizes attribute based on the device, so that the browser will download a standard 1x image and not waste time with a larger image. That said, if you really want High-DPI images on your site, Easy IO does have a toggle for that. Just remember that it will cause images to load more slowly on most mobile devices.
The Next Generation (Image Formats)
Most folks have heard of ye olde image formats, like JPG, PNG, and GIF. If you haven’t, JPG is for photos, PNG is for decorative elements, icons, and logos, GIF is for animations–don’t use it for anything else, use PNG instead. You can also use SVG for icons, logos, and decorative bits, but that’s a topic for another day. Besides, I wouldn’t lump SVG in with the others since it hasn’t been supported by browsers as long and is still very relevant for modern site design.
There are a couple newer image formats that come with some pretty great bonuses, but also some drawbacks. The first on the scene was WebP, which can replace JPG for photos with it’s lossy mode, PNG images with lossless mode, and even GIF with animation ability. Wow, right?! The newer AVIF format does most of that, though it really shouldn’t be used for animations–use an actual modern video format, like VP8/VP9 (in an mp4 container). Those video formats are actually where WebP and AVIF started, as they were originally created to store thumbnails for their respective video formats.
But why?
While it’s nice that one format can replace all your other image formats, the real win is that the “next-gen” formats do all that with a smaller file size. In both WebP and AVIF, the lossy mode is the most impressive, with savings averaging 65% for WebP and over 80% for AVIF. You can get some solid savings in lossless mode too, 25% or so with WebP, but AVIF can have issues converting PNG images.
And how?
Now this is the real question, and can get tricky, though it doesn’t have to be. Some folks just export WebP (or AVIF) from their photo editing software, and upload WebP images to their sites. It’s the simplest, but does have some drawbacks, since not everything out there supports WebP, and may not even be an option with AVIF if your web server doesn’t support the format.
As for your visitors? All major browsers support both WebP and AVIF, but older versions of MacOS and Android lack support for these formats (around 5% of visitors). The same applies for Google Merchant Center, among others, as we still see around half of all requests to our CDN lacking WebP support. Though even then, it’s possible some bots and automated systems actually support WebP (or AVIF) and just don’t advertise it.
For those reasons, I recommend implementing fallback support with both JPG (or PNG) and WebP/AVIF. The only drawback is that now you’ve got up to three different image formats and need to only deliver those to supported browsers. The absolute easiest solution is our Easy IO CDN that takes care of the conversion to WebP or AVIF on-the-fly.
But if you want local WebP conversion, EWWW IO can do that for free, and it is the only plugin that can convert unlimited images to WebP on any server. You can make WebP copies of your images with the bulk optimizer, and then you can use one of the built-in delivery methods to get those to your visitors. Just keep in mind that you might end up using more disk space to store multiple copies of your images in both legacy and modern formats.
Now hold on, what about local AVIF conversion? We don’t support this yet, for one very big reason. Converting images to AVIF is slow and incredibly resource intensive, and could get you in trouble with your web host for using too many resources. Local AVIF may still happen at some point, as I have a hard time saying no forever, but for now that’s a non-starter. Besides that, with the incredible wins on the WebP front, it’s a tough sell to spend 6x (or more) in CPU for a 1/6 improvement.
Mind Reading (Preload Images)
I mentioned before that we want the LCP image to load right away, to minimize the chance for layout shifts. If you want to step things up just one more notch, you could even preload that LCP image, or your logo, or both. This allows the browser to start downloading those images as soon as it starts receiving the HTML in the very first HTTP request. For a logo, that’s a pretty easy thing to do, as the image file is likely pretty small, and we don’t have to worry a ton about mobile screen size vs. desktop.
However, with the LCP image, you might have different sized images using that srcset/sizes responsive markup we mentioned earlier. Then what? You can actually use a preload with srcset markup also, but that isn’t as easy to implement (yet). For a logo, we can preload that with SWIS Performance no problem. Just copy/paste the image URL into the SWIS Preload option, and you’re done. But we have a couple issues to watch out for, especially with larger images that need to scale based on screen size.
Watch out!
First, if you don’t already have srcset/sizes markup, you’re better off letting the auto-scaling in EWWW IO handle that image so you don’t waste a lot of bandwidth/time preloading bits that aren’t needed. Likewise, if you haven’t tweaked the responsive markup to be more accurate than the stock WP markup, you’re probably also better off using auto-scaling to deliver the best sized version to the visitor instead of preloading a bloated image.
In either case, certainly test it out and see what makes the most sense (or watch this video where I tested it). On ewww.io, we don’t preload any images even though we already have solid image markup in place with properly sized images. Instead, we preload our fonts to prevent too much layout shifting when the browser switches from the default system font to the web font we use throughout the site.
In testing with a (simulated) Slow 4G connection, the difference is only 50 ms between the start of preloading our fonts vs. when our above the fold images start to load–without preloading. Preloading web fonts makes a lot more sense, as you avoid the wait time of loading and parsing CSS that normally has to occur before fonts are loaded. For images that are already at the top of the page, that doesn’t work out so well in the real world. Testing ewww.io on GTmetrix confirms that preloading the LCP image would have zero impact, so they put it in the “no impact” audits.
There is Too Much… Let me Sum Up
That’s a lot to explain, and even then I’ve tried to keep it as short as possible. I know, you’re looking at me funny, because that wasn’t very short! So let’s sum up:
Compress your images with the bulk tool from your preferred plugin–you did choose EWWW Image Optimizer, right?? If you are going to use WebP and don’t care about disk space, lossless compression is fine, but make sure you enable WebP conversion before you run the bulk tool. On the other hand, if disk space is a premium, then you should also use premium compression in EWWW IO, run that bulk optimization and not generate WebP locally.
Instead of local WebP, activate the Easy IO CDN for automatic WebP conversion and delivery. Otherwise, choose a local delivery method for WebP (JS, Picture, or server-based rewrite rules). Lastly, turn on the lazy loader so that you can use the auto-scale option and make sure all your images are the best size for whatever device your visitor is using. And we’re done!
Send us an email if you have any questions or run into any trouble. Until then, happy optimizing!
