Core Web Vitals Explained: What Actually Moves Rankings

Core Web Vitals get talked about like a magic lever — fix the score, watch rankings jump. That is not how it works, and treating it that way leads to the wrong priorities. Here is what LCP, INP and CLS actually measure, what really moves them, and what Google has and has not confirmed about their effect on rankings.

What Core Web Vitals actually measure

Core Web Vitals are three metrics Google uses to approximate whether a real visitor experienced a page as fast and stable, not whether a developer thinks it is fast.

• LCP (Largest Contentful Paint) — how long until the biggest visible element renders, usually a hero image or a headline. This is the closest thing to “does the page feel like it has loaded.”
• INP (Interaction to Next Paint) — how quickly the page responds after someone clicks, taps or types. This is “does the page feel stuck” — almost always a JavaScript problem.
• CLS (Cumulative Layout Shift) — how much content jumps around while the page loads. This is “did I just click the wrong thing because an ad loaded underneath my cursor.”

These are Google’s own published thresholds, measured from real visitors’ browsers via the Chrome User Experience Report — not a lab score from running a test once on a fast connection.

Are Core Web Vitals actually a ranking factor?

Yes, but the honest version of that answer matters more than the yes. Google has confirmed page experience, including Core Web Vitals, as a ranking signal since 2021. It is one signal among hundreds, and it carries far less weight than relevance and content quality. Google has been explicit that a slower page with genuinely better, more relevant content will still outrank a faster page that answers the query poorly.

In practice, Core Web Vitals function more like a tie-breaker between pages that are already competing for the same query, and as a direct lever on user behaviour — bounce rate, time on page and conversion rate all move with speed, independent of any ranking effect. Search Console and independent studies consistently show slow, unstable pages losing visitors before they lose rankings. That is reason enough to fix them without needing to oversell what Google does with the score.

If someone tells you a specific number of points will move you a specific number of ranking positions, that is not a claim Google has ever supported.

What causes poor Core Web Vitals

The same handful of causes show up on almost every site I audit:

• Oversized, unoptimised images — the single most common cause of poor LCP.
• Render-blocking CSS and JavaScript in the page head, delaying everything below it.
• Slow server response (TTFB) — the page cannot start rendering until the server replies, and no front-end fix compensates for a slow back end.
• Too many third-party scripts — chat widgets, ad tags, analytics tools and embeds, each adding its own JavaScript and its own delay.
• Web fonts blocking text render, or swapping in late and shifting the layout when they do.
• Ads, embeds or dynamically injected content with no reserved space, pushing everything else down once they load.
• Missing width and height on images, which is the most common single cause of layout shift.

What actually improves Core Web Vitals

Images

On most business sites, images are 60–80% of total page weight and are usually the LCP element, which makes this the highest-leverage category. Serve modern formats such as WebP, size images to the slot they are actually displayed in rather than uploading full-resolution photos, set explicit width and height on every image, and lazy-load everything below the fold — but never the hero image, since lazy-loading it delays LCP rather than improving it.

CSS and JavaScript

Defer or async anything not required for the first paint. Render-blocking scripts in the page head stop the browser drawing until they finish downloading and executing. Remove unused CSS and JavaScript rather than shipping a whole framework for a handful of used features, and be deliberate about third-party scripts — every chat widget or tracking pixel is code you did not write, running on every page, whether or not it is doing anything useful there.

Caching and CDN

Caching stores a finished version of the page so the server is not rebuilding it from scratch on every visit, which is one of the largest and cheapest wins available on most platforms. A CDN serves static assets — images, CSS, JavaScript — from a server physically closer to the visitor, which matters more the further your visitors are from your hosting location.

Hosting and server performance

This is the one people most often skip because it is the least interesting to work on, and it is frequently the ceiling everything else sits under. Check your Time to First Byte in PageSpeed Insights. Consistently above roughly 600ms means the server is thinking too long before it sends anything, and no amount of image compression or script deferral fixes that. Budget shared hosting puts a hard limit on every other optimisation on this list.

WordPress-specific considerations

WordPress sites tend to accumulate Core Web Vitals problems for reasons specific to the platform: plugins that load their CSS and JavaScript on every page regardless of whether that page uses them, page builders that generate deeply nested, bloated markup, themes carrying years of unused legacy code, and a database that grows heavier with every post revision and expired transient nobody has cleared.

None of that is a reason to avoid WordPress — it is a reason to audit what is actually running on it. I have written the full ranked breakdown separately: see How to Improve WordPress Website Speed for the fixes in the order they actually move the number, and WordPress development for how that work gets scoped.

How platform and code quality affect performance

Core Web Vitals problems are not really about which platform a site is built on — they are about how well that platform is implemented and maintained. A tightly built WordPress site can post better field data than a bloated custom React application shipping three megabytes of JavaScript for a page that could have been static HTML. Equally, a Webflow site with a dozen stacked interactions and unoptimised images will struggle just like WordPress with too many plugins.

What differs by platform is the ceiling and the effort required to hit it. Webflow and a well-scoped custom frontend tend to start closer to good Core Web Vitals by default, because there is less accumulated third-party code running by default. WordPress can match either, but it takes active maintenance to keep it there rather than a one-time setup. If you are choosing a platform partly on this basis, WordPress vs Webflow vs Framer covers the wider trade-offs.

What businesses should actually focus on

Chasing a perfect Lighthouse score is the wrong goal, for a few concrete reasons:

• Lab scores and field data disagree, and field data is what Google actually uses. A single PageSpeed Insights run on a fast connection is a diagnostic tool, not the real number. Check Search Console’s Core Web Vitals report for what your actual visitors experienced.
• The difference between a good score and a perfect one is mostly invisible to visitors and irrelevant to rankings. Time spent chasing 100/100 is time not spent on the fix that would actually move LCP from poor to good.
• Fix the worst metric first, not the easiest one. If LCP is poor because of hosting, no amount of CSS minification changes that. Establish a baseline, fix the biggest blocker, then re-measure.
• Core Web Vitals are one part of technical SEO, not the whole strategy. A fast page that Google has never crawled, or that targets the wrong query, will not rank regardless of its score. Speed work sits alongside indexation, site structure and content relevance — not ahead of all of them.

The businesses that get real value from this work treat it as one input to both search visibility and conversion rate, measured before and after, rather than a score to maximise for its own sake.