How to fix Core Web Vitals on a WordPress site

To fix Core Web Vitals on a WordPress site, start by removing what the page does not need (preloaders, animation scripts, unused plugins), then size and lazy load images, then add page caching. On my client sites the biggest gains came from deleting things rather than installing another optimisation plugin. The three metrics to work on are Largest Contentful Paint (LCP), Interaction to Next Paint (INP) and Cumulative Layout Shift (CLS).

This post is the fix order, metric by metric, for any WordPress site. If you run Elementor, how to speed up an Elementor site without rebuilding it goes deeper on the builder itself. On LiteSpeed hosting, see how to set up LiteSpeed Cache safely. Store owners should also read why a WooCommerce store is slow, and if you are budgeting for the work, what WordPress speed optimisation costs.

What are Core Web Vitals in plain terms?

They are three measurements Google collects from real Chrome users and reports in Search Console and PageSpeed Insights. They are part of Google's page experience signals, so they matter for search as well as for the people who leave a slow page.

Those are the "good" thresholds, and Google assesses them at the 75th percentile of page loads. In plain terms, at least three in four real visits need to hit each number for the page to pass.

Lab tools like Lighthouse are good for debugging. The field data in Search Console is what Google uses, and it updates slowly because the Core Web Vitals report is based on a 28-day rolling window of real visits. Also expect a gap between devices: the PageSpeed Insights lab test simulates a throttled mobile device and network, so mobile scores sit well below desktop. To turn a PageSpeed Insights or Lighthouse report into a ranked fix list, paste it into the free Page Speed Fix Planner.

Related guide: Hire a Bricks Builder developer: what to check first

Where should you start on a slow WordPress site?

1. 1

   Measure on mobile

   Run PageSpeed Insights on the homepage and your top landing pages, and open the Core Web Vitals report in Search Console to see which URL groups fail.

2. 2

   List what loads

   Check the network waterfall. Note every script, font, image and video, and which plugin or theme feature adds it.

3. 3

   Remove

   Delete loaders, unused plugins, demo content and scripts that do not earn their weight.

4. 4

   Fix images

   Resize, convert and lazy load images, starting with the hero on each template.

5. 5

   Cache and retest

   Add page caching, then retest the same pages on mobile and compare.

Which scripts should you remove first?

Start with anything that delays the first view for decoration. Heavy JavaScript is the main cause of poor INP, and it often drags LCP down too.

• Preloaders and smooth-scroll scripts. A loader hides the page until everything has downloaded, which pushes LCP back on every visit. Smooth-scroll libraries hijack scrolling and keep the main thread busy. Both can usually go with no loss to the design.
• Plugins you do not use. Theme demos often install plugins the site never needs, sometimes a full shop plugin on a site with no shop. Removing them cuts weight and attack surface.
• Overlapping plugins. Two slider plugins, two form plugins, two SEO plugins. Pick one of each. Rather than counting plugins, audit what each one loads on the front end: scripts, styles and database queries. A plugin that loads nothing on public pages costs little; one that adds a script to every page costs every visitor.
• Third-party widgets. Chat bubbles, review widgets and popups each add JavaScript. Keep the ones that make money, and load them after the page is usable.

Once the obvious weight is gone, work on INP directly:

• Defer or delay non-critical JavaScript. Add defer to scripts the first view does not need, and delay chat, review and marketing widgets until the first scroll or tap. Most caching plugins have a "delay JavaScript execution" option. Test menus, forms and checkout after turning it on.
• Break up long tasks. Any task over 50 ms blocks the page from responding. The Performance panel in Chrome DevTools shows them. In custom code, split the work and yield back to the browser between chunks, as described in Google's guide to optimising long tasks.
• Remove jQuery-heavy sliders. Older carousel plugins load jQuery, a slider library and an animation library on every page. A static hero or a CSS scroll-snap carousel does the same job with almost no JavaScript.

How do you fix slow images?

Images are the largest bytes on most pages and are often the LCP element.

• Resize to the slot. Decide image sizes per template up front (a fixed width for the hero, a fixed square for product images) and give them to whoever uploads content, so new images arrive at the right size.
• Serve separate mobile images where the crop differs, using srcset or a picture element, so phones do not download desktop banners.
• Re-export from originals when photography is the selling point. Image enhancement was part of my Magpie Retreat repair, and for photo-led sites like retreats and hotels it pays to re-export at the right dimensions and compression rather than running a blanket optimiser over files that are already compressed.
• Convert to WebP or AVIF. For a one-off batch, my free Under1MB image converter compresses and converts in the browser with no uploads and no sign-up.
• Load the hero first. Never lazy load the hero image, add fetchpriority="high" to it, and preload it if the theme sets it as a CSS background.
• Lazy load below the first screen so off-screen images wait until they are needed.
• Set width and height on every image so the browser reserves space and the layout does not jump.

For the full method, see how to optimise website images without losing quality.

Related guide: Bricks Builder site slow? How to fix Core Web Vitals

How do you stop fonts and late elements shifting the layout?

After images, web fonts are the most common CLS cause I see on WordPress sites.

• Set font-display. Use swap so text shows straight away in a fallback font, or optional if you would rather skip the custom font on slow connections than show a visible swap.
• Preload the one or two font files used above the fold, in WOFF2, and self-host them rather than pulling them from a third-party font service.
• Match the fallback font. Use size-adjust and the related override descriptors on the fallback @font-face so the swap does not reflow lines of text.
• Load fewer weights. Every weight and style is another file. Two or three is usually enough.
• Reserve space for late elements. Cookie bars, announcement banners and embeds should have a fixed slot or sit over the content, not push it down after load.

Does the page builder matter?

It sets the starting point. Bricks Builder outputs lean markup, which makes passing easier on content-heavy sites. Ravens Ait, a Thames island venue with 20+ event pages, is a Bricks build.

Elementor can get there with discipline: remove unused widgets and add-on packs, turn on Elementor's built-in performance features, keep nested containers shallow and apply everything above. The Elementor sites that fail usually do so because of the scripts and images piled on top, not the builder alone. More on this in Bricks vs Elementor vs Oxygen and speeding up an Elementor site.

Related guide: Website speed optimisation services: what gets fixed and what it costs

What about caching and hosting?

Caching comes after the cleanup, not instead of it.

• Page caching with a plugin such as WP Rocket, or LiteSpeed Cache if your host runs LiteSpeed.
• Load assets only where they are used. A slider script needed on one page should not load on all of them. The Wow Vastra store I worked on loads in about 1.5 seconds, and conditional asset loading is one of the cheapest wins on any store.
• Fix server response time (TTFB). A slow server delays everything, including LCP. Better hosting, an object cache such as Redis and fewer slow database queries all help.
• Use a CDN for images, CSS and JavaScript so visitors in the UK, the US and India are not all waiting on one server.
• Inline critical CSS for the first screen and defer the rest. Most caching plugins can generate it; check each template afterwards for unstyled flashes.
• Check the hosting cache layer when something breaks after a speed change, before blaming the plugin.
• Stay on a supported PHP version. It is a security issue as much as a speed one.

How do you handle a video hero?

Treat it as progressive enhancement. The Warren House homepage I built opens with a video hero, which is common for hotels and venues, and the same rules apply to any of them:

• Show a compressed poster image immediately, so the poster, not the video, becomes the LCP element.
• Set preload="none" on the video so the browser does not fetch it during the first paint.
• Load or start the video after the page has painted, with a short script or a lightweight embed.
• Keep the file short, muted and compressed, and consider a still image on mobile.

How do you know the fixes worked?

Retest the same pages on mobile in PageSpeed Insights, then watch the Search Console report move over the following weeks; because of the 28-day window, give it a month before judging. Keep a before and after record, ideally GTmetrix or PageSpeed reports saved on launch day, so you have a baseline to hold future changes against.

If you would rather hand this over, I do it as part of my technical SEO and Core Web Vitals service. Send me the URL or book a 20-minute call, and I will tell you what I would remove first.