Core Web Vitals & Google rankings: When load time makes a difference

You’ve optimised your website’s loading time, the test results are green, and your rankings have stalled. This scenario is more common than most people realise. The reason is almost always the same: the loading time wasn’t the real problem.

This article answers the underlying question: When do Core Web Vitals actually influence Google rankings? And when is it worth investing time and money in performance optimisation?

Do Core Web Vitals improve Google rankings? The straight answer

Yes, Core Web Vitals are a confirmed Google ranking factor. Google incorporated them into the Page Experience signal in June 2021. Since then, the metrics for page speed, responsiveness and visual stability have been factored into the ranking assessment.

Google itself, through its employee John Mueller, has assessed the extent of this influence as follows: Core Web Vitals are more than just a tie-breaker, but they do not replace content relevance. In practical terms, this means that if two pages are of a similar standard in terms of content, the technically superior page may tip the balance. However, if your page addresses the wrong topic, is not indexed for the correct search query, or has weak content, no amount of loading time optimisation will make up for it.

A common mistake in practice: website teams spend weeks on performance optimisation, even though the real problem lies with relevance, indexing or intent alignment. The result is green test results and rankings that remain unchanged.

So first of all, check: Does your site even rank for the right search queries? Are your most important pages indexed correctly? Does your content really match the search intent? If not, start there.

What Google really measures: real user data rather than test results

The most common misconception regarding Core Web Vitals is the confusion between two fundamentally different types of measurement.

Lighthouse is a diagnostic tool. It simulates a page view under controlled conditions: a specified device, a stable connection and no background processes. The result is a lab result. Google does not use these lab results to determine rankings.

Google uses only real user data for its rankings. This data comes from the Chrome UX Report and is aggregated over a rolling 28-day period based on actual visits to your site. The 75th percentile is key here: 75 per cent of all page views must meet the target metrics for your site to be considered good.

The difference between the two measurement methods can be significant. A Lighthouse test result of 1.8 seconds for load time may be 2.4 seconds in real-world user data, because real users may have older devices, poorer mobile connections and different usage contexts.

PageSpeed Insights displays both sets of data: the top section shows the real-world user data. This is the figure that is relevant for rankings. The lab data below is useful for identifying technical issues, but it is not a ranking signal.

An important caveat: actual user data is only available for pages with sufficient traffic. Google requires at least around 1,000 page views from Chrome browsers within 28 days to display URL-specific data. Websites with low traffic do not appear in the user data, which is neither an advantage nor a disadvantage for the ranking.

The three metrics: What LCP, INP and CLS mean

LCP: How quickly does the user see the main content?

LCP stands for Largest Contentful Paint. This metric measures how long it takes for the largest visible element on your page to load completely. In practice, this is usually the hero image, a large photograph or a prominent headline.

Target time: under 2.5 seconds. Times of up to 4 seconds are considered to leave room for improvement; anything longer is considered poor.

LCP is the metric where most websites still have some way to go. According to the latest data from the Chrome UX Report, only 62 per cent of pages viewed on mobile devices achieve a ‘good’ score. This is the lowest figure of all three metrics and, in practice, often makes LCP the biggest bottleneck.

The most common causes of poor LCP scores are Hero images that haven’t been preloaded, image files that are too large, and slow server response times. Anyone still serving images in JPEG format should consider switching to AVIF: this modern format produces files that are 20 to 30 per cent smaller than WebP, whilst maintaining the same or better quality.

INP: How quickly does the page respond to clicks?

INP stands for Interaction to Next Paint. This metric measures how long it takes for the page to respond visually to a user interaction. This includes clicks on buttons, menus or links, entries in form fields and keystrokes.

Since March 2024, INP has replaced its predecessor, FID. The key difference is that FID only measured the first interaction on a page. INP evaluates all interactions throughout the entire visit. A page may respond quickly to the first click, but become noticeably sluggish by the fifth. FID would not have picked that up, but INP does.

Target value: under 200 milliseconds. Up to 500 milliseconds is considered to leave room for improvement; anything above that is considered poor.

INP is an area that is often underestimated. External scripts are the most common cause. Google Analytics, Facebook Pixel, chat widgets, consent banners and retargeting scripts can, when combined, block the browser’s main thread to such an extent that the page responds to clicks with a noticeable delay. Anyone who uses a lot of external scripts and has never measured their INP before will often find that this is where the greatest potential for improvement lies.

CLS: Does the content jump around whilst loading?

CLS stands for Cumulative Layout Shift. This metric measures the extent to which visible elements on the page shift unexpectedly without the user having triggered a corresponding action.

This happens, for example, when an image reloads and pushes the text below it down, or when an advert appears late and displaces buttons from the position where they were clicked. On mobile devices, this regularly leads to accidental clicks.

Target value: below 0.1. A value of up to 0.25 is considered to leave room for improvement; anything above that is considered poor.

CLS has improved the most over the past two years: 81 per cent of pages viewed on mobile devices now achieve a ‘good’ score. Simply declaring images with fixed dimensions in the HTML and incorporating ad spaces with reserved space is usually enough to resolve most CLS issues.

Why Core Web Vitals are relevant even without a direct impact on SEO

Performance optimisation is not solely an SEO issue. The strongest argument in favour of faster loading times is often the conversion argument.

Online shops that load in under a second convert up to three times better than those that take five seconds. Even one extra second’s loading time can reduce the conversion rate by up to 7 per cent.

This is particularly relevant for checkout processes: if a user clicks on ‘Add to basket’ and the page takes a noticeable time to respond, they may click again or abandon the process because they are unsure whether their click has been registered. Poor INP scores in the checkout area are a direct revenue issue, regardless of whether they affect search rankings.

This means that even if your Core Web Vitals scores are already within the target range and you don’t expect any impact on your search rankings, performance optimisation can deliver a measurable return on investment through improved conversion rates.

When is optimising page load times beneficial for search rankings?

Three scenarios with different recommendations.

• Your current user metrics are already good: the marginal benefit of further performance optimisation is minimal in terms of ranking. Focus on content quality, topic coverage and search intent. Load time isn’t the issue here.

• Your actual user metrics show yellow or red figures, and you’re facing stiff competition from sites with similar content: performance optimisation can be the deciding factor as a ranking factor. A targeted sprint is well worth the effort.

• Your conversion rate is being affected by measurable UX issues: if button clicks are slow to respond or content jumps around whilst loading, causing accidental clicks, it’s still worth optimising even if the impact on your search ranking is unclear.

The starting point for your assessment is always the CWV report in Google Search Console. It shows which page groups are in which status. There, you can quickly see whether performance is actually your current problem.

Here’s how to go about it in a structured way

The most important principle: one change at a time. If you implement several measures at once, you won’t be able to tell afterwards which one made a difference.

A sensible procedure:

• Select the group of pages with the poorest user metrics from the Search Console report, such as product pages or blog posts

• Document the current status of the actual user data before any changes are made

• Implement a single measure: for example, reduce the use of external scripts, switch images to AVIF, preload hero images, or declare image dimensions in the HTML to improve CLS

• Wait at least 6 weeks, as Google aggregates user data over a 28-day rolling period and Search Console is also updated with a delay

• Carry out a before-and-after comparison using real user data in Search Console

What we observed during a sprint: Enabling lazy loading for hero images on product pages improved the LCP value in real-world user data from 3.2 to 2.4 seconds. The lab results in PageSpeed Insights showed a more significant improvement to 1.8 seconds, illustrating the typical discrepancy between lab results and real-world performance. INP remained stable. The CLS score deteriorated slightly due to the delayed loading, which demonstrates that individual measures can have an undesirable impact on other metrics. It is therefore important to always keep an eye on all three metrics.

Is charging time really your main problem right now? Quick check

If you can answer ‘yes’ to at least four of the following six points, it’s worth undertaking a targeted sprint:

• Your actual user data shows yellow or red metrics in the Search Console report on Core Web Vitals

• You are competing with websites that have similar content to yours

• Your conversion rate is suffering due to noticeable lag when clicking or a layout that jumps around

• You have documented the current situation and planned a measurement window

• You have identified a representative set of pages for the test

• You can implement a measure in isolation, without making other changes at the same time

If fewer than four points apply: First, clarify the content, search intent and indexing. Performance comes afterwards.

Frequently Asked Questions: