Image optimisation for WordPress, start to finish

Images are usually the largest thing on a WordPress page and the easiest to fix. Most slow sites are slow partly because somebody uploaded a photograph straight from a phone.

Start with size, not compression

Compression is the step everyone reaches for. Dimensions matter more.

A photo from a modern phone is around 4000 pixels wide. Displayed in a 800-pixel-wide content column, you are sending five times more data than the browser can use. No amount of compression fixes that — you are compressing four times too many pixels.

Sensible maximum widths:

• Full-width hero: 1920px
• Content images: 1200px
• Blog thumbnails: 600px
• Logos and icons: the size they display at, or SVG

Resize before uploading. Any image editor does it, and doing it once at upload beats every plugin.

Then format

WebP is 25–35% smaller than JPEG at the same visual quality and supported by every browser in use. There is no real argument against it any more.

AVIF is smaller still, with slightly weaker support and slower encoding. Worth it on image-heavy sites.

Keep JPEG for photographs as a fallback, PNG only when you need transparency — a PNG photograph is enormous for no benefit — and SVG for logos and icons, which scale perfectly at any size for a fraction of the weight.

Plugins that convert in bulk and serve WebP automatically: ShortPixel, Imagify, Smush, EWWW. Any of them is fine.

Then compression

80–85% quality is the sweet spot for JPEG and WebP. The difference from 100% is invisible on a screen and the file is often half the size.

Use a plugin for bulk conversion of what is already uploaded, and set it to compress on upload so the problem does not return.

Set width and height, always

This one is not about file size — it is about layout shift.

Without dimensions, the browser does not know how much space to reserve. The text renders, the image arrives, everything below jumps down. That is CLS, and it is one of the three things Google measures.

WordPress adds dimensions automatically now. Some themes and page builders strip them. Check your rendered HTML for width and height on image tags — if they are missing, that is your CLS problem.

Lazy loading, with one exception

WordPress lazy-loads images below the fold by default, which is right.

The exception that matters: your hero image must not be lazy-loaded. It is the largest contentful paint element, and deferring it directly damages your LCP score. Most lazy-loading plugins let you exclude the first image or a specific class — do it.

This is a surprisingly common own goal: a plugin installed to improve performance making the single most important metric worse.

Clean up what WordPress generates

WordPress creates multiple sizes of every upload. Your theme and plugins add more. It is normal to have eight or ten copies of every image on disk.

Most are never used. A plugin like Force Regenerate Thumbnails or the cleanup tools in ShortPixel can remove unused sizes, which shrinks your backups and your storage.

You can also stop WordPress generating sizes you never use, by removing them in your theme's functions file — worth doing on a new site, more care needed on an existing one.

A realistic workflow

For new uploads: resize to the right dimensions before uploading, let a plugin convert to WebP and compress automatically.

For what is already there: run a bulk conversion and compression pass, regenerate thumbnails, delete unused sizes.

Then check: hero image not lazy-loaded, dimensions present in the HTML, and WebP actually being served — look at the Network tab and confirm the format.

That is usually a 20–40% improvement on image-heavy pages, and it is the least risky optimisation available. Unlike caching or script deferral, badly compressed images do not break layouts — they just look slightly worse, which you can see immediately.