WordPress speed optimisation

Why page speed is a business problem, not just a technical one

Google research is unambiguous on this: as load time increases from 1 second to 3 seconds, the probability of a mobile visitor bouncing rises by 32%. From 1 to 5 seconds, it rises by 90%. Portent's analysis of 94 million page views found that e-commerce sites loading in 1 second convert at 2.5 times the rate of sites loading in 5 seconds - and for B2B sites the ratio is 3 times. A slow site is not an inconvenience; it is a measurable drain on enquiries and revenue.

The Google rankings angle compounds this. Page speed became a mobile ranking factor in 2018. Core Web Vitals - Google's three user experience metrics - became a confirmed ranking signal in 2021. Only 41% of websites currently pass Core Web Vitals on mobile. If your site is in the failing 59%, you carry a negative signal into every search result where you compete with a site that passes. Fixing that removes a genuine headwind on your rankings.

Core Web Vitals - what Google actually measures

Core Web Vitals are three metrics Google uses to assess real-world page experience. To pass, 75% of actual visits to a URL must hit the "Good" threshold in Google's Chrome User Experience Report (field data, not lab data).

Lighthouse score vs Core Web Vitals - they are not the same thing

Lighthouse runs in a simulated lab environment on a throttled connection. It is a useful diagnostic tool. Core Web Vitals are measured from real Chrome users visiting your actual live site, averaged over the past 28 days. Google uses field data (Core Web Vitals) for rankings - not Lighthouse lab scores. A site can score 92 in Lighthouse and still fail Core Web Vitals in the field if it has heavy third-party scripts (live chat, ad pixels, marketing tags) that only fire during real sessions. I work on both: improving the lab score shows what's structurally faster, and fixing field data issues requires understanding what real sessions look like.

Why WordPress sites get slow

Most WordPress performance problems come from the same small set of causes. Knowing which one is limiting your site tells you where the optimization effort should go first.

Shared hosting with poor TTFB

Time to First Byte (TTFB) measures how long the server takes to start sending a response. Budget shared hosting typically produces TTFB of 500-1,200ms before any page content even starts loading. Google's threshold for a "Good" TTFB is under 800ms - and LCP cannot be good if TTFB is bad. No amount of caching, image compression, or plugin optimisation fully compensates for a slow server. If your hosting is the bottleneck, a move to a VPS or managed WordPress host is the single highest-return action.

No caching - or the wrong type

WordPress has three distinct caching layers and most sites have none of them configured properly. Page caching stores rendered HTML and serves it without touching PHP or MySQL - this alone can cut response times by 70-90% for standard brochure pages. Object caching (Redis or Memcached) stores the results of database queries in memory so repeated queries do not hit the database. OPcache stores compiled PHP bytecode so the server does not re-parse PHP files on every request. Each layer solves a different problem. Plugging in WP Rocket or W3 Total Cache handles page caching; object caching requires server-level configuration.

Unoptimised images

A photo uploaded from a modern phone is typically 3-8MB. Without resize, compression, and format conversion, WordPress serves it at that size to every visitor. Converting to WebP reduces file size by 30-35% compared to JPEG at equivalent visual quality. Lazy loading ensures images below the fold do not block the initial page render. Setting explicit width and height attributes on images prevents layout shift (CLS). The LCP image - usually the hero or featured image - should be preloaded in the `` so the browser starts fetching it immediately.

Page builders and render-blocking resources

Elementor, Divi, and Beaver Builder produce fast-looking sites but come with a significant performance overhead: heavy inline CSS generation, multiple JavaScript files, and additional HTTP requests. Elementor's plugin files alone exceed 5MB compressed. When this stacks on top of a theme that loads its own CSS framework, sliders, and widget scripts, the render-blocking resource count climbs quickly. The fix involves deferring non-critical JavaScript, eliminating unused CSS, and reducing the number of requests the browser has to make before rendering anything.

Google Fonts served from Google's servers

Loading fonts from fonts.googleapis.com requires a DNS lookup, TCP connection, and TLS handshake to an external domain before any text can render. This directly delays LCP and FCP. Self-hosting fonts - downloading the font files to your own server and loading them from there - eliminates the external dependency entirely. It also removes the GDPR concern of IP addresses being transmitted to Google's servers on every page visit.

Database bloat

WordPress stores a new revision every time a post or page is saved. A site running for three years with regular content updates can accumulate tens of thousands of redundant database records. Add expired transients, spam comments, and deleted posts still in the trash, and the database queries that run on every page load take measurably longer. A database cleanup and revision limit configuration is a standard part of any optimisation project. For WooCommerce sites, accumulated order data, abandoned cart sessions, and unindexed product search queries compound this significantly.

What the optimisation service includes

What realistic results look like

Every site is different, and I will not promise a specific Lighthouse score before seeing the site. What I can say is that the starting point matters enormously.

• Shared hosting, no caching, Elementor site: Lighthouse typically 20-45, LCP often 5-10 seconds. After optimisation and hosting migration: Lighthouse 70-85, LCP 2.0-3.0s. Core Web Vitals pass is achievable but depends on what's in the template.
• Managed hosting, some caching in place: Lighthouse 50-70, LCP 2.5-4s. After full optimisation: Lighthouse 85-95, LCP under 2.0s. Core Web Vitals pass on mobile is realistic.
• WooCommerce on shared hosting: LCP often 5-12 seconds, INP failures common. After hosting move and targeted WooCommerce fixes: LCP 2.0-3.5s, INP improvements depend on theme and active plugins.

After changes go live, Core Web Vitals field data in Google Search Console takes up to 28 days to update - it reflects a rolling 28-day average of real user visits, not an instant snapshot. I include a follow-up check on field data after the 28-day window.