webs.me.uk UK web hosting directory

Home → Guides → Making WordPress fast: caching, images and Core Web Vitals

Intermediate 10 min read

Making WordPress fast: caching, images and Core Web Vitals

Where the time actually goes on a slow WordPress site, and the fixes in order of how much they help per hour spent.

Measure before you change anything

Use PageSpeed Insights for Core Web Vitals, and WebPageTest with a London test location for a waterfall. The number that matters most for hosting decisions is TTFB (time to first byte). Under 200ms is good; over 600ms means the server or the site's PHP is the problem, and no amount of image optimisation will fix it.

In order of impact per hour spent

  1. Page caching. Turns a 700ms PHP-and-database page build into a 40ms static file. LiteSpeed Cache if your host runs LiteSpeed (Krystal, Hostinger, Pickaweb, many cPanel hosts), WP Rocket if you will pay, WP Super Cache or W3 Total Cache if free. This is usually a 5–10x improvement on TTFB and takes ten minutes.
  2. Images. Typically 70% of page weight. Serve WebP or AVIF, size them correctly rather than scaling a 4000px photo in CSS, and lazy-load anything below the fold (WordPress does this by default). ShortPixel or Imagify automate it.
  3. Host and PHP version. Moving from oversold shared hosting to a decent NVMe host, and from PHP 7.4 to 8.3, routinely halves TTFB with no code changes.
  4. Fewer plugins, better plugins. Query Monitor will show you which plugin is adding 400ms of database queries to every page. Page builders (Elementor, Divi, WPBakery) are frequently the single largest cost on a slow site.
  5. A CDN. Cloudflare's free tier serves static assets from a UK edge node. Worth doing, but it will not rescue a slow origin — cached HTML at the edge will.
  6. Object caching with Redis. Meaningful for WooCommerce and membership sites with lots of uncacheable, logged-in traffic; largely irrelevant for a brochure site.
  7. Fonts. Self-host them, subset them, and use font-display: swap. Google Fonts loaded from Google's CDN costs a DNS lookup and a connection, and raises GDPR questions in the EU.

Core Web Vitals in plain terms

MetricTargetUsual WordPress cause when it fails
LCP — largest contentful paint< 2.5sHuge unoptimised hero image, or slow TTFB from cheap hosting
CLS — cumulative layout shift< 0.1Images without width/height attributes; ads and cookie banners injected late
INP — interaction to next paint< 200msHeavy JavaScript from page builders, sliders and tracking scripts

A realistic target for a small WordPress site on good UK hosting is a sub-1.5s LCP for UK visitors. If you are above 4s, the cause is almost always one giant image, one page builder, or hosting that costs £1.99 a month.