Basic Core Web Vitals
Help you gain basic understanding of the Core Web Vitals and use it to better troubleshoot your site performance issues.
Web performance metrics can seem like an alphabet soup of acronyms. For someone new to the topic, it can be a real hurdle to understanding what's going on. In this post, I'll describe each metric in a beginner-friendly way. I'll also focus more on the concepts and impact of each rather than the technical definitions.
What are the Core Web Vitals?
The Core Web Vitals are a class of specific metrics created by the Chrome team. They are currently limited to 3 metrics which are focused on user experience (more on each later):
Largest contentful paint (LCP)
Cumulative layout shift (CLS)
Interaction to next paint (INP)
These three metrics together are meant to focus on how a user experiences loading, interactivity, and visual stability. We use several more metrics that help us debug performance issues, but these three are meant to summarize user experience. And guess what? User experience can impact SEO...
How do performance metrics impact my SEO?
Search engines try to offer the best content results for a user. Google considers how a user experiences a website to contribute to the quality of that content. We should already care about performance because it can lead to lower conversions and faster abandonment. Why would a search engine ignore those issues? Thus, the Core Web Vitals also feed into your search engine and ad rankings for Google.
How big is their impact? We don't know for sure, but content is still king. If your content quality is above competitor websites, you might be impacted less. However, for two sites with close to equivalent content quality, the faster one is more likely to be ranked higher. The lesson here is don't let web performance be the reason why you're losing your ranking.
Loading speed: Time to first byte (TTFB)
Time to first byte, or TTFB, is the time from when a user first requests a page (clicks on a link or types in the URL) to when the first byte of data returns to the browser from the server.
A TTFB of less than 0.8s is considered good, and over 1.8s is poor.
Things that impact TTFB are server response times (complex queries, high traffic) and distance to that server (no CDN).
Loading speed: First contentful paint (FCP)
First contentful paint, or FCP, is the time from when a user first requests a page (same as TTFB), until the first content (text, image, or non-white canvas or SVG) is rendered on the page. As you might have noticed, it also includes the TTFB. When we use FCP for performance debugging, we focus more on the time after TTFB.
An FCP of less than 1.8s is considered good, and over 3s is poor.
Things that can impact FCP outside of TTFB are render-blocking resources, connections to multiple domains (origins), and many more. Most problems are usually related to render-blocking resources. CSS is a render-blocking resource because we don't want to see the unstyled page before switching to a styled page. JavaScript can be render-blocking depending on how it is loaded and used.
Loading speed: Largest contentful paint (LCP)
Largest contentful paint, or LCP, is the time from when a user first requests a page (same as TTFB), until the last largest element on the visible screen (viewport). is rendered. It has the same starting point as TTFB and FCP. Similar to FCP, we focus more on the time after these other metrics when debugging LCP.
An LCP of less than 2.5s is considered good, and over 4s is poor.
Most LCP elements are images. Often, the LCP element will change based on screen size since we build websites to be responsive and mobile-friendly. Thus, common things that can impact LCP are related to the loading of the image or font used for the LCP element. For example, if you use a front-end framework like Vue or React, the browser might not know that it needs an image until after it has downloaded multiple files and parsed (read) them. Another example is poor prioritization leading to less critical assets being loaded before the ones needed for the LCP element.
Responsiveness: Interaction to next paint (INP)
Interaction to next paint, or INP, measures the amount of time it takes for the browser to paint the next frame (show a change on screen) after user interaction. Think of when you click on a button on a website but don't get any visual feedback that you performed an action until after some delay. INP can only be measured with real users. It is measured for the duration of a session, not just for the first interaction, and reports the worst or nearly worst time.
An INP of less than 200ms is considered good, and over 500ms is poor.
Too much JavaScript running on the main thread is the primary culprit for INP problems. The main thread cannot run scripts and respond to user inputs at the same time, so long scripting time trips up responsiveness. This could be due to long tasks, too many dependencies, too many third-party scripts, and more.
On merchant sites, we see a lot of apps and third-party and tag manager bloat. Remove ones that are no longer used, and evaluate the rest in terms of the trade-offs between performance and feature benefits.
For slow INP later in the page lifecycle, evaluate specific interactions using a performance profiler to look for opportunities to reduce or prioritize work on the main thread.
Responsiveness: Total blocking time (TBT)
Total blocking time, or TBT, measures the amount of time the main thread was blocked from FCP until time to interactive (TTI). TTI is when the main resources have finished loading and the main thread can reliably respond to user input. Remember how INP can only measure real user interactions? TBT is a "lab" metric that we can measure anytime we run a test. It helps us better predict when we may have a problem with responsiveness that would show up in INP.
A TBT of less than 200ms is considered good when tested on average mobile devices. The same causes for poor INP lead to poor TBT.
Cumulative layout shift (CLS)
Cumulative layout shift, or CLS, measures the largest "burst" of unexpected layout shifts during a page session. The technical definition can be complex, but generally, we don't want the elements on a webpage to move around unless the user would expect it from an interaction. Layout shifts can be very annoying. Think of how many times you clicked the wrong button because it shifted down right before you clicked. Or when you lose your place while reading an article because an ad finally finished loading.
A CLS of less than 0.1 is considered good, and over 0.25 is poor. It lacks metrics because the score is the product of the impact fraction and distance fraction. To understand the calculation in more detail, check out the Layout shift score.
Common culprits for unexpected layout shifts include:
An advertisement or image loads (without space reserved for it)
An announcement or cookie banner injected at the top of the screen
A shift from a fallback font to a web font
An animation
Last updated
Was this helpful?