SEO Unpacked is all about breaking down the parts of SEO that sound far more complicated than they need to be. This time, we are looking at Core Web Vitals, which have somehow managed to turn a handful of measurements about how a website behaves into a collection of acronyms, coloured scores and panicked screenshots being sent to developers with very little explanation.
Let’s imagine this for a second. Someone puts a URL into PageSpeed Insights, sees a mobile performance score of 43, takes a screenshot of the large orange circle and declares that the website is slow, rankings are going to collapse and everything needs to be fixed immediately. Suddenly, images are being removed, plugins are being installed and developers are being asked to “make the score green”, usually without anyone checking what the actual problem is or whether real users are experiencing it.
Core Web Vitals are important and website performance should absolutely be taken seriously. If you think about it, nobody wants to use a website that takes more than a few seconds to load, ignores them when they click something or moves the button just as they are trying to press it. However, Core Web Vitals are not the only part of technical SEO and a perfect score does not guarantee perfect rankings or deserve to become the business’s biggest priority.
So, let’s dive into what Core Web Vitals are, what each measurement actually means, why the different testing tools appear to never agree with each other and most importantly, when website performance should be treated as a genuine SEO and commercial priority.
What are Core Web Vitals?
Core Web Vitals are measurements created by Google to assess important parts of the experience users have when visiting a webpage. Rather than trying to judge whether a website looks nice or whether someone likes the colour of the buttons, they focus on areas that can be measured more consistently, including how quickly the main content appears, how responsive the page is and whether the layout remains stable while someone is using it.
When you open PageSpeed Insights, which is the free tool you can use by Google, you will normally see five prominent performance metrics. These are split into three Core Web Vitals that determine whether the page passes its Core Web Vitals assessment and two other notable metrics that provide additional information about the loading process.
The three Core Web Vitals are:
- Largest Contentful Paint, usually shortened to LCP
- Interaction to Next Paint, usually shortened to INP
- Cumulative Layout Shift, usually shortened to CLS
LCP measures loading performance by looking at when the largest visible piece of content appears.
INP measures responsiveness by looking at how quickly the page visually reacts when someone interacts with it.
CLS measures visual stability by identifying content that unexpectedly moves around while the page is being used.
There you have it, all the information you need, there’s no need for any more reading right? Right?
Well, unfortunately for you, we’re not done just yet because PageSpeed Insights also displays two supporting measurements under “Other notable metrics”:
- First Contentful Paint, usually shortened to FCP
- Time to First Byte, usually shortened to TTFB
FCP measures when the first visible piece of content appears, while TTFB measures how long it takes for the browser to begin receiving a response from the website. These are not part of the Core Web Vitals assessment itself, but they provide useful context when investigating why a page is slow to begin loading or why its main content takes too long to appear.
This means a page can pass its Core Web Vitals assessment even when FCP or TTFB is marked as needing improvement. LCP, INP and CLS determine whether the assessment passes, while FCP and TTFB help you understand what may be happening around them. Because apparently three acronyms were not enough, PageSpeed Insights gives us another two to think about as well.
Core Web Vitals are normally assessed using real-user data collected over a rolling 28-day period. Google also looks at what the majority of users are experiencing, which means that at least 75% of measured visits need to meet the recommended threshold for a metric to be considered good.
That last point is important because Core Web Vitals are not based on one person loading a page once. Real users visit websites using different phones, laptops, browsers, internet connections and locations. Someone visiting on a new phone while connected to fast Wi-Fi may have a completely different experience from someone using an older device on a weak mobile connection, even though they are visiting exactly the same page.
Largest Contentful Paint
Largest Contentful Paint measures how long it takes for the largest visible piece of content within the user’s screen to appear. In many cases, this will be a large hero image, a banner, a product image, a heading or a prominent block of introductory text.
A simple way to think about LCP is that it measures how long the user has to wait before the page looks like it has properly arrived. The website may technically have started loading, the header may be visible and a small icon might have appeared, but if the main product image or page heading is still missing, the user is probably not going to feel as though the page is ready.
Imagine walking into a restaurant, being shown to your table and then waiting several minutes for the menu. You are technically inside the restaurant, the lights are on and somebody has acknowledged that you exist, but you still cannot do the thing you came there to do. A poor LCP creates a similar experience. The page has started loading, but the main content the user wants is taking too long to appear.
Google considers an LCP of 2.5 seconds or less to be good. Between 2.5 and four seconds is classed as needing improvement, while anything above four seconds is considered poor. Poor LCP can be caused by several things, including slow server responses, large images, important resources being discovered too late, render-blocking stylesheets or JavaScript, and content that has to wait for scripts to run before it can be shown. This is where it is important not to jump to conclusions. PageSpeed Insights may tell you that an image is the LCP element, but that does not automatically mean the image is the only problem. The browser may have discovered it late, given something else priority or finished downloading it before another resource allowed it to appear.
In other words, compressing the hero image may help, but it is not a legally binding requirement that every LCP issue must be solved by repeatedly compressing the same image until it looks like it was taken on a phone from 2007.
Interaction to Next Paint
Interaction to Next Paint measures how responsive a page is when a user interacts with it. This includes actions such as clicking a button, opening a menu, selecting an option, expanding an accordion or interacting with a form. The possibilities are endless!
The measurement actually looks at how long it takes from the user beginning the interaction to the browser displaying a visual response. Google considers an INP of 200 milliseconds or less to be good, between 200 and 500 milliseconds to need improvement and anything above 500 milliseconds to be poor.
You will probably have experienced poor responsiveness without knowing its official name. You click a button and nothing appears to happen, so you click it again. The page then catches up, opens two things at once or submits the form twice, leaving you unsure whether the first click worked or whether you have just ordered two sofas That is an INP problem from the user’s perspective. They are not sitting there wondering whether the browser’s main thread is being blocked by a long-running JavaScript task. They simply know that they clicked something and the website ignored them.
INP is particularly important on interactive websites. Ecommerce sites, quote journeys, booking systems, filters, calculators and online applications all depend on users being able to select options and receive a response quickly. A blog article that is mainly read from top to bottom may have fewer complex interactions, but a product page where the size selector, image gallery and add-to-basket button are slow to respond can create a much more obvious commercial problem.
This is why the importance of a Core Web Vitals issue depends partly on the page and what users are expected to do there. A slow response on a decorative accordion containing extra information is not necessarily as serious as a slow response on the button that generates a quote or completes a purchase.
Cumulative Layout Shift
Cumulative Layout Shift measures how much visible content unexpectedly moves while the page is being used. Unlike LCP and INP, it is not measured in seconds. Instead, Google calculates a score based on how much content moved and how much of the screen was affected.
A CLS score of 0.1 or less is considered good, between 0.1 and 0.25 needs improvement and anything above 0.25 is poor.
This is usually the easiest Core Web Vital to explain because almost everyone has experienced it. You may have been reading an article when an advert loads and pushes the paragraph down the page or you go to click a product, but a banner appears above it and you accidentally select something else. It is frustrating because the page is changing after the user has already started interacting with it.
Common causes include images without defined dimensions, adverts or embeds that do not have space reserved for them, banners being inserted after the page has loaded, font changes and content being added above what the user is already viewing. The underlying issue is normally that the browser did not know how much space an element would need, so it had to rearrange the page once that element appeared.
Some movement is expected and perfectly reasonable like if a user clicks an accordion and the content below moves down, they caused and expected that change. CLS focuses on unexpected movement, which is why a page can contain interactive elements without automatically being considered unstable.
First Contentful Paint
First Contentful Paint measures how long it takes for the first visible piece of content to appear on the screen. This might be some text, a logo, an image, an icon or another visible page element.
The main difference between FCP and LCP is that FCP looks at when anything first becomes visible, whereas LCP measures when the largest and usually most important piece of visible content appears.
Imagine opening a restaurant menu online. FCP is the moment the restaurant logo or first heading appears, reassuring you that the page is loading. LCP is the moment the actual menu, main image or important information you came to see becomes visible.
A page can therefore have a reasonable FCP but a poor LCP. Something may appear quickly, but the main content could still take several more seconds to arrive. Equally, a slow FCP usually means the user is left looking at an empty or incomplete screen for too long, which can make the website feel unresponsive before they have even had the chance to use it.
Google considers an FCP of 1.8 seconds or less to be good. Between 1.8 and three seconds needs improvement, while anything above three seconds is considered poor.
Poor FCP can be caused by slow server responses, redirects, render-blocking stylesheets, JavaScript, web fonts or important resources taking too long to download. It is particularly useful when investigating LCP because it helps establish whether the whole page is slow to begin displaying content or whether the delay mainly affects the largest element.
If FCP and LCP are both poor, the problem may begin early in the loading process. If FCP is healthy but LCP is poor, the page may start appearing quickly while the main image, heading or content block is delayed.
Time to First Byte
Time to First Byte measures how long it takes between requesting the page and the browser beginning to receive the first byte of the response.
In simple terms, it measures how quickly the website starts answering. Imagine ordering something at a restaurant. TTFB is not how long it takes for the full meal to arrive. It is how long it takes before the waiter acknowledges the order and the kitchen starts responding. If nothing happens for several minutes, everything that follows will naturally be delayed.
TTFB includes more than the time spent by the server processing the request. It can also be affected by redirects, DNS lookups, establishing the connection, network latency and security negotiation. This means a slow TTFB does not always point towards one simple server problem, although hosting, caching and backend performance are common areas to investigate.
A TTFB of 0.8 seconds or less is generally considered good. Between 0.8 and 1.8 seconds needs improvement, while anything above 1.8 seconds is considered poor.
TTFB is an important diagnostic measurement because it happens before FCP and LCP. If the browser waits a long time before receiving anything from the website, the page is already starting the loading process at a disadvantage.
This does not mean that every slightly slow TTFB requires an expensive hosting migration or emergency server rebuild. A TTFB of one second may be marked as needing improvement, but if the page still loads its main content quickly, passes its Core Web Vitals assessment and provides a good experience, it may not be the most urgent issue facing the website.
How the five measurements work together
Although PageSpeed Insights displays five prominent field measurements, only three form the Core Web Vitals assessment:
- LCP measures when the main content appears
- INP measures how quickly the page responds to interactions
- CLS measures whether the layout moves unexpectedly
The two other notable metrics provide additional context:
- FCP measures when the first visible content appears
- TTFB measures when the website begins responding
Looking at them together gives you a clearer picture of the loading experience. TTFB can help identify whether delays begin before the page starts arriving, FCP shows when the user first sees something and LCP shows when the main content becomes visible. INP then tells you how quickly the page responds once the user begins interacting with it, while CLS shows whether the layout remains stable throughout the experience.
This is why the individual measurements are normally more useful than simply saying that a page is slow. They help you understand where the delay or frustration occurs and what kind of problem needs to be investigated.
Why do Core Web Vitals matter?
Core Web Vitals matter because they represent problems that affect how people actually use a website. It is easy to discuss them entirely as an SEO topic because they appear in Google Search Console and PageSpeed Insights, but their value goes much further than whether Google gives a page a small ranking advantage.
If the main content takes too long to load, users may decide the page is broken or leave before seeing it. If buttons do not respond, they may struggle to complete an enquiry or purchase. If content moves unexpectedly, they may click the wrong thing or lose their place. None of those experiences are good for the user and, unsurprisingly, they are not particularly useful for the business either.
This is where performance work should be connected to the purpose of the page. On a lead-generation website, the biggest concern may be whether a slow form is stopping users from making an enquiry. On an ecommerce site, it may be whether product images, filters and basket functions work properly. For a publisher, it may be whether adverts and embedded content are constantly shifting the article while someone is trying to read it.
A Core Web Vitals report becomes much more useful when it helps answer a commercial question. “Our mobile product pages have poor INP because the size selector is slow to respond” gives the business something meaningful to investigate. “The website scored 48” gives everyone a number to worry about without telling them what is wrong.
Do Core Web Vitals affect rankings?
Kind of like all of SEO, Core Web Vitals are used by Google’s ranking systems but it’s not the one and only signal that it uses for Ranking. So even though you may be passing them, it doesn’t mean Google will send a page to position one or that failing them will automatically remove it from search results.
Good Core Web Vitals are recommended as part of providing a strong overall page experience, but there is no single page-experience score that determines rankings. Achieving good scores in Search Console or third-party tools does not guarantee top rankings and pursuing a perfect score purely for SEO may not be the best use of time.
Relevance is still extremely important, if one page provides a brilliant, detailed and highly relevant answer to a search while another loads slightly faster but barely answers the question, Google is not expected to ignore the useful result purely because its LCP is a little slower.
Core Web Vitals are therefore best viewed as one part of the wider picture. When several pages provide similarly relevant, useful and trustworthy information, the page offering a better overall experience may have an advantage. However, improving a performance score will not rescue a page that targets the wrong search intent, contains poor content, is not indexed, has no useful internal links or does not properly explain the product or service.
Why PageSpeed Insights causes unnecessary panic
PageSpeed Insights is a useful tool, but it is also responsible for a lot of confusion because it shows several different measurements on the same screen and presents one of them as a large coloured score. Naturally, everyone looks at the large coloured score.
That performance score is generated through a Lighthouse lab test and assesses a wider range of performance measurements. It is useful for diagnosing opportunities and comparing changes under controlled conditions, but it is not the same thing as the Core Web Vitals assessment and it is not a direct Google ranking score.
A page can receive a disappointing Lighthouse performance score while still passing its Core Web Vitals assessment using real-user data. The reverse can also happen, with a lab test looking healthy while real users are experiencing problems. Neither result should be immediately ignored, but they are measuring performance in different ways. Lets explore why you get different results and why the data is different.
Lab data and field data: what is the difference?
Lab data is collected by testing a page in a controlled environment using predefined device and network settings. It is designed to create a repeatable test that helps identify technical problems, which makes it useful when debugging a page, comparing versions or checking whether a development change improved something.
Field data is collected from real users visiting the website. It reflects a much wider mix of devices, connection speeds, locations and behaviours, which means it is generally more representative of what the site’s actual audience is experiencing. Google’s field data is commonly taken from the Chrome User Experience Report, usually referred to as CrUX.
A straightforward way to think about it is that lab data is a controlled test drive, while field data is the information collected from thousands of real journeys.
During the test drive, the same car may be driven on the same route, in similar conditions and at roughly the same time. In the real world, people drive through traffic, bad weather, roadworks and questionable decisions at roundabouts. The controlled test is useful because it helps identify specific problems, but it cannot perfectly reproduce every real journey.
This is why PageSpeed Insights can appear to contradict itself. The field data at the top may say the page passes Core Web Vitals, while the Lighthouse test underneath identifies performance problems. The field data is telling you what users have generally experienced over time, while the lab test is showing what happened during that particular controlled test. Where both are available, field data should normally guide prioritisation because it represents real users, while lab data can help diagnose the cause and test possible improvements.
Why does the performance score keep changing?
Another common source of panic or confusion is running the same PageSpeed Insights test several times and receiving different results. The page might score 74, then 62, then 81, which can make the whole process feel like a slot machine operated by somebody who enjoys watching marketing teams suffer.
Small changes between tests are normal. Network conditions, server response times, third-party scripts, adverts and the resources being loaded can all affect the result. A lab test creates controlled conditions, but it cannot remove every variable involved in requesting and rendering a live website.
This is why decisions should not be based on the most alarming result from a collection of tests. Run several tests, look for consistent patterns and pay attention to which metric or resource is repeatedly causing the problem. If one test briefly reports a poor result but the others are broadly healthy, that may not represent the normal experience. If every test identifies the same large image, delayed request or long JavaScript task, you have a much stronger lead.
The goal is not to keep refreshing until you receive the score you wanted either. That is not performance optimisation. That is negotiating with the tool.
Why does PageSpeed Insights say there is not enough data?
Field data depends on there being enough eligible real-user visits for Google to report the information. Smaller websites and lower-traffic pages may not have enough data available at an individual URL level, which is why PageSpeed Insights sometimes says it cannot discover what real users are experiencing.
Where information is unavailable, PageSpeed Insights may show data for the wider origin, meaning the website as a whole. This can still provide useful context, but it may not accurately represent the exact page being tested. A simple article, an image-heavy homepage and an interactive checkout can all behave differently even though they sit on the same website.
How to use the Core Web Vitals report in Google Search Console
The Core Web Vitals report in Google Search Console is usually a good place to begin because it uses real-user data and separates mobile and desktop performance. It shows pages as Good, Need improvement or Poor and identifies whether the problem relates to LCP, INP or CLS. The report groups together URLs that Google believes provide a similar experience, often because they share the same template or underlying structure. A product page shown as an example may therefore represent a larger group of product pages rather than being the only URL affected.
This grouping is useful because Core Web Vitals problems are often template based. If hundreds of product pages use the same image gallery, scripts and layout, they may all be affected by the same underlying issue. Fixing the shared template could improve a large section of the site, which is normally far more valuable than making a tiny improvement to one isolated page.
It also means you should not look at one example URL and assume it tells the entire story. Review other URLs within the group, test representative pages and check whether the issue is consistent. One product may contain an unusually large image, one article may have an embedded video and one location page may include a map that behaves differently from the rest.
When should Core Web Vitals be a priority?
Core Web Vitals should become a clear priority when the problem is severe, affects important pages and creates an obvious barrier for users. If key landing pages take several seconds to display their main content, menus regularly fail to respond, product options are difficult to select or the checkout layout moves while users are entering details, the business has a genuine problem rather than an imperfect score.
Performance work should also be prioritised when one technical issue affects a large template or section of the website. A single change to the product-page template, navigation or shared JavaScript can potentially improve hundreds or thousands of URLs so always keep that in mind. In these situations, the scale of the opportunity can justify development time even when the performance problem is not catastrophic on every individual page.
Important commercial journeys should receive particular attention. That may include:
- Main product and category pages
- Core service pages
- Quote and booking journeys
- Enquiry forms
- High-traffic organic landing pages
- Pages supporting major campaigns or product launches
It is also worth investigating when performance has suddenly deteriorated after a redesign, migration, plugin update or new third-party tool has been introduced. If pages previously passed and a large section of the website is now reporting poor LCP or INP, that change may have created a clear starting point for the investigation. The important thing is to connect the technical issue with the people and pages it affects. “CLS is poor across 4,000 product pages because a promotional banner is moving the add-to-basket section” provides a much stronger business case than “our score is orange”.
Common Core Web Vitals mistakes
Core Web Vitals mistakes often happen because the measurements are treated as a scorecard rather than a diagnostic tool. People naturally want to make red numbers green, but improving website performance requires slightly more thought than repeatedly pressing “analyse” and hoping the internet becomes faster.
Chasing a score of 100
A perfect Lighthouse score can be satisfying, but it is not a requirement for good rankings, a successful website or a strong user experience. Some websites contain useful functionality, tracking tools, videos, product imagery and third-party services that naturally affect performance.
That does not mean everything should be accepted without question, but it does mean changes should be judged by their impact. Spending several days of development time moving a score from 96 to 100 may produce far less value than fixing a broken form, improving an important landing page or creating content around a commercially valuable topic.
Only testing the homepage
The homepage is not the whole website. It may use a completely different layout from product, category, service and article templates, and it may not even be the main organic landing page for most users. A homepage could perform brilliantly while thousands of product pages have the same slow image gallery. Equally, an image-heavy homepage may perform poorly while the service pages generating most leads are perfectly healthy.
Test the templates and journeys that matter, not just the URL everybody knows.
Treating every recommendation as equally important
PageSpeed Insights may recommend reducing unused JavaScript, serving images in a different format, improving caching, changing font behaviour and removing resources that block rendering. That does not mean every recommendation will have the same effect or that completing all of them is necessary.
Focus on the metric that is failing and the resources directly contributing to it. If CLS is the problem, spending the entire development budget compressing images may not solve it. If INP is poor because a third-party script blocks interactions, adjusting the dimensions of a banner will not suddenly make the page responsive.
Removing useful features without considering the user
Performance should improve the user experience, not become an excuse to remove everything users find useful. A video, calculator, product gallery or live-chat tool may affect performance, but it may also help customers make a decision or contact the business.
The correct question is not always, “Can we remove this?” It may be, “Can we load this more efficiently, delay it until needed or replace it with a lighter option?”
A perfectly fast website that no longer helps anybody is not the victory it might appear to be on the spreadsheet.
Installing another performance plugin
Performance plugins can be useful, particularly on platforms such as WordPress, but installing several of them without understanding what each one does can create new problems. Multiple tools may attempt to cache, defer, minify or combine the same resources, resulting in broken layouts, missing functionality and a website that performs brilliantly right up until somebody tries to use it.
Plugins should support a clear performance strategy rather than replace one. Understand the issue, choose an appropriate tool, test the change and make sure the website still works afterwards. Revolutionary stuff, we know.
Sending developers a score with no context
Developers need useful information. A PageSpeed Insights score does not explain which pages matter, which metric is failing, whether the problem affects real users or what level of improvement the business expects.
A better request might explain that mobile product pages are failing LCP, the main product image is consistently being identified as the largest element, the issue affects the full product template and those pages account for a significant proportion of organic revenue.
That gives the team a defined problem to investigate. “Please make this 100” gives them a reason to mute the conversation.
So, what is the key takeaway?
Core Web Vitals are useful because they turn parts of the user experience into measurements that can be monitored, investigated and improved. LCP helps us understand how quickly the main content appears, INP shows how responsive the page is when someone interacts with it and CLS highlights whether the layout moves around unexpectedly.
FCP and TTFB provide additional context by showing when the first visible content appears and how quickly the website begins responding. They are not part of the Core Web Vitals assessment, but they can help identify where loading delays begin and why LCP may be struggling.
Core Web Vitals matter for SEO because Google’s ranking systems use them as part of evaluating page experience, but they are not a shortcut to higher rankings and they should definitely not be viewed in isolation. Relevance, content quality, search intent, indexation, internal linking and the overall usefulness of the page all feed into Google’s decision process. A green report does not guarantee visibility, just as an orange report does not automatically mean the website is doomed.
Improve performance where it makes a meaningful difference, keep the wider SEO picture in mind and, above all, do not panic.
Leave a Reply