Skip to content
ThemesIonic — home
WordPress Tutorials

How to Optimise Images in WordPress

Resize before uploading, compress once, serve WebP, and lazy-load everything except the hero. Those four steps remove most of the page weight on a typical WordPress site.

1 min read intermediate

The order that matters: correct dimensions first, compression second, format third, delivery fourth. Compressing a 4000-pixel image that displays at 800 pixels is optimising the wrong thing — resizing it saves an order of magnitude more.

Step 1: upload at the right size

Find the real display width using the browser inspector: hover the <img> tag and compare intrinsic size to rendered size.

Rules of thumb for a typical content area:

Use Upload width
Full-width hero 1920–2560 px
Content image 1200–1600 px
Card or thumbnail 600–800 px
Logo SVG, or 2× its display size

Roughly double the display width covers high-density screens. Anything beyond that is bytes nobody sees — the visual side of this is in how to fix blurry images.

Note that WordPress scales uploads over 2560 px on the longest side and uses the scaled copy. Work with that rather than against it unless you have a specific reason.

Step 2: compress once

Two lossy passes look considerably worse than one. Pick a single place to compress:

  • Before upload, in an image editor or a desktop tool. Most control, most manual effort.
  • On upload, via an optimisation plugin. The practical default.
  • At the CDN, if your CDN offers image optimisation. Then turn the plugin's compression off.

WordPress re-encodes generated sizes at a fixed quality; raise it if compression artefacts show:

<?php
add_filter('wp_editor_set_quality', fn () => 85);

Quality between 80 and 88 suits most photographs. Above 92 adds weight for almost no visible gain.

Keep originals. If a plugin offers "overwrite originals" to save disk space, decline — regeneration becomes impossible once they are gone.

Step 3: serve modern formats

WebP is supported everywhere that matters and is typically 25–35% smaller than JPEG at comparable quality. AVIF is smaller still, with slightly narrower support and slower encoding.

Two delivery approaches:

  • Convert and serve with a fallback. The plugin generates .webp copies and rewrites the markup or the server config to serve them to browsers that accept them.
  • Negotiate at the CDN. The CDN converts on the fly based on the request headers, and the origin keeps only originals.

Check the result in the Network tab: the response type for a photo should say webp on a modern browser.

Do not convert everything blindly — an SVG logo should stay SVG, and a screenshot with fine text often does better as PNG or WebP-lossless than as lossy WebP.

Step 4: get lazy loading right

WordPress adds loading="lazy" to images automatically. Two adjustments matter:

Never lazy-load the LCP image. The largest above-the-fold image should load eagerly and with high priority:

<img src="hero.webp" width="1600" height="900" alt="…"
     loading="eager" fetchpriority="high">

Do not stack two lazy loaders. A performance plugin's JavaScript lazy loading on top of the native attribute causes images that never appear — one of the causes in images not showing.

Step 5: always set width and height

Every image needs explicit dimensions so the browser reserves space before the file arrives. Without them the page reflows as images load, which is the single biggest source of layout shift — see how to fix cumulative layout shift.

WordPress does this automatically for images inserted through the editor. Images output by a theme template or a page builder sometimes do not, and are worth checking in the page source.

Let srcset do its job

WordPress generates several sizes and outputs srcset and sizes, so browsers download the size that fits. It only works when the sizes exist, so register sizes that match your layout and regenerate:

wp media regenerate --yes

Background images set in CSS bypass srcset entirely. Use image-set() or size the file for the largest realistic display.

Optimising an existing library

  1. Back up wp-content/uploads first — bulk optimisation is not reversible.
  2. Run in batches rather than all at once; it is CPU-intensive and can time out.
  3. Keep originals.
  4. Check a sample of results visually before processing the rest.
  5. Expect a large one-off increase in disk usage if WebP copies are generated alongside originals.

Measure the result

Compare total page weight before and after on the same page — that number, not a score, is what changed. Then check LCP in the field data rather than a lab test, since the hero image is usually the element being measured.

If images are now small and pages are still slow, the remaining weight is scripts and third-party embeds — the full method is in how to speed up a WordPress site.

Do not forget alt text

Optimisation is not only bytes. Descriptive alt text makes images usable for people using screen readers and gives search engines context; decorative images take an empty alt attribute so they are skipped. It costs seconds per image at upload time and cannot be retrofitted cheaply across a large library — the wider list is in the WordPress SEO checklist.

Frequently asked

For photographs and most graphics, yes — it is typically 25–35% smaller than JPEG at similar quality. Keep the original as a fallback and let the plugin or server handle format negotiation.
It helps for images below the fold and hurts for the largest image above it. Lazy-loading the LCP image delays the metric search engines measure.
Yes, but do it in batches and take a backup first. Bulk optimisation is server-intensive and irreversible if the plugin overwrites originals.

Related guides