WordPress Image Optimization Done Right

Open the network tab on almost any WordPress site and the story is the same: images are half the page weight, often more, and a large share of that weight does nothing for anyone. A 2400-pixel photo displayed in a 400-pixel column. A PNG screenshot that should have been a WebP at a quarter the size. A hero image lazy-loaded into invisibility while the browser dutifully preloads the footer logo. None of this is exotic to fix — but the fixes interact, and doing them in the wrong combination cancels the benefit. This guide covers the three levers that matter (format, size, loading strategy) and the specific ways WordPress helps or fights you on each.

Formats: The Cheapest Win Available

Image formats are a solved problem with an adoption lag. As of today, the practical hierarchy is:

The most expensive mistake in the wild remains the photographic PNG — a screenshot or exported photo saved as PNG, weighing megabytes where a WebP would weigh tens of kilobytes. If you audit only one thing, search your media library for large PNGs.

WordPress has supported WebP uploads for years and AVIF uploads since version 6.5, and can generate WebP/AVIF sub-sizes on capable hosts. In practice, most sites get formats handled one of three ways:

1. An optimization plugin that converts on upload and serves the modern format to supporting browsers with fallback. Set-and-forget; the usual right answer.
2. A CDN or host that transforms images on the fly (many managed hosts and image CDNs do this). Even better, because it also handles resizing per device and future formats without re-processing your library.
3. Manual conversion before upload. Fine for low-volume sites with a disciplined owner; a fantasy for multi-author ones.

One quality note: aggressive compression settings are almost always safe for photos. Human eyes are terrible at spotting the difference between quality 85 and quality 70 in a real page context, but the file size difference is large. Test with your own images at quality ~70–80 before assuming you need more.

Sizes: Stop Shipping Pixels Nobody Sees

Format determines the price per pixel; dimensions determine how many pixels you buy. This lever is bigger than the format one, and it is where WordPress both shines and gets sabotaged.

What WordPress does for you

On upload, WordPress generates multiple sub-sizes (thumbnail, medium, large, and more, plus theme-registered sizes) and writes srcset and sizes attributes into image markup so browsers can pick a file matched to the actual slot and screen density. It also caps enormous uploads at 2560px. This machinery is genuinely good — when nothing interferes with it.

How it gets sabotaged

• Themes and page builders inserting raw full-size URLs. Background images set via CSS get no srcset at all. Builder image widgets sometimes select “full” size by default. Audit your templates: any image rendered without srcset is a candidate for shipping 4× the needed pixels.
• An inaccurate sizes attribute. srcset offers candidates; sizes tells the browser how wide the slot will be. Themes that declare sizes="(max-width: 2560px) 100vw" for an image living in a 380px card cause the browser to conscientiously download a huge file for a small hole. Recent WordPress versions improved auto-sizing for lazy images, but page-builder markup often overrides it.
• Retina overkill. Serving 2× density images is visible on photos, marginal on most content, and doubles-to-quadruples bytes. A defensible policy: 2× for the hero and product photography, 1×–1.5× for everything else.

The practical audit

Open your most important page, then in browser dev tools inspect the rendered size versus intrinsic size of each image (Chrome flags this directly, and Lighthouse’s “properly size images” audit lists offenders). A healthy target: no image whose intrinsic width is more than ~1.5–2× its largest rendered width. Fix offenders by choosing the right registered size in the editor, adding a theme size that matches your actual layout slots, or letting an image CDN resize on the fly.

Lazy Loading: Free Speed, One Sharp Edge

Lazy loading defers offscreen images until the user scrolls near them. WordPress adds loading="lazy" to images automatically and has for years, so the base case is handled. The remaining work is the sharp edge:

Never lazy-load the hero

The largest image at the top of the page is usually your Largest Contentful Paint element — the thing Google times to judge your speed. Lazy-loading it adds delay to exactly the wrong image, because the browser deprioritizes it until layout settles. The correct treatment is the opposite: eager loading plus a priority hint:

<img src="hero.avif" loading="eager" fetchpriority="high" ...>

WordPress attempts to skip lazy-loading for the first content image, and modern themes set fetchpriority on it, but page builders, sliders, and custom headers defeat the heuristic constantly. Verify with a Lighthouse run: if it warns that your LCP image was lazily loaded, this one attribute change is often worth more than every compression effort combined.

Other lazy-loading rules of thumb

• CSS background images do not lazy-load natively — another reason to prefer real <img> elements for content imagery.
• Always include width and height attributes (WordPress does by default) so the browser reserves space and the page does not jump as images arrive — that jumping is Cumulative Layout Shift, and lazy loading without dimensions is its main manufacturer.
• Carousels: slide two onward can lazy-load; slide one is above the fold and follows hero rules. Better yet, question the carousel.

The Upload Pipeline: Fix It Once, Benefit Forever

Optimization applied only at the display layer decays as people upload new material. The durable setup handles images at the moment they enter the site:

1. Set expectations at the source. Anyone uploading regularly should know the house rule; a sensible one is no uploads wider than 2560px, camera originals get exported first, screenshots become WebP.
2. Convert and compress on upload via plugin or host, including regenerating the sub-sizes in the new format.
3. Bulk-optimize the back catalog once. Most plugins can process the existing library. Do it after a backup, and expect it to take hours on a big library. This single pass frequently reclaims gigabytes of disk and is the step people skip because the benefit feels invisible — it is not; old posts get traffic too.
4. Serve through a CDN. Images are the most cacheable asset you have; there is no reason they should travel from your origin server to another continent per request.

What Not to Bother With

Honest omissions, because effort is finite:

• Chasing the last sliver of compression. The difference between a good setting and a perfect one is noise compared to fixing one oversized hero.
• Blurry-placeholder effects everywhere. Tasteful on photo-heavy portfolios; on ordinary sites they add JavaScript and complexity to solve a problem that width/height attributes already solved.
• Re-encoding tiny images. Optimizing a 6KB icon saves 2KB and a lot of attention. Sort your audit by file size, work from the top, and stop when the files stop being embarrassing.

A One-Page Checklist

• Modern formats (WebP minimum, AVIF where available) served with fallback — automated on upload.
• No photographic PNGs in the library.
• No image shipping more than ~2× its rendered width; srcset present on all content images; sizes attribute sane.
• Hero image: eager, fetchpriority=high, never in a lazy slider.
• Everything below the fold: lazy, with width and height set.
• Back catalog bulk-optimized once; CDN in front; house rules for future uploads.

Images are the rare performance domain where the work is genuinely finishable. One honest afternoon of auditing plus an automated pipeline, and the heaviest half of your site stops being your problem — not because you keep optimizing, but because nothing unoptimized can get in anymore.

Photo: Lisett Kruusimäe on Pexels