Image Optimisation for WordPress: Formats, Sizing and Lazy Loading

For WordPress image optimisation, the fastest route is to stop treating the site as one object. A WordPress page is built from PHP, database queries, theme output, plugin assets, cache rules, CDN delivery, DNS and browser execution.

For practical WordPress work, the tool choice follows the symptom: Core Web Vitals for user experience, GTmetrix for waterfall timing, DevTools for execution, and admin screens for configuration.

When a site has several symptoms, pick the one closest to the user journey. A failed checkout, broken enquiry form or mobile LCP failure deserves attention before a cosmetic score improvement on a low-traffic page.

Find the image that actually matters

A WooCommerce category page downloads 4000px product images into 480px cards. BunnyCDN can deliver them quickly, but it should not be asked to deliver unnecessary weight.

• LCP image dimensions far exceed the rendered size
• srcset exists but the browser still picks a large candidate
• below-the-fold gallery images compete with the hero image

For speed work, compare the same URL across PageSpeed Insights and GTmetrix. PageSpeed is useful for Core Web Vitals diagnostics; GTmetrix is useful for waterfall order and request weight; DevTools is where you confirm the browser behaviour directly.

Formats, dimensions and lazy loading

Screenshots are useful when they show the exact request, setting or metric involved.

• PageSpeed Insights LCP image audit
• DevTools Network image filter with transferred and intrinsic sizes
• WordPress media attachment details
• LiteSpeed Cache image optimisation status

CDN delivery after origin cleanup

• 1. resize source images close to display dimensions
• 2. generate WebP or AVIF and verify fallbacks
• 3. lazy-load below-the-fold media but exclude the LCP image
• 4. check WooCommerce thumbnail and single-product image sizes after theme changes

If LCP is the main failure, work on the first visible content and its discovery path. If INP is the failure, look for scripts that block the main thread after the page appears usable. If CLS is the failure, inspect what moves after paint. If TTFB is high, check cache status, PHP work and database behaviour before touching images.

Decision point for WordPress image optimisation

For WordPress image optimisation, choose the next change by metric ownership. Slow TTFB belongs to cache state, PHP work, database queries or hosting resources. Poor LCP belongs to the first visible asset and how early the browser discovers it. Poor INP belongs to long JavaScript tasks, often from page builders, forms, sliders or third-party widgets. Poor CLS belongs to layout space, dimensions, banners and late-injected content.

If the next test does not tell you what to do afterwards, it is too vague. A good test has a pass/fail result: cache HIT appears, the LCP image changes, the CNAME resolves, checkout remains uncached, or the repeated database query disappears.

Artefacts to keep for WordPress image optimisation

Do not keep random screenshots. Keep the ones that show cause and effect: before metric, changed setting, purge action and after metric.

• PageSpeed Insights mobile result showing LCP element and diagnostics.
• GTmetrix waterfall filtered to HTML, images, CSS, JavaScript and third-party requests.
• DevTools Performance trace with long tasks, layout shifts and LCP timing visible.

Image mistakes seen on WordPress sites

• using PNG for product photography
• lazy-loading the first visible image
• assuming CDN delivery replaces image optimisation

When the first fix only partly improves the result, keep the same test page and move to the next likely layer. Changing the test and the setting at the same time destroys the comparison.

Verification notes

• Retest the same mobile URL in PageSpeed Insights and note LCP, INP, CLS and TTFB.
• Open GTmetrix to confirm the changed request is actually lighter or earlier.
• Use DevTools to verify the LCP element, long tasks and cache headers.

Questions about media optimisation

When should AVIF be used?

WordPress image optimisation should be checked against the failing URL, not a generic checklist. Use the symptom, the tool output and the WordPress layer involved to decide the next action.

How do I find the LCP image?

WordPress image optimisation should be checked against the failing URL, not a generic checklist. Use the symptom, the tool output and the WordPress layer involved to decide the next action.

Can LiteSpeed optimise existing uploads?

WordPress image optimisation should be checked against the failing URL, not a generic checklist. Use the symptom, the tool output and the WordPress layer involved to decide the next action.

If the issue only appears during busy periods, schedule a follow-up check. Some WordPress problems are resource or traffic dependent and will not show during quiet testing.

When a speed article is still unclear, add one more measurement rather than one more opinion. Record the HTML TTFB, the LCP resource URL, total transfer size, number of main-thread long tasks and whether LiteSpeed Cache served a HIT or MISS. Those five values usually point to the next sensible action.

Hold one URL steady while settings change, otherwise the test loses its value.

A confusing retest is a signal to narrow the experiment, not widen it.

If the change cannot be reversed cleanly, test it somewhere safer first.

When the issue involves Core Web Vitals, record which metric you are trying to move before changing settings. LCP, INP and CLS often need different fixes, so one combined score is not enough evidence.

Summary

The practical route is evidence first: reproduce the issue, inspect the right tool output, make one controlled change and validate the same visitor journey. That keeps WordPress optimisation from turning into guesswork.