Client Site Is Slow: A 7-Step Core Web Vitals Rescue

The email arrives on a Tuesday. A screenshot of PageSpeed Insights showing 34 on mobile, a red Core Web Vitals panel from Search Console, and one line: “Why is our site so slow?” The site you built eighteen months ago has not changed. What changed is the plugin count, the image library and the number of marketing scripts the client’s other agency added.

Here is a repeatable seven-step process for a Core Web Vitals WordPress fix: how to measure properly, what to fix in what order, and how to stop the gains disappearing again within a quarter.

First, know which numbers matter

Three metrics make up Core Web Vitals, and each has a distinct cause. Confusing them is why so many optimisation attempts produce no movement.

Metric	What it measures	Usual culprits
LCP — Largest Contentful Paint	When the biggest above-the-fold element finishes rendering	Slow server response, unoptimised hero image, render-blocking CSS, lazy-loaded hero, font loading
INP — Interaction to Next Paint	How quickly the page responds to user input	Heavy JavaScript, third-party tags, sliders and builder scripts, long tasks on the main thread
CLS — Cumulative Layout Shift	How much content jumps during load	Images without dimensions, injected banners, web fonts swapping, ads and embeds

Also separate field data from lab data. Search Console and the CrUX panel in PageSpeed Insights show what real visitors experienced over the last 28 days. Lighthouse shows one simulated load on your machine. Field data is what Google assesses; lab data is a diagnostic tool. Fix the field number, use the lab to work out how.

The seven-step rescue

Step 1 — Baseline before you touch anything

Record field data for at least four URL types: home, a key landing page, a blog post and a template with heavy dynamic content such as an archive or product listing. Note LCP, INP and CLS for mobile and desktop, plus Time to First Byte. Save the screenshots. Without a baseline you cannot prove improvement, and proving improvement is what gets the invoice paid.

Then run WebPageTest or Lighthouse on the same URLs and export the waterfall. The waterfall is where the truth lives: it shows exactly which request the browser was waiting for when the page stalled.

Step 2 — Fix the server response first

If TTFB is above roughly 600ms, nothing you do in the browser will rescue LCP. Work through hosting and the back end before touching CSS.

• Confirm page caching is actually active for anonymous visitors — check the response headers rather than the plugin’s dashboard.
• Add persistent object caching (Redis or Memcached) where the host supports it. On query-heavy sites this alone can halve TTFB.
• Check the PHP version and bump it if the site is trailing several releases.
• Look for autoloaded options bloat and abandoned transients. A wp_options table carrying megabytes of autoloaded data slows every single request.
• Rule out a shared host that is simply oversubscribed. Sometimes the fix is a migration, not a tweak.

Database work is often the quiet win here. Clear expired transients, remove orphaned post meta left behind by deleted plugins, and check that autoloaded options are measured in kilobytes rather than megabytes before assuming the front end is at fault.

Step 3 — Audit the plugin stack

Every plugin that enqueues assets on every page is a tax on every page. Build a table of installed plugins, what each one is for, whether it is still used, and what it loads on the front end. Expect to find a slider used on one page loading its library sitewide, two form plugins where one would do, a social feed making a blocking external call, and an analytics plugin duplicating a tag that also exists in Tag Manager.

Remove what is unused. Conditionally dequeue what is used on only a few templates. Do this on staging and only on staging — this is the step most likely to break something visible.

Step 4 — Deal with images properly

Images are usually the largest single win on a content site, and the changes are low risk.

1. Serve modern formats. WebP or AVIF typically cuts weight substantially against the same JPEG at equivalent quality.
2. Resize at source. A 4000px photograph displayed in a 600px column is wasted bandwidth no compression can rescue.
3. Ensure width and height attributes are present so the browser reserves space. This is the fastest CLS fix there is.
4. Lazy-load below the fold and never above it. A lazy-loaded hero image directly delays LCP; add fetchpriority high to it instead.
5. Serve through a CDN so visitors on other continents are not fetching from a single origin.

The rules and implementation details are covered in our guide to lazy loading images in WordPress, including the exclusions that matter for LCP.

Step 5 — Cut and defer JavaScript

INP is where most WordPress sites now fail, and third-party tags are the leading cause. Inventory every script: analytics, heatmaps, chat widgets, consent banners, retargeting pixels, A/B testing tools. For each, establish who asked for it, whether it still earns its place, and whether it can load after interaction rather than on page load.

Then handle first-party scripts: defer non-critical files, remove jQuery dependencies where a theme no longer needs them, and split long tasks. Be careful with aggressive “delay all JavaScript until interaction” settings — they flatter the score while making the site feel worse for real users, which defeats the purpose.

Step 6 — Fix the critical rendering path

Inline the small amount of CSS needed for the above-the-fold view and load the rest asynchronously. Preload the LCP image and the primary web font. Self-host fonts, subset them, and use font-display swap with a metric-compatible fallback so text does not vanish or jump. Where a page builder emits a large per-page stylesheet, check whether the theme can generate a leaner one for key templates.

Step 7 — Re-measure, then document

Re-run the lab tests immediately, but tell the client that field data takes up to 28 days to reflect the change. Write a one-page summary: what was changed, the before and after lab numbers, what to expect in Search Console, and a list of things that will undo the work if they happen. That document is what turns a one-off job into a retainer conversation.

Why a Core Web Vitals WordPress fix does not stick

Three months after a successful Core Web Vitals WordPress fix, scores drift back. The site did not regress on its own. Someone uploaded a 5MB banner, the marketing team added two tags, a plugin update re-enqueued a library, or a new landing page was built without the performance rules.

Prevention is boring and effective: a monthly automated check on a fixed set of URLs, an image weight limit enforced at upload, a rule that new tags go through one person, and a performance line item in your build checklist. Setting a formal target per template — the approach in performance budgets across a client site portfolio — makes regressions visible before the client notices them.

This is also the natural bridge into recurring revenue. A speed rescue is a project; keeping the site fast is a service. Our WordPress maintenance and support service is built around that ongoing monitoring, and if the initial rescue is beyond what your team has time for, WordPress speed optimisation can be run as white label work under your brand, with the report written for you to send on.

When to say no

Not every slow site should be optimised. If the site runs a heavily customised, abandoned premium theme from 2016, sits on a host that cannot supply object caching, and carries forty plugins the client refuses to remove, you can spend twenty hours to move mobile LCP from awful to merely bad. Rebuilding the front end on a lean theme is often cheaper than rescuing it, and saying so early protects both the client’s budget and your reputation.

Equally, be honest about what performance buys. Better Core Web Vitals improve user experience and remove a ranking disadvantage. They are not a substitute for content, relevance or a functioning conversion path. Clients who expect a traffic jump from a green score will be disappointed unless you frame it correctly up front. This kind of candour is part of the same operating discipline described in the white label WordPress development guide for agencies.

Frequently asked questions

How long does a Core Web Vitals rescue take?

The technical work on a typical brochure site is usually a few days of focused effort across measurement, plugin audit, images and scripts. The field data in Search Console then needs up to 28 days of real traffic before it reflects the change, so set that expectation at the start.

Will a caching plugin fix everything?

No. Caching mainly improves server response time, which helps LCP. It does very little for INP, which is driven by JavaScript execution, or for CLS, which is a layout problem. Plugins are one tool in a sequence, not the sequence.

Do we need to move the client to a new host?

Only if TTFB stays high after caching and database work, or if the host cannot offer object caching and a current PHP version. Migration is disruptive, so treat it as a considered decision run against a proper zero-downtime WordPress migration checklist rather than a first response.

Is a perfect score the goal?

No. Passing the thresholds on field data for the templates that matter is the goal. Chasing 100 in Lighthouse usually means stripping functionality the client wants, and it is measured in conditions no real visitor experiences.

Can this be done on a live site?

Image and caching changes usually can. Plugin removals, script deferral and critical CSS should be done on staging with a full backup, then deployed in a controlled window. The risk of breaking checkout or a form on a live site is not worth the time saved.

If you have a client site stuck in the red and you would rather hand the diagnosis to someone else, send us the URL and the Search Console screenshot and we will tell you what we would tackle first.

For teams who would rather book capacity than quote job by job, the dedicated plans set out the monthly hour tiers and what is included.