WordPress Core Web Vitals: Diagnose and Fix LCP, INP and CLS

To improve Core Web Vitals on a WordPress site, first find out which metric fails (LCP, INP or CLS) and on which page templates, using field data from PageSpeed Insights and Search Console. Then break the problem down with Chrome’s tools, fix the specific cause (server, main image, JavaScript, layout) and validate over 28 days. Each metric has its usual suspects on WordPress, and this guide walks through them one by one.

Guide current as of 15 October 2026, checked against WordPress 7.1 and Google’s documentation on web.dev.

What are Core Web Vitals and why do they matter?

Core Web Vitals are three Google metrics that describe what real visitors experience: LCP (how fast the main content shows), INP (how quickly the page responds to interactions) and CLS (how stable the layout is). They are collected from Chrome users and used, among many other signals, by Google’s ranking systems.

Google’s documentation on page experience is careful here: Core Web Vitals are used by its ranking systems, but there is no single page experience signal and good scores do not guarantee top rankings. They matter first and foremost to your visitors.

Where do you find your Core Web Vitals data?

Start with field data from real visitors: PageSpeed Insights for a single URL, and the Core Web Vitals report in Search Console for the whole site. Lab tools such as Lighthouse then help you reproduce and diagnose issues, but they never replace field data.

Two common traps: Search Console gives each URL group the status of its worst metric (a group marked Poor because of CLS may have an excellent LCP), and small sites often lack enough Chrome traffic for URL-level data, in which case PageSpeed Insights falls back to origin-wide data.

How do you diagnose a slow LCP?

Identify the LCP element (usually the featured image, a banner or the main heading), then measure its four sub-parts: server response time, the delay before the resource starts loading, the load itself, and the render delay. The longest sub-part tells you what to fix.

Google’s Optimize LCP guide describes this method and suggests a rough split for a healthy LCP:

Open DevTools > Performance in Chrome: live metrics show your local LCP and its element, and a page-load recording breaks down the sub-parts.

1. High TTFB: fix the server first

If TTFB alone eats half your budget, no front-end tweak will save you. Make sure pages are served from a page cache (on a LiteSpeed server, the LiteSpeed Cache plugin drives the built-in cache: see our LiteSpeed Cache setup guide), that PHP is up to date and that no needless redirect chain sits in front of the page. The web server matters too, as our comparison of LiteSpeed, Nginx and Apache for WordPress explains.

# Measure TTFB in seconds (run twice to test a warm cache)
curl -s -o /dev/null -w "TTFB: %{time_starttransfer}\n" https://www.example.com/

2. Load delay: make the LCP image discoverable and high priority

The LCP image should be in the initial HTML, without loading="lazy", ideally with fetchpriority="high". Since WordPress 6.3, core adds that priority to the image it expects to be the LCP element and stops lazy-loading the first content images, as the official dev note explains. Problems therefore usually come from a theme, page builder or optimisation plugin that lazy-loads every image again.

If your theme outputs the hero image itself, you can force the right behaviour:

// Above-the-fold featured image: never lazy-loaded, high priority.
echo wp_get_attachment_image(
	get_post_thumbnail_id(),
	'large',
	false,
	array(
		'loading'       => false,
		'fetchpriority' => 'high',
	)
);

In LiteSpeed Cache, exclude the logo and header image from lazy loading, or turn on Viewport Images (VPI). Avoid hero sliders: their first image is often injected by JavaScript and discovered late.

3. Load duration: make the image lighter

Serve the image at the size it is actually displayed (WordPress generates several sizes and a srcset attribute for exactly this), compressed and in a modern format such as WebP or AVIF.

4. Render delay: clear the rendering path

If the image has downloaded but paints late, look for what blocks rendering: large CSS files in the <head>, synchronous scripts, a scroll-reveal animation on the hero block, or a heading waiting for a web font. Minify and defer JavaScript and keep animations for content further down.

How do you fix a high INP?

A high INP means the browser takes too long to respond to a click, tap or keystroke. Find the slow interaction, measure its three phases (input delay, processing, presentation), then cut the JavaScript keeping the main thread busy: heavy plugins and builders, third-party scripts, expensive event handlers.

INP reports the slowest interaction of the visit (ignoring the worst one per 50 interactions on very interactive pages). According to Optimize INP, each interaction breaks down like this:

To find the culprit, open DevTools > Performance and interact with the page: the interactions log shows each one’s duration and phases. Turn on CPU throttling to get closer to a budget phone. To see what real visitors experience, the official web-vitals library can report the cause of every slow interaction:

import { onINP } from 'web-vitals/attribution';

onINP( ( metric ) => {
	// metric.value: duration in ms; metric.attribution: target element and phase timings.
	console.log( 'INP', metric.value, metric.attribution );
} );

Any JavaScript task over 50 ms is a long task that blocks interactions. If you build your own theme, yield to the browser between steps of long work (scheduler.yield() where supported, setTimeout otherwise). With off-the-shelf plugins, most of the gain comes from removing what you do not need.

Be wary of “delay all JavaScript until interaction”: it flatters the lab score but can pile every script onto the first click and hurt real-world INP. Test it page by page.

How do you eliminate layout shifts (CLS)?

CLS measures elements that move without the user doing anything. Reserve space for everything that arrives after the first paint: image and iframe dimensions, ad slots and banners, and web fonts whose metrics match the fallback font. Never insert content above what the visitor is already reading.

Typical WordPress causes, based on Google’s Optimize CLS guide:

• Images and videos without width and height, common in hand-pasted HTML and some builder blocks. WordPress adds dimensions to Media Library images; LiteSpeed Cache offers “Add Missing Sizes”.
• Cookie banners, announcement bars or notices pushed in at the top after load. Show them as an overlay (fixed position) instead.
• Ads and embeds (videos, maps, social posts): reserve their height with min-height or aspect-ratio.
• Web fonts swapping in at a different size: use size-adjust and the metric override descriptors, or font-display: optional for non-essential fonts.
• Animating layout properties (top, height, margin): use transform instead.

/* Reserve space for a 16:9 video embed (if your theme doesn't already) */
.wp-block-embed__wrapper {
	aspect-ratio: 16 / 9;
}

/* Fallback font tuned to limit the shift when the web font loads */
@font-face {
	font-family: "Inter Fallback";
	src: local("Arial");
	size-adjust: 107%;
}
body {
	font-family: "Inter", "Inter Fallback", sans-serif;
}

The right size-adjust value depends on your font pair. Also keep pages eligible for the back/forward cache (bfcache): a restored page shows instantly with no shift. An unload handler or a Cache-Control: no-store header prevents it; check eligibility under DevTools > Application > Back/forward cache.

Which WordPress features already help Core Web Vitals?

An up-to-date install does a lot already: native lazy loading, high priority for the likely LCP image, sizes="auto" on lazy images and speculative loading of the next page. Your main job is not to undo these optimisations.

To go further without code, the official Performance Lab plugin from the WordPress performance team offers features in testing, such as modern image formats or Image Prioritizer (beta), which prioritises the real LCP element based on measurements from actual visitors. Only enable the modules you need.

Speculative loading is configured through a filter. On a well-cached site you can test a more ambitious mode, which makes the next page near-instant at the cost of extra server requests:

// Child theme functions.php or a small custom plugin
add_filter( 'wp_speculation_rules_configuration', function ( $config ) {
	if ( is_array( $config ) ) {
		$config['mode']      = 'prerender';
		$config['eagerness'] = 'moderate';
	}
	return $config;
} );

How do you check that your fixes worked?

Check in the lab and with DevTools live metrics first, on the same pages and under the same conditions as before. Then click “Validate fix” in Search Console: Google monitors the affected URLs for 28 days while field data refreshes.

1. Record the starting value (field and lab), on mobile, for one template (home, post, product page).
2. Make one change at a time and note the date.
3. Purge every cache (plugin, server, CDN) and load the page twice to measure a warm cache.
4. Check the page visually (menu, forms, cart).
5. Start the validation in Search Console for the affected URL group.
6. Come back four weeks later and compare field data in PageSpeed Insights or CrUX Vis.

For a broader list of speed actions, from caching to scheduled tasks, see our guide to speeding up WordPress in 15 steps.

How much does hosting weigh on Core Web Vitals?

TTFB alone makes up a large share of LCP, and it depends on the server first. At Hosterwise, every plan runs on LiteSpeed servers with LSCache, HTTP/3 and free SSL certificates, so cached pages are served without running PHP. The Premium and Boost plans add resources for dynamic sites such as WooCommerce stores. Compare them on our WordPress hosting pricing page, or let us move your site for you with our free migration and measure the difference on your own Core Web Vitals.