PerformanceProfessional services

Speeding Up a Slow WordPress Site

Diagnosis before treatment. The order that finds the real bottleneck instead of optimising things that were already fine.

This is an implementation example, not a client case study. It describes how this work is actually carried out — the method, the sequence and the reasoning. No client is named and no result is claimed, because inventing either would make it worthless as evidence.

Ordered diagnosis of a slow WordPress website

Speed work fails when it starts with a checklist instead of a measurement. Minifying CSS on a site whose problem is a 4MB hero image is effort spent on the wrong thing, and it produces a report full of green ticks and a site that is still slow.

Project type
Performance remediation on an existing WordPress site
Sector
Professional services

The challenge

'The site is slow' can mean at least four different things: slow server response, a heavy payload, render-blocking resources, or a layout that shifts while loading. Each has a different cause and a different fix, and they are frequently confused with each other.

The objective

Identify which of those four is actually happening, fix that, and verify the fix against real user data rather than a lab score.

Approach

Measure first, on a mid-range mobile profile over a throttled connection. Then work down in order of typical impact — images, plugin weight, caching, hosting — changing one thing at a time so the effect of each is attributable.

Implementation

1. Establish what kind of slow

Four distinct signals, four distinct causes:

SymptomMetricUsual cause
Long wait before anything appearsTTFBServer, uncached PHP, slow database
Main content appears lateLCPOversized hero image, render-blocking CSS
Page feels unresponsive when tappedINPHeavy JavaScript on the main thread
Layout jumps while loadingCLSImages without dimensions, injected banners

Field data from Search Console is what matters here. A lab test on a fast connection will tell you everything is fine while real users on a phone experience something else entirely.

2. Images

Usually the largest single win and usually unchecked. Serve at rendered size, modern format, compressed, explicit dimensions, lazy-load below the fold only — never the hero.

3. Plugin audit

List everything. For each: what it does, where it is used, whether it loads globally. A slider plugin shipping its CSS and JavaScript to the contact page is pure cost.

Deactivate on staging, measure, delete what is not needed rather than leaving it dormant.

4. Caching

Page cache first — it is the largest step on an uncached site. Then object cache, browser cache headers, and a CDN for static assets.

One caching layer configured properly beats two fighting each other.

5. Hosting

If server response stays above roughly 600ms with caching active, the plan is the constraint and no further optimisation will move it.

6. Verify

Re-measure in the same conditions. Then wait four weeks and check field data, because that is the number Google actually uses.

Technology

  • WordPress
  • PageSpeed Insights
  • Search Console
  • WebP / AVIF
  • Query Monitor

Decisions worth explaining

Field data over lab scores as the success measure

Lab tests run on fast hardware and connections. Search Console reports what real visitors experienced, which is both what Google uses and what actually costs you customers.

One change at a time

Batching five changes and seeing an improvement tells you nothing about which one worked, or whether one of them made things worse.

No pursuit of a perfect score

The last few points routinely cost more than they return. Real-world load time is the goal; the number is a proxy.

What it produces

A site where the actual bottleneck has been identified and removed, verified against real user data. No percentage improvement is quoted, because the available improvement depends entirely on how bad the starting point was.

What it teaches

  • Checklists applied without measurement optimise things that were already fine.
  • Lab scores and field data regularly disagree, and field data is the one that counts.
  • A deactivated plugin is still a dependency and still a vulnerability.
  • Lazy-loading the hero image delays the exact element LCP measures.

Related services

Related guides

Worked examples

All case studies