Image Optimisation WordPress: File Size, Format and Lazy Load
A client came to us with a WordPress site scoring 38 on PageSpeed Insights. The code was clean, the hosting was solid, and the theme was lean. The culprit was a 4.2MB hero image uploaded straight from a camera roll, sitting at 4000px wide on a screen that never needed more than 1200px. One file. Thirty-eight points lost. Image optimisation in WordPress is where most sites haemorrhage performance before a single line of code is ever questioned.
On this page
- Why Unoptimised Images Hit Rankings, Not Just Load Times
- The Format Decision: JPEG, PNG, WebP and When Each One Earns Its Place
- File Size vs Display Size: The Dimension Problem Most People Miss
- Compression Without Visible Quality Loss: Tools and Settings That Work
- Lazy Load in WordPress: What It Does, What It Breaks, and How to Set It Up Right
- Responsive Images and srcset: Letting the Browser Pick the Right File
- A Repeatable Workflow for Every Image That Enters Your WordPress Site
Why Unoptimised Images Hit Rankings, Not Just Load Times
Google measures page experience through Core Web Vitals, and Largest Contentful Paint is the metric images wreck most reliably. LCP tracks how long it takes for the biggest visible element on a page to render, and on most sites that element is a hero image or a feature photo sitting above the fold. A 4MB JPEG that takes four seconds to paint will push your LCP score into the red, signalling to Google that the page delivers a poor user experience. That signal feeds directly into ranking quality assessments, which means a bloated image isn’t just a slow-load problem, it’s a rankings problem.
The knock-on effects compound quickly. A high LCP drags Total Blocking Time up as the browser queues render-blocking resources, and Cumulative Layout Shift spikes when images load without declared dimensions and push content around the page. Google bundles all three into a single page experience signal, so one poorly handled image can pull down scores across the board. WordPress sites are especially exposed here because the default media library applies no compression, stores multiple unoptimised size variants, and serves whatever format the original file was uploaded in, regardless of what the browser could actually handle.
The Format Decision: JPEG, PNG, WebP and When Each One Earns Its Place
The format you choose does more work than most people realise. JPEG is still the right call for photographs, where its lossy compression chews a 4 MB camera file down to 120 KB without visible damage to colour gradients or skin tones. PNG earns its place when you need pixel-perfect edges or a transparent background, think logos, icons and UI overlays where JPEG’s compression artefacts would show up immediately. The trade-off is file size. A logo saved as PNG-24 with transparency might sit at 40 KB, while the same graphic forced through JPEG can balloon to 90 KB and still look worse.
WebP covers both cases with better results. Google’s format delivers roughly 25 to 35 percent smaller files than JPEG at equivalent visual quality, and it handles transparency cleanly where PNG once had a monopoly. Browser support is now near-universal, so there is very little reason to avoid it for standard web use. The practical decision tree comes down to this, photograph with no transparency, use WebP first and JPEG as a fallback. Logo or illustration with a transparent layer, use WebP with a PNG fallback. If you want to understand how speed improvements compound across a WordPress build, format choice is one of the fastest gains you can make without touching a single line of code.
File Size vs Display Size: The Dimension Problem Most People Miss
Most WordPress sites serve images at their original upload dimensions, which is rarely the size the browser actually renders them. A photograph shot at 4000px wide lands in a container styled to 1200px, so the browser downloads all four thousand pixels, scales the image down on the fly, and discards the extra data. The visitor never sees those redundant pixels, but their connection pays for every byte of them. On a page with six or eight photos like that, you can easily hand a mobile user several megabytes of image data they have no use for.
The fix starts before you upload anything. Resize images to match their maximum rendered width, factoring in that a Retina or high-DPI screen needs roughly 2x the CSS pixel count to stay sharp, so a 600px CSS column warrants a 1200px source file, not a 4000px one. WordPress does generate intermediate sizes via its built-in thumbnail system, but it only serves them automatically when your theme correctly references srcset and sizes attributes. If your theme skips those attributes, WordPress regenerates the sizes and then ignores them, which means auditing your theme’s image markup is as important as the upload itself.
Compression Without Visible Quality Loss: Tools and Settings That Work
Lossless compression removes redundant data from an image file without touching a single pixel, so the output looks identical to the source. Lossy compression discards data the eye is unlikely to notice, which produces much smaller files but needs a careful quality ceiling. For JPEGs, a quality setting between 75 and 85 is the practical sweet spot, files typically sit under 150 KB for a full-width hero image, and under 80 KB for a standard blog thumbnail. WebP with lossy encoding at equivalent quality trims roughly 25 to 35 percent more off those numbers, making it the better default where browser support allows.
On WordPress, managing your plugin stack carefully matters here, because running two competing compression plugins at once will double-process images and silently degrade quality. Shortpixel and Imagify are the two most reliable single-plugin solutions, both convert to WebP automatically, apply compression on upload, and let you set a global quality threshold per image type. PNG files used for logos or icons with transparency should target lossless compression and stay under 100 KB. Anything above 200 KB for a non-hero image is worth reviewing before it ships.
Lazy Load in WordPress: What It Does, What It Breaks, and How to Set It Up Right
Lazy loading tells the browser to skip images that are off-screen on page load and fetch them only as the user scrolls down. WordPress has shipped native lazy loading via the loading="lazy" attribute since version 5.5, so most sites already have it running without a single plugin installed. For a product page with thirty images below the fold, that matters. The browser skips the bulk of those requests on initial load, which cuts both page weight and render time considerably.
The trap is above the fold. If your hero image or header banner carries loading="lazy", the browser deliberately delays fetching the one image that dominates your Largest Contentful Paint score, and your LCP tanks as a direct result. WordPress applies lazy loading to most images automatically, but it does exclude the first image on the page in many configurations. Still, themes and page builders sometimes override that logic, so always check your hero markup manually. If you spot loading="lazy" on any image visible without scrolling, switch it to loading="eager" and verify the change in a real Core Web Vitals audit before shipping.
Responsive Images and srcset: Letting the Browser Pick the Right File
When WordPress uploads an image, it generates several resized copies and writes a srcset attribute into the <img> tag automatically. That attribute lists every available size alongside its pixel width, and the browser reads it alongside the sizes declaration to decide which file to download. A visitor on a 375px mobile screen fetches a 400px crop, not the 1920px original. No JavaScript, no plugin, no manual intervention. It just works, provided the theme is built correctly and calls wp_get_attachment_image() or uses the_post_thumbnail() rather than hardcoding image URLs directly into templates.
The automation breaks down in two common places. First, page builders often insert images as CSS backgrounds or construct their own <img> markup outside WordPress’s native functions, stripping the srcset out entirely. Second, custom themes that register no additional image sizes leave the browser choosing between thumbnail and full, which is a poor set of options on a mid-range viewport. If you have built a custom WordPress theme, auditing your image output with browser DevTools is worth doing before any other optimisation work. Check the Network tab, filter by image, and confirm the file size downloaded matches the size rendered on screen.
A Repeatable Workflow for Every Image That Enters Your WordPress Site
The goal is simple, fix the habit, not the backlog. Before any image touches your media library, resize it to the maximum display width it will ever render at, typically 1200px to 1600px for full-width hero images and 800px or under for editorial content. Export it as WebP from your editing tool of choice, keep quality between 75 and 85, and check the file size before uploading. A product shot at 1400px wide should land under 150KB. If it doesn’t, compress again. This single checkpoint stops the most common cause of bloated media libraries before it starts.
Once the image is in WordPress, confirm your lazy load attribute is active and verify your alt text is descriptive and specific. A plugin like a well-organised plugin stack handles compression, format conversion and lazy loading automatically, so your content editors aren’t making technical decisions on every upload. Run a quick audit monthly using PageSpeed Insights to catch anything that slips through. Prevention compounds over time. A library built on clean inputs takes minutes to audit. A library built on raw JPEGs takes days to fix.