Core Web Vitals for WordPress: Fixing LCP, INP and CLS

A green PageSpeed score and a passing Core Web Vitals assessment are two different things. The score comes from one simulated page load. The assessment comes from what real visitors on real phones experienced over the last four weeks, and it is the one Search Console reports on. Most WordPress Core Web Vitals failures trace back to a short list of causes in the theme, the page builder, the plugins and the hosting.

Below are the three metrics with their pass marks, how to read the data, and the fixes we reach for, one metric at a time.

The three metrics and their pass marks

Google's Web Vitals documentation defines the metrics and sets the thresholds:

Metric	What it measures	Good	Poor
Largest Contentful Paint (LCP)	How long until the largest image or text block in the viewport is drawn	2.5 seconds or less	Over 4 seconds
Interaction to Next Paint (INP)	How long the page takes to respond visibly to a click, tap or key press	200 milliseconds or less	Over 500 milliseconds
Cumulative Layout Shift (CLS)	How much visible content moves around unexpectedly	0.1 or less	Over 0.25

Anything in between is labeled "needs improvement". A page passes when the 75th percentile of visits is in the good range for all three, and mobile and desktop are judged separately. Your own fast laptop on office wifi says very little about the visitor at the slow end, and that visitor decides the result. INP replaced the older First Input Delay metric, so advice that still talks about FID is out of date.

Where WordPress Core Web Vitals data comes from

There are two kinds of data, and mixing them up wastes a lot of effort.

Field data is collected from Chrome users who visit your site and published through the Chrome User Experience Report. PageSpeed Insights shows it at the top of its report, and Search Console groups your URLs by it. It covers the previous 28 days, so a fix made today moves the numbers gradually. Pages with little traffic have no field data of their own, and the tools fall back to a figure for the whole site.

Lab data is a single Lighthouse run on a simulated phone and connection. It is repeatable and shows you what to fix, which makes it the right tool while you work. It cannot measure INP, because nobody clicks anything during the test. Total Blocking Time is the lab stand-in.

So use field data to decide which templates fail (product page, blog post, home page) and on which metric. Use lab tests and Chrome DevTools to find the cause on one example of each template. Then let the field data confirm the fix.

Fixing LCP on a WordPress page

Start by finding out what the LCP element is. PageSpeed Insights names it, and the Performance panel in Chrome DevTools marks it on the timeline. On most WordPress pages it is the hero image, the featured image or the main heading. The time it takes splits into the server's response, the delay before the browser requests the file, the download, and the delay before drawing. Each part has typical causes.

• Slow server response. No page cache, or a cache that most visitors bypass. Nothing else can start until the HTML arrives, so fix this first. The diagnosis is in how to reduce TTFB on WordPress.
• The browser finds the image late. A hero set as a CSS background in a page builder or slider is invisible until the stylesheet has been parsed, and it gets no responsive sizes. Use a real image element for the hero, or preload the background file.
• The hero is lazy-loaded. WordPress core leaves the first images on a page out of lazy loading and marks the likely LCP image with fetchpriority="high". Optimization plugins that swap src for data-src on every image undo that. Exclude the hero and the logo from any JavaScript lazy loader.
• The file is too big. A full-width desktop JPEG sent to a phone is the classic case. Our guide to WordPress image optimization covers formats and sizes.
• Rendering is blocked. A long row of stylesheets and synchronous scripts in the head keeps the browser from painting even after the image has arrived. When the LCP element is text, a late web font has the same effect, so preload the font file the heading uses and set font-display: swap.

Fixing INP means freeing the main thread

INP looks at every click, tap and key press during a visit and reports close to the slowest one. On WordPress the usual problem is the wait before the browser can even start handling the tap, because it is still busy executing scripts. Those scripts are seldom your own:

• tag manager containers carrying marketing tags, chat widgets, heatmaps and A/B testing scripts
• page builder libraries, sliders and animation packages loaded on every page
• cookie consent tools that scan the page again after each click
• very large pages, where mega menus and deeply nested builder markup make every style recalculation slower

To find the cause, open the Performance panel in Chrome DevTools, set CPU throttling to 4x or more, and record while you click what visitors click: menu, search, filters, add to cart. The long tasks around each interaction name the script file.

The fixes, roughly in order of payoff: remove scripts nobody uses any more, load third-party widgets only on the pages that need them or after the first interaction, give your own scripts the defer strategy, and reduce the markup on heavy templates.

Fixing CLS by reserving space

Layout shift happens when something arrives late and pushes visible content out of the way. The cure is always the same: tell the browser how big each thing will be before it loads.

• Images without dimensions. WordPress adds width and height to images inserted from the media library. Images hard-coded in theme templates, SVG logos and some builder widgets lack them. Add the attributes, or give the container a CSS aspect-ratio.
• Ads, embeds and iframes. Give every slot a min-height so the page does not jump when it fills in.
• Banners injected at the top. Cookie notices and promo bars push the whole page down. Make them overlays, or reserve their height in the initial HTML.
• Web fonts. A fallback font with different proportions reflows the text when the real font arrives. Preload the main font and pick a fallback with similar metrics.

Shifts within half a second of a click or tap are not counted, so an accordion opening is fine. To see what moves, use the layout shifts track in the DevTools Performance panel on a throttled connection.

The order to work in

1. Read the field data per template and per device. Fix what fails and leave what passes alone.
2. Get server response time down with page caching, since it feeds every other number.
3. Fix the LCP element on each failing template: easy for the browser to find, not lazy-loaded, the right size and format.
4. Fix layout shift, which is usually a handful of CSS and markup changes.
5. Work on INP last. It takes the most investigation and often a conversation with marketing about which tags stay.
6. Test again in the lab after each change, then watch the field data for four weeks.

Make one change at a time, so you know which one helped and which one broke the checkout.

What you can do yourself and what needs a developer

Setting up page caching, converting images and removing unused plugins are jobs a careful site owner can do, and on a simple site they are often enough to pass. Do not chase a lab score of 100. Passing the field assessment is the goal, and the last few points usually cost more than they return.

It becomes development work when the cause sits in the theme or in generated markup: a hero built as a background image, a builder that prints thousands of nested elements, scripts with tangled dependencies, or a custom feature that blocks the main thread. That is what our performance optimization service deals with, starting from an audit of the failing templates. When the theme itself is the bottleneck, rebuilding it as a lean custom theme can be less work than patching it.

Frequently asked questions

Do Core Web Vitals affect Google rankings?

Google's Search documentation says its ranking systems aim to reward good page experience and recommends achieving good Core Web Vitals. Relevance still decides most results, so passing will not lift a weak page above a better answer. The more dependable reason to fix them is the visitor, who finds a quick and stable page easier to use.

Why does my PageSpeed score change every time I test?

The score is lab data from one simulated load, and it varies with server load, network conditions and third-party scripts at that moment. Run several tests and take the middle value. For decisions, rely on the field data section.

How long does a fix take to show in Search Console?

Field data is a rolling 28-day window, so the improvement appears gradually and is complete about four weeks after the fix went live. Use a lab test to confirm the change straight away.

Will a caching plugin alone make a WordPress site pass?

It often fixes LCP on simple sites, because server response is a large part of that metric. It does nothing for layout shift and little for INP, which depends on the JavaScript the page runs. Treat caching as the first step and measure again afterwards.