How to Improve Core Web Vitals on WordPress: LCP, INP and CLS Fixes That Work

WordPress can pass Core Web Vitals comfortably, and plenty of WordPress sites fail them for the same handful of reasons: an oversized hero image, too much JavaScript, unstable layout and weak hosting. This guide shows how to measure properly, then fix each metric in the order that gives the biggest gain.

The three metrics and their thresholds

Google's Core Web Vitals measure real-user experience, and a page is considered good when the 75th percentile of visits meets all three thresholds.

• Largest Contentful Paint (LCP): how quickly the main content appears. Good is 2.5 seconds or less.
• Interaction to Next Paint (INP): how quickly the page responds to taps and clicks. Good is 200 milliseconds or less.
• Cumulative Layout Shift (CLS): how much the layout jumps while loading. Good is 0.1 or less.

They are a lightweight ranking signal, not a trump card. Relevance still wins, but a slow, jumpy page loses conversions regardless of rankings.

Measure field data before lab data

Start with real-user data: the Core Web Vitals report in Search Console groups failing URLs by issue, and PageSpeed Insights shows field data for a page when enough traffic exists. Then use lab tools such as Lighthouse to reproduce and debug the problem, remembering that a lab score is a diagnostic, not the metric Google uses. Fix templates, not single URLs: one slow product template can fail hundreds of pages.

Fix LCP: the hero element and server response

On most WordPress pages the LCP element is the hero image or a large heading. The LCP optimisation guide breaks the time into server response, resource load delay, load time and render delay. In practice:

• Never lazy-load the hero image. Many themes and plugins do this by default and it delays LCP badly.
• Mark the hero with a high fetch priority and preload it when it is referenced from CSS or JavaScript.
• Serve right-sized images in WebP or AVIF with proper srcset values, instead of a 3000-pixel original scaled down by CSS.
• Cut server response time with full-page caching, a current PHP version and a CDN. A slow first byte limits everything after it.
• Inline critical CSS or remove render-blocking stylesheets, and self-host fonts with the font-display setting.

Check which element is actually the LCP element in your field and lab tools before optimising anything. On product and category templates it may be a different image or even a text block than you expect, and fixing the wrong element changes nothing. Slider plugins deserve special suspicion, because they often delay the first slide until their own script has run, which pushes LCP out by seconds.

Fix INP: reduce and split JavaScript

INP failures come from long tasks on the main thread. On WordPress the usual culprits are page builders, sliders, animation libraries, chat widgets, tag managers and a dozen plugins each loading their own scripts on every page. The INP guide recommends the approach below.

1. Audit what loads on each template and remove scripts that the page does not use. Load plugin assets conditionally.
2. Delay third-party tags such as chat and marketing pixels until the first interaction.
3. Replace heavyweight sliders and effects with CSS where possible.
4. Defer non-critical scripts and break long tasks into smaller chunks.
5. Test on a mid-range phone, not your fast laptop. INP problems show up on slower CPUs.

Fix CLS: reserve space for everything

Layout shift is almost always content arriving without reserved space, which the CLS guide covers in detail. Set width and height attributes on every image and video, or use aspect-ratio in CSS. Preload key fonts and use size-adjusted fallbacks so text does not reflow on swap. Reserve fixed-height containers for ads, embeds, cookie banners and sticky bars, and never inject banners above existing content after load.

A realistic order of work

Teams often burn weeks on micro-optimisations while one template-level issue causes most of the damage. Work in this order and re-measure after each step.

1. Fix the worst failing template in Search Console first, not the homepage score you check most often.
2. Get server response down with page caching and a modern PHP version, because every metric depends on it.
3. Correct the hero image: right size, modern format, correct priority and no lazy loading.
4. Remove or delay the heaviest scripts, starting with third-party tags and unused page builder features.
5. Add dimensions and reserved space wherever content shifts.
6. Re-test on a real mid-range phone and wait for the field data to update, which can take several weeks because it reflects a rolling window of real visits.

Be patient with the reporting. Search Console aggregates roughly the last 28 days of field data, so improvements appear gradually even when the fix is live immediately. Keep a short change log so you can connect each deployment with the movement in the metrics.

Hosting, caching and plugin discipline

Optimisation plugins help, but they cannot fix a poor foundation. Choose hosting with modern PHP, HTTP/2 or HTTP/3 and a proper full-page cache, add an object cache for dynamic sites, and keep the database lean by checking autoloaded options. Run one caching plugin and one image optimiser, not five overlapping tools, because stacked optimisers conflict and are hard to debug.

Audit your plugin list every quarter: remove what you no longer use, replace several small plugins with one purpose-built one, and test the impact of every addition. The same discipline matters even more on shops, which we cover in WooCommerce speed and conversion optimisation.

If you have optimised properly and a page builder theme is still the bottleneck, it may be time for a leaner build. Our web design service builds to pass Core Web Vitals from the first commit, and Next.js vs WordPress explains when changing the stack is worth it. For an audit of your own site, request a quote.

Share:XLinkedInWhatsApp