Modern WordPress sites drown in image bytes. A single high-resolution product photo or blog hero image can weigh three to five megabytes before optimization, and most themes load a dozen images above the fold. The good news: converting to WebP and deferring offscreen images can routinely cut your image payload by more than half without visible quality loss.
I've seen production sites drop from 8 MB to 3 MB of image data on the homepage after implementing the stack I'll walk through here. The bad news is that careless optimization introduces new failure modes—broken images for older browsers, layout shifts that wreck Core Web Vitals, and CDN cache misses that negate your gains.
This guide covers the opinionated production setup that works and the anti-patterns that waste your time.
Why WebP and lazy loading matter for hosting performance
WebP typically compresses 25 to 35 percent smaller than JPEG at equivalent perceptual quality and 25 to 50 percent smaller than PNG for images with transparency. That's not marketing—it's the delta you see in real file sizes after conversion.
Lazy loading defers images below the viewport until the user scrolls near them. For a long-form blog post with twenty images, the browser fetches maybe four on initial load instead of all twenty. The Time to Interactive metric improves, and users on metered connections save real bandwidth.
Together, these two techniques routinely achieve a 50 to 70 percent reduction in image payload on the first meaningful paint. That translates directly to faster load times on mobile networks and lower bandwidth bills if your host meters transfer.
The production-grade stack
Here's the setup that survives traffic spikes and doesn't break when iOS 12 Safari shows up in your logs.
Serve WebP with JPEG/PNG fallback
Always generate and store both WebP and the original format. Serve WebP to browsers that accept it via the Accept header or a <picture> element with fallback <source> tags.
Never delete the original JPEG or PNG. Older browsers, email clients, and some screen readers still need them. I've debugged support tickets where a site served only WebP and broke images in Outlook and legacy Android WebView.
The <picture> approach looks like this:
<picture>
<source srcset="image.webp" type="image/webp">
<img src="image.jpg" alt="Description" loading="lazy">
</picture>
The browser picks the first source it understands and falls back to the <img> if WebP isn't supported. This works without JavaScript and respects loading="lazy".
Convert at upload time, not on the fly
Generate WebP versions when the image is uploaded to the Media Library. On-the-fly conversion adds CPU load to every request and creates cache complexity.
Use ImageMagick or libvips on the server. Both are faster and produce smaller files than GD. A typical command with ImageMagick:
convert input.jpg -quality 82 -define webp:method=6 output.webp
Quality 82 to 85 is the sweet spot for photographic images. Method 6 is the slowest but yields the smallest files—acceptable for a one-time upload operation.
For PNG images with transparency, use:
convert input.png -quality 90 -define webp:lossless=false output.webp
Lossy WebP handles transparency and still compresses better than PNG.
Lazy load everything below the fold
Use native loading="lazy" on every <img> and <iframe> that isn't in the initial viewport. Modern browsers (Chrome 77+, Firefox 75+, Safari 15.4+, Edge 79+) handle this natively with no JavaScript.
<img src="photo.jpg" alt="Description" loading="lazy" width="800" height="600">
Always specify width and height attributes. The browser reserves the correct space before the image loads, preventing layout shift. Omitting dimensions is the number one cause of bad Cumulative Layout Shift scores after implementing lazy loading.
Eager-load the hero and above-the-fold images
Mark the first two or three images (your hero image, logo, and anything visible before scroll) as loading="eager" or omit the attribute entirely. Lazy-loading above-the-fold images delays Largest Contentful Paint and actually harms performance.
For the hero image specifically, add a fetchpriority="high" hint:
<img src="hero.jpg" alt="Hero" fetchpriority="high" width="1200" height="675">
This tells the browser to prioritize fetching that image over lower-priority resources like third-party scripts.
Offload to a CDN with automatic format negotiation
Serving images from your origin server wastes CPU and bandwidth. A CDN caches images at edge locations close to your users and can perform automatic format conversion based on the Accept header.
Cloudflare's Polish (on Pro plans and above) and BunnyCDN's Optimizer automatically serve WebP or AVIF to supporting browsers without changing your HTML. You upload JPEG, the CDN handles the rest.
If you're using a CDN without automatic optimization, configure your WordPress image URLs to point to the CDN hostname and ensure you've uploaded the WebP versions to the same paths.
Anti-patterns that sabotage performance
Half the optimization plugins in the WordPress repository implement these wrong. Here's what to avoid.
Don't lazy-load with JavaScript if native lazy loading exists
Old-school lazy loading libraries (like the original lazysizes.js) add several kilobytes of JavaScript, introduce a dependency, and delay image loads until the script executes. Native loading="lazy" is built into the browser, has zero JavaScript overhead, and starts working immediately.
The only exception is if you need to support browsers older than 2020. Check your analytics—if your Safari 14 traffic is below one percent, you don't need the polyfill.
Don't replace <img> with background images for lazy loading
I've seen plugins that convert inline images to CSS background-image on a <div> for lazy loading. This breaks right-click save, accessibility (no alt text), and SEO (search engines don't index background images).
Stick with <img> elements and use the native loading attribute or the <picture> element for format negotiation.
Don't serve WebP without a fallback
Some setups rewrite all image URLs to .webp extensions and rely on server-side rewrites or plugins to serve JPEG if the browser doesn't support WebP. This breaks when:
- A user saves the image or shares the direct URL.
- An email client or external service hotlinks the image.
- Your rewrite rules fail or the plugin deactivates.
Always keep the original image accessible at its original URL. Serve WebP through <picture> elements or content negotiation, never by replacing the canonical URL.
Don't use aggressive quality settings
I've debugged tickets where a site owner set WebP quality to 60 to maximize compression. The images looked terrible—visible blocking, color banding, loss of fine detail.
Quality 82 to 85 is the floor for photographic content. Below that, the artifacts outweigh the byte savings. For product photos where quality is critical, use 85 to 88.
Don't forget to set cache headers
If your CDN or browser doesn't cache the optimized images, you're converting them on every request. Set long cache lifetimes (one year is standard) and implement cache-busting via query strings or filename hashes when you replace an image.
<IfModule mod_expires.c>
ExpiresActive On
ExpiresByType image/webp "access plus 1 year"
ExpiresByType image/jpeg "access plus 1 year"
ExpiresByType image/png "access plus 1 year"
</IfModule>
Without this, your optimization work benefits only the first visitor. Everyone else fetches a fresh copy.
Measuring the impact
Before you declare victory, measure the actual payload reduction. Use the browser's Network tab filtered to images and compare the total transferred size before and after optimization.
A typical measurement:
- Before: 6.2 MB transferred, 18 images, 3.8s to Largest Contentful Paint.
- After: 2.1 MB transferred, 6 images eager-loaded (rest lazy), 1.9s LCP.
That's a 66 percent payload reduction and a 50 percent improvement in LCP. Core Web Vitals scores jump, and mobile users on slow connections see a real difference.
Check WebPageTest or Lighthouse after deploying. Look for:
- Reduced "Total Byte Weight" metric.
- Improved LCP (target under 2.5 seconds).
- No increase in Cumulative Layout Shift (target under 0.1).
If CLS increases, you forgot to set width and height attributes. Go back and add them.
Tools and plugins that do it right
If you're running a managed WordPress host, check whether they offer built-in image optimization. Many hosts (Kinsta, WP Engine, Cloudways) include automatic WebP generation and CDN delivery.
For self-managed setups, these plugins follow best practices:
- Imagify or ShortPixel: both convert to WebP at upload, preserve originals, and serve via
<picture>elements. - Perfmatters: adds native lazy loading attributes without JavaScript bloat and lets you exclude above-the-fold images.
- EWWW Image Optimizer: local conversion with ImageMagick or API-based optimization; supports WebP and AVIF.
Avoid plugins that promise "one-click optimization" without showing you what they change. Read the settings and verify that they're using native lazy loading, keeping fallbacks, and setting dimensions.
What about AVIF?
AVIF compresses another 20 to 30 percent smaller than WebP at the same perceptual quality. It's the next-generation format.
Browser support is nearly universal now (Chrome 85+, Firefox 93+, Safari 16+), but encoding AVIF is slow—significantly slower than WebP. If you're converting thousands of images, the CPU time adds up.
For new uploads, consider generating AVIF alongside WebP and JPEG. Serve AVIF first in your <picture> stack:
<picture>
<source srcset="image.avif" type="image/avif">
<source srcset="image.webp" type="image/webp">
<img src="image.jpg" alt="Description" loading="lazy">
</picture>
For existing libraries with thousands of images, batch-converting to AVIF is a heavy lift. Stick with WebP unless you have a specific need to squeeze every byte.
Handling images in page builders and block editor
Gutenberg's Image block respects the native loading attribute if your theme or a plugin adds it. Most modern themes (Twenty Twenty-Two and later) include it by default.
Page builders (Elementor, Divi, Beaver Builder) vary. Elementor supports lazy loading natively in recent versions; enable it in the settings. Divi and Beaver Builder may require a plugin or custom code to add the attribute.
If your page builder inserts images as background-image in CSS, you'll need a different approach—either switch to using actual <img> elements or accept that those images won't benefit from lazy loading.
FAQ
Does lazy loading hurt SEO?
No. Google's crawler executes JavaScript and scrolls the page, so lazy-loaded images are indexed normally. Make sure your images have proper alt text and are in the HTML, not loaded dynamically by JavaScript after a delay.
Will WebP work on all browsers?
WebP is supported by over 95 percent of browsers in use today. Serve a JPEG or PNG fallback for the rest using the <picture> element, and you're covered.
Can I lazy-load images in the slider or carousel?
Eager-load the first slide, lazy-load the rest. Lazy-loading the first slide delays its appearance and harms LCP. The user won't scroll to slides two through five immediately, so those can load on demand.
Why did my CLS score get worse after adding lazy loading?
You didn't set width and height attributes. The browser doesn't know how much space to reserve, so the layout jumps when each image loads. Add explicit dimensions to every <img> tag.
Should I use a plugin or do this manually?
Use a plugin unless you're comfortable editing theme templates and adding filters. A good plugin handles edge cases (galleries, featured images, post thumbnails) that manual code might miss.
What to check first
Start by measuring your current image payload in the browser Network tab. If images account for more than half your page weight, optimization will make a visible difference.
Convert new uploads to WebP automatically using a plugin or your host's built-in tools. Keep the original formats as fallbacks. Add native loading="lazy" to every image except the hero and above-the-fold content, and always specify width and height.
Offload delivery to a CDN with automatic format negotiation if your budget allows. Check your LCP and CLS scores in Lighthouse after deploying—if LCP drops and CLS stays low, you've done it right.
Skip JavaScript lazy-loading libraries, don't delete the original image formats, and never sacrifice quality for a few extra kilobytes of savings. These three mistakes cause more support headaches than any performance gain is worth.