Core Web Vitals in 2025: What You Actually Need to Know

Google has been talking about Core Web Vitals as a ranking signal since 2021. A lot of the advice out there still treats them as a vague SEO checkbox. They are not. They are measurable performance metrics with specific targets, and most WordPress sites fail at least one of them.

Here is what each metric actually measures, how much it matters for rankings, and what you do to fix it.

LCP: Largest Contentful Paint

LCP measures how long it takes for the largest visible element on the page to load. Usually that is a hero image, a large heading, or a video poster. Google's target is under 2.5 seconds.

The most common reason LCP is slow is the image itself. An uncompressed image served at full resolution to a mobile device will take time. The fixes here are specific: compress the image, serve it in WebP format, and add fetchpriority="high" to the LCP image element so the browser prioritises it. Do not lazy-load your LCP image. That is a common mistake. Lazy loading tells the browser to wait until the image is near the viewport. Your LCP image is already in the viewport.

The second most common reason is server response time. If your hosting is slow or your server is not caching responses, the browser is waiting before it can even start loading anything. A target of under 200ms for Time to First Byte is reasonable. Most shared hosting does not hit it consistently.

CLS: Cumulative Layout Shift

CLS measures how much the page layout shifts during loading. You know the experience: you go to tap a button and the page jumps and you tap something else instead. Google's target is a score under 0.1.

The fix for CLS is mostly about being explicit with dimensions. Every image on the page needs a width and height attribute set. When those are absent, the browser does not know how much space to reserve for the image before it loads. The layout shifts to accommodate it after the fact.

The same applies to embeds, iframes, and ad slots. If you have a Google Ad unit on your page with no reserved height, it will push content down when it loads. Set explicit dimensions. Reserve the space before the content arrives.

Fonts cause CLS too. When a web font loads and swaps with the fallback font, text can reflow if the two fonts have different metrics. Using font-display: swap combined with a system font fallback with similar metrics reduces this.

INP: Interaction to Next Paint

INP replaced FID (First Input Delay) as a Core Web Vital in March 2024. It measures how quickly the page responds to any user interaction. Taps, clicks, keyboard input. Google's target is under 200 milliseconds.

INP failures are almost always caused by JavaScript blocking the main thread. When a user taps something and the browser is in the middle of running a large JavaScript task, the response to that tap has to wait. The user experiences a lag.

The fixes depend on what is blocking the thread. Third-party scripts are a major contributor. A single analytics library, a chatbot widget, and a marketing pixel can collectively block the main thread for hundreds of milliseconds. Load third-party scripts asynchronously. Defer anything that does not need to run on initial load. Audit what is actually running on your pages and remove anything that is not earning its performance cost.

On WordPress sites, plugins that inject JavaScript into every page regardless of whether it is used are common offenders. A contact form plugin that loads its JavaScript on a blog post page that has no form is wasting resources and blocking the thread.

What a Good Score Looks Like in PageSpeed Insights

PageSpeed Insights gives you two sets of scores: lab data (simulated from Lighthouse) and field data (real user experience from the Chrome User Experience Report). Field data is what Google actually uses for ranking.

A good result is green across LCP, CLS, and INP in the field data section. Lab scores matter for diagnosing issues but do not directly influence rankings.

Run PageSpeed Insights on your most important pages, not just your homepage. Product pages, service pages, and landing pages that drive conversions are the ones that matter most. A fast homepage and a slow product page is a problem.

Aim for a Lighthouse Performance score of 90 or above on mobile. That is the harder target. Mobile testing simulates a slower device and network, which is realistic. Most of your traffic is probably on mobile.

The WordPress Plugins That Destroy These Scores

Some plugins are consistently responsible for Core Web Vitals failures on WordPress sites.

Visual Composer and older versions of WPBakery load substantial CSS and JavaScript globally. Even pages that use none of their features carry the weight. Revolution Slider is notorious for LCP problems because it takes control of the hero area and loads assets in a way that is difficult to optimise without modifying the plugin.

WooCommerce adds JavaScript to every page by default, including pages that have no commerce functionality. There are filters to disable this on non-WooCommerce pages and they are worth implementing.

Chatbot plugins are increasingly common and many of them load immediately on page paint, blocking the main thread early. If a chatbot is necessary, load it after a user interaction or a time delay. Not on initial load.

The general principle: audit every plugin that adds front-end assets, verify it is only loading them where they are needed, and remove anything that is not actively contributing to the user experience.

If your WordPress site is failing Core Web Vitals and you need a diagnosis, we audit sites before we optimise them. No guessing at what to fix.