Google's Core Web Vitals have been a ranking factor since 2021. The most important one for most sites is Largest Contentful Paint, or LCP. Google considers anything under 2.5 seconds 'good.' Anything over 4 seconds is 'poor.' And yet, the average WordPress site in 2026 still loads in over 3 seconds.
We target 2 seconds or less on every WordPress build. Here's how.
Start with hosting, not plugins
No amount of optimisation plugins will fix bad hosting. If your WordPress site is running on £3/month shared hosting, your server response time is already eating 800ms to 1.2 seconds before any content loads. That's half your budget gone on the server alone.
We use managed WordPress hosting with server-level caching, HTTP/2 or HTTP/3 support, and edge CDN. That gets our Time to First Byte (TTFB) under 200ms consistently. The difference between cheap hosting and proper hosting is the difference between a 3.5-second site and a 1.8-second site.
Image optimisation
Images are the LCP element on 70% of web pages. If your hero image is a 2.4MB PNG, nothing else you do matters. We convert all images to WebP or AVIF, serve responsive sizes using srcset, and lazy-load everything below the fold. The hero image gets preloaded in the head. These four steps alone typically cut 1 to 2 seconds from load time.
Reduce plugin bloat
The average WordPress site has 20 to 30 plugins. Each one adds HTTP requests, CSS files, and JavaScript. We audit every plugin and ask two questions. Does this plugin load assets on every page? And does this functionality actually need a plugin, or can it be done with 10 lines of code?
We've seen sites where a social sharing plugin added 400KB of JavaScript to every page. A contact form plugin loaded its CSS and JS on every page, not just the contact page. And an analytics plugin added three separate tracking scripts when one would do. Each of these is fixable. Most are unnecessary.
Critical CSS and deferred loading
The browser can't render anything until it's parsed the CSS. If your stylesheet is 200KB, that's a problem. We extract critical CSS (the styles needed to render above-the-fold content) and inline it in the head. Everything else gets loaded asynchronously. Same principle for JavaScript: defer it unless it's essential for initial render.
