Maybe you’ve seen core web vitals around – whether in Google Search Console or elsewhere, but what does it mean? Core Web Vitals play a crucial role in determining the overall user experience of your website, which in turn affects your search engine rankings. That’s great, but what are the metrics, what do the metrics mean, and how do you measure them?
This post is going to get fairly technical. We’re going to look to use built in browser tools to gauge the various different elements of core web vitals. Are there better ways to do this? Yep – you can head right into Google Search Console (GSC) and look there, but its fun to geek out and really understand what these measurements are under the hood. Let’s get to it!
What Are Core Web Vitals?
Let’s start by breaking down what exactly Core Web Vitals are. These metrics, which include loading, interactivity, and visual stability, measure the user experience on your website. Understanding the importance of Core Web Vitals is crucial because they directly impact search engine rankings and user satisfaction.
Understanding the concept of Core Web Vitals is crucial for optimizing your website’s performance and user experience. To break it down further, here are six key aspects you need to know:
- Largest Contentful Paint (LCP): This measures how long it takes for the largest element on your webpage to load. Aim for an LCP of under 2.5 seconds for a good user experience.
- First Input Delay (FID): FID measures the time it takes for a webpage to respond to a user’s first interaction, such as clicking a button. A low FID score indicates a responsive website.
- Cumulative Layout Shift (CLS): CLS measures the visual stability of a webpage, focusing on the unexpected shifting of elements during loading. A lower CLS score means a more stable and user-friendly experience.
- Interaction to Next Paint (INP): Replacing FID in March 2024, INP measures the time it takes for the browser to visually respond to any user interaction, such as clicking, typing, or scrolling. A low INP score indicates a consistently responsive website throughout a user’s engagement.
Ok, let’s get into each of these a little more. We have the core 3 that have been in place for a while, and now we have INP coming on the scene and taking a leading role starting in March of this year.
First though, let’s talk about why these metrics are important. Have you ever visited a site, read a bit of the site, went to click…and the button moved?
If your site is slow or obnoxious (like a button that dodges clicks), it’s invariably going to drive down user engagement. Frustration = I’m not staying on your page.
Improving your website’s performance and user experience is crucial, and that’s where Core Web Vitals come in. Core Web Vitals is a reflection of performance and a good indication of the user experience. If the users are frustrated with your site, engagement will be lacking, dwell time will be low, and bounce rate will be high. These are all clear indications that your content is not meeting a user’s needs and satisfying search intent. As such, it’s critical to get your site performing as well as possible.
It’s kind of a double whammy – if your Core Web Vitals are off, Google will penalize you. Core Web Vitals are a direct ranking factor. What’s worse, here, however, is that if your site performance is poor, users are going to bounce. User engagement is another signal to Google. Bad perf plus users not sticking around means your page/site is going to fall even faster in SERP.
Now, let’s get into the specifics.
How to Start a Performance Recording in Chrome Dev Tools
This is where it gets a little geeky the post digs in on how to use Chrome Dev Tools to try and measure core web vitals. This is not the easiest way – but it is fun. This is a great way to dig further into the nuts and bolts and try to really understand what is having the biggest impact on your site’s performance.
This exact same process is followed regardless of which Core Web Vital is being measured. Follow these simple steps to get the dev tools open and a recording started.
1. Open the webpage you want to analyze.
In my case, I am opening https://sc.scomurr.com/seo-fundamentals-featured-snippets/
2. Open the Developer Tools:
- Windows/Linux: Press
- Mac: Press
- Or, hit the 3 dots in the upper right corner and browse to Dev Tools
- Or, hit F12 (at least on Windows)
I’m also going to configure my dev tools to present my browser as a mobile device. It’s always best to optimize for mobile first.
3. Navigate to the “Performance” tab.
4. Click the “Record” button (circled icon) to start recording a performance trace.
5. Reload the webpage (or click the “Reload” button in the toolbar).
With the dev tools open, if you right mouse click on the reload button you get a few options.
- Normal Reload: This is the standard page reload, similar to clicking the reload button or pressing F5. It will re-fetch resources, but might use cached versions if they are considered fresh.
- Hard Reload: This option forces the browser to re-fetch all resources from the server, ignoring any cached content. It’s more thorough than a normal reload and is useful for seeing changes that might be affected by caching.
- Empty Cache and Hard Reload: This option clears the browser’s cache for the page and then performs a hard reload. It ensures that all resources are fetched anew from the server, which can be helpful for developers when testing changes or debugging caching issues.
For this, I always go with Empty Cache and Hard Reload. This represents worst case scenario – optimize for for the worst and it’ll be a benefit across the board. Keep in mind that the cache in question here is the local cache – this does not necessarily overpower non client side caching.
6. Wait for the page to load fully.
<insert Jeopardy song here>
7. Click the “Stop” button (red square icon) to stop recording.
Now that you have a recording, we can dig in for LCP, FID, CLS, INP or any other TLA (three letter acronym) we want to throw at it.
Now let’s talk about Largest Contentful Paint (LCP). LCP refers to the time it takes for the largest content element on your webpage to load and become visible to the user. This metric is crucial because it directly impacts user experience and can affect your website’s ranking on search engine results pages. To measure and optimize LCP, you need to focus on improving server response times, optimizing images and videos, and minimizing render-blocking resources.
In general, the Largest Contentful Paint (LCP) refers to the largest element (image or text block) visible within the user’s viewport that finishes loading. It is considered a key metric for measuring webpage performance because it approximates the point when the main content of the page has likely loaded and becomes available to the user.
- LCP measures the time it takes for the largest image, video, or block-level text element to load on the page.
- It indicates when the most important content becomes available to users, allowing them to start engaging with your website.
- A good LCP score is crucial for providing a positive user experience, as a slow-loading largest element can frustrate users and lead to higher bounce rates.
Here’s how the LCP element is determined:
- Candidate Identification: The browser identifies all potential LCP candidates, which are typically the largest images, video thumbnails, background images, and text elements like headings and paragraphs.
- Size Comparison: The browser compares the size of each candidate within the viewport. The element with the largest area within the viewport becomes the LCP candidate.
- Paint Completion: The browser monitors the loading progress of the LCP candidate. Once the element finishes loading and is fully painted within the viewport, the current time is recorded as the LCP value.
Therefore, the LCP element can be different for different users depending on their screen size and the specific content displayed within their viewport.
Google considers an LCP measurement of under 2.5 seconds as good, so we always aim to achieve this benchmark.
I want to get to the nitty gritty and really determine what might be impacting my page performance, so that’s why we’re hopping into the Chrome Dev Tools. It turns out that my post on Featured Snippets actually has a lower LCP score than I would like. As such, let’s break it down with the built in browser tools and see if there is anything I can do to solve the performance issue.
1. Follow the instructions above to create a recording
2. Locate the LCP measurement:
- In the Performance panel, look for the “Timings” track.
- Within the Timings track, you should see an entry labelled “Largest Contentful Paint” (LCP).
- The LCP entry will have a timestamp indicating when the LCP occurred.
Here, we can see that LCP was 1.8 seconds. We’re aiming for < 2.5s, so we’re in the ballpark. It’s always good to run the test multiple times, and reconfigure for different mobile as well as test desktop.
3. What’s causing the slowness:
- To identify the specific element that triggered the LCP, hover over the LCP entry in the Timings track.
- A preview of the element will appear in the Performance panel, and the element itself will be highlighted on the webpage.
This screenshot is a little hard to decipher, so let’s walk it. First with a click on LCP within the timing swim lane it brings up the summary in the middle of the screen. From there, we see the timing (2.8s in this case – really bad) and it tells you the related node. In this case, it’s a <p>. By hovering over the related node, it highlights the content in the browser on the left. You can see that it’s the first text content of the post because it is highlighted.
- You can zoom in on the Timings track to get a closer look at the LCP event and other performance metrics.
- You can also export the performance recording as a JSON file for further analysis.
Here we can see that it’s the first paragraph of the post that’s getting flagged for being slow. What’s interesting is that I am testing both with the ads being displayed as well as without using a local ad blocker. I get a much lower LCP score each time I allow the ads to load. This is where I need to consider whether or not I want to allow the banner ad at the top of the page if it is going to impact overall performance.
To Do: Dig into making sure Google AdSense’s auto ads are loading async and there are no other blocking elements. Since my LCP is staying the same (it’s always paragraph 1), it is a little odd that the banner ad is impacting the LCP measurement. More to do here!
Here are some general tips and tricks to optimize for LCP. Unfortunately, every site is different, every page is different, and each situation is unique.
Content and Code:
- Prioritize above-the-fold content: Make sure the most important elements users see first are lightweight and load quickly.
- Minimize large images and videos: Optimize their size and consider lazy loading for content below the fold. I pretty much only use .webp images at this point.
- Preload key resources: Fonts, scripts, and critical images can be preloaded for a head start.
- Optimize font delivery: Use web fonts strategically and consider font display options.
- Leverage browser caching: Cache static resources like images and scripts for faster repeat visits.
- Minimize HTTP requests: Combine resources and optimize image formats to reduce roundtrips to the server.
- Implement asynchronous ad loading: Don’t let ads delay your main content. This is probably what is getting me – I intend on doing a blog post specifically around optimizing for Google AdSense in the future.
- Consider server-side rendering: Offload some rendering to the server for faster initial page load.
- Utilize a Content Delivery Network (CDN): Deliver content from geographically closer servers for quicker reach. I use Cloudflare for this – my site traffic is low enough that I still fall within the free tier.
- Monitor and analyze performance: Tools like Google PageSpeed Insights and Lighthouse offer valuable insights and optimization suggestions.
- Test and iterate: Every website is unique, so experiment with different configurations and find the sweet spot for your specific content and audience.
Iterate, and then iterate some more. Find a way to get that LCP to be consistently < 2.5s, and you will make Google happy.
First Input Delay (FID) measures the time it takes for a webpage to respond to a user’s first interaction, like clicking a button, tapping a link, or typing in a form. Essentially, it captures how quickly the page reacts to the user’s initial engagement.
First Input Delay (FID) is focused on the responsiveness of a page when a user first interacts with it.
- Key Press
Why is FID important?
FID is a crucial metric for website performance because it directly impacts user experience. A fast FID provides a sense of responsiveness and keeps users engaged. Conversely, a slow FID can lead to frustration, disengagement, and ultimately, higher bounce rates. I know if I have to wait…I’m probably not. If I click and we don’t go anywhere…well…I go somewhere else.
How is FID calculated?
The browser records the time between a user’s first interaction and the browser’s “time to first meaningful paint,” which occurs when the browser judges that the content has changed to the point where it is visually impactful for the user. This includes rendering dynamic elements like responses to clicks or changes in page layout.
Good vs. Bad FID scores:
- Good: Less than 100 milliseconds provides a smooth and responsive experience.
- Moderate: 100-300 milliseconds can still be acceptable, but some users might notice a slight delay.
- Poor: Above 300 milliseconds leads to frustration and significantly impacts user experience.
Now, let’s look at how to use the Chrome Dev tools just like we did with LCP to determine FID.
You can measure First Input Delay (FID) using Chrome Dev Tools, although it’s a bit indirect. FID measures the time from when a user first interacts with your site (i.e., when they click a link, tap on a button, etc.) to the time when the browser is actually able to begin processing event handlers in response to that interaction. Chrome Dev Tools do not give you the FID measurement like they do for LCP – we’ll have to do a little math.
Since FID is an event-based metric that requires real user interaction, it cannot be simulated or measured in a lab environment like with Lighthouse or other automated tools (not really). However, you can get an idea of FID by looking at similar metrics in Chrome Dev Tools. Let’s do it!
1. Follow the instructions above to create a recording.
- The only difference here is that you do need to click on something or press a key during the recording. I chose to click one of the links in the table of contents within the Featured Snippets post.
2. Find FID
- Hit Ctrl-F and search for ‘FID’
But, is this the true measurement we want to look at? Dev tools takes micro screenshots, and we can use those to tell a little more about the interaction.
Here’s click interaction – you can see the link being highlighted (turning red) as part of the interaction.
This is the spot!
3. Calculating the Measurement
- Grab the time stamps from the performance window and just do a little subtraction!
- Compare your FID score to the following benchmarks:
- Good: Less than 100 milliseconds (smooth and responsive experience)
- Moderate: 100-300 milliseconds (acceptable, but slight delay)
- Poor: Above 300 milliseconds (frustrating and impacts user experience)
In this case, the FID for the Featured Snippets posts seems to be around 35ms which is great!
- You can repeat the recording process with different interactions to analyze FID for various user actions.
- Iterate and measure for desktop vs. mobile.
- Measure with and without ads.
- Minimizing server response times.
- Preloading critical resources.
- Reducing layout shifts.
By focusing on these aspects, you can ensure your website responds quickly to user interactions, providing a more positive and engaging experience. There’s more that can be done, but this is a great place to start!
Let’s now talk about Cumulative Layout Shift (CLS). CLS refers to the unexpected shifting of webpage elements as it loads, causing a poor user experience. It is crucial to address CLS because it affects your site’s performance and user engagement. This one is a pet peeve of mine (as demo’ed by the GIF up top with the button moving). When I run into this, I run away.
Cumulative Layout Shift (CLS) measures how much a webpage unexpectedly shifts its layout while a user is viewing it. Imagine you’re reading an article online, and suddenly the content jumps down because an ad loads, or you tap a button but end up clicking something else because the layout shifted beneath your finger. These frustrating experiences are what CLS aims to quantify.
- Give me 5
- Up high
- On the side
- On the other side
- Down low…
If it’s too slow, you get a swing and a miss. If the site is performant with no CLS issues then there’s just a really nice down low “high five”, and you, as the reader, are happy.
Here’s a breakdown:
Focus: Visual stability of the page during interaction.
What it measures: The total amount of unexpected layout shifts that occur throughout the entire time a user is on the page.
Types of shifts: Any visible change in the position of an element, including:
- Images loading
- Ads appearing
- Content dynamically updating
- Fonts changing
Why is CLS important?
- A stable layout fosters a positive user experience, making users feel in control and preventing frustration.
- Google considers CLS as one of the Core Web Vitals, meaning it can impact your website’s search ranking.
- A high CLS can lead to increased bounce rates and decreased engagement.
How is CLS calculated?
CLS takes into account both the magnitude and frequency of layout shifts:
- Distance fraction: How much an element moves relative to the viewport size.
- Impact fraction: How likely a user is to be visually impacted by the shift.
These factors are combined to create a score ranging from 0 (no shift) to 1 (maximum shift).
Good vs. Bad CLS scores:
- Good: Less than 0.1 – Minimal shifting, excellent user experience.
- Moderate: 0.1 – 0.25 – Some noticeable shifts, but still acceptable for most users.
- Poor: Above 0.25 – Frequent and/or large shifts, significantly impacting user experience.
Let’s explore how to use Chrome Dev Tools to measure a website’s CLS and aim for a more stable and user-friendly web experience.
Measuring CLS in Chrome Dev Tools is super straight forward – the score is essentially given to you in the browsers. It’s just a matter of finding it!
1. Follow the instructions above to open Chrome Dev Tools and create a recording.
2. Locate Layout Shifts in the Performance Window
3. Find the CLS Score
- Within the Summary section of the page, the CLS score will be displayed. Simply select the CLS event from the swim lane furthest to the right and you have the cumulative score!
Pretty simple! Here, you can see there were only 2 layout shifts and they happened very fast. This content on the page is essentially static (this was recorded with no ads).
I re-recorded with ads enabled and then scrolled up and down the page. Here was the result from that test:
Despite this score floating into the mid range of acceptability, this was a pretty aggressive test where I forced all of the shifts as fast as I could by scrolling up and down very quickly a few times. I’m happy with this!
Here are a few tips for optimizing Core Web Vitals related to CLS (Cumulative Layout Shift). The goal here is just to prevent the screen from jumping around if and whenever possible.
- Size images properly and set height/width attributes so space is reserved for them as the page loads. Avoid images loading later and causing layout jumps.
- Avoid large changes in font size or element dimensions after initial render. This can cause content to suddenly shift.
- Use flexbox, grid, and other modern layout methods to create more predictable and stable layouts. Avoid floats and other older techniques.
- Load fonts asynchronously to avoid FOIT (flash of invisible text) and layout shifts when fonts load.
- Set min-height on containers/components so more space is reserved upfront if more content loads in later.
- Use server rendering frameworks to serve fuller HTML so less has to change and shift around on the client side.
- Use skeleton screens and placeholders to reserve space for loading components, avoid components suddenly appearing and forcing layout issues.
The key focus areas are reserving space properly for page elements so content doesn’t jump around, avoiding inserting additional elements that force shifts, and minimizing font and component dimension changes. This will lead to the lowest CLS score and optimization for core web vitals. And, most importantly, it will lead to a happier reader.
Interaction to Next Paint (INP)
So, what’s the difference between FID and INP? FID is really just focused on the very first interaction on a website, and it really only measures the time between the interaction and when the browser processes the interaction. It’s limited in that it doesn’t really consider event handler code or DOM re-re-rendering. INP seeks to address that by creating a measurement that more accurately assesses the impact of the interaction on the user experience.
What is INP
INP, or Interaction to Next Paint, is a web performance metric that measures the responsiveness of a webpage. It specifically captures the delay between a user’s interaction with a page (like clicking a link or button, typing in a text box, etc.) and the next visual update or “paint” of the page in response to that interaction.
Here’s a closer look at INP:
- Focus: INP measures the responsiveness of a web page during user interactions. It’s all about how quickly a page can visually respond to an input action.
- It’s the full interaction – not just the click -> handler. It’s the click -> handler -> processing -> rendering (paint…as in the next paint…as in the name)
- Types of Interactions Measured: This metric is concerned with various user interactions such as clicks, taps, and key presses. It measures the latency for these interactions.
- Why is INP important?:
- A low INP (quick response) enhances the user experience, making the site feel more responsive and interactive.
- Slow INP can lead to a perception of a sluggish or unresponsive page, impacting user satisfaction.
- INP is a critical factor in overall web performance, and improving it can lead to better user engagement and retention.
- How is INP calculated?:
- INP is measured in milliseconds (ms).
- INP is not just about the first interaction – it’s the worst case scenario for all interactions on the page during the page’s lifecycle.
- It typically measures the longest interaction delay that a user experiences within the 98th percentile of all interaction latencies.
- Good vs. Bad INP scores:
- Good: Typically, an INP of 100ms or less is considered good, indicating that the site responds quickly to user inputs.
- Poor: An INP longer than 300ms is often considered poor, as it indicates a noticeable delay in response to user interactions.
How to Measure INP with Chrome Dev Tools
1. Create a recording just as above.
- Again, we’re measuring interactions, so, an interaction or two will be required during the recording.
2. Identify the event you want to assess
For the interaction, I once again just clicked on a link within the table of contents.
The click is actually represented as two separate interactions within Chrome Dev tools. There’s a mouse down and then there’s a mouse up event. Should we measure INP starting from mouse down or should we start measuring it from mouse up? It somewhat depends, and Google is actually going to sample this over a bunch of interactions with your site as they calculate core web vitals and start to factor performance into ranking.
Next question, should total time end at the end of the animation? In this case, when the link in the table of contents is clicked, the site scrolls to the spot in the page where the link content exists. For my site, because the scroll is graceful, it takes about 200 MS from the time of mouse down to the animation being completed. That’s actually pretty good considering that I want this scroll to be graceful. In this case, we wouldn’t really want to measure all the way from mouse down all the way to the end of the animation as this is not going to accurately reflect what my INP score is.
How to Optimize for INP
Optimizing a site for INP (Interaction to Next Paint) involves several steps, starting with identifying any issues and then tackling it from both code and rendering perspectives. Here’s a breakdown:
1. Identify the Problem:
- Field Data: Use tools like Chrome’s Performance panel or Google Search Console reports to gather real-user INP data and understand which interactions are contributing the most to the delay.
- Lab Data: Analyze the data to pinpoint specific code blocks or rendering processes causing the delay.
2. Optimize Interactions:
- Reduce Input Delay: This involves minimizing background CPU activity on the main thread. Look for long tasks and consider offloading them to Web Workers or delaying them until after the critical rendering path.
- Optimize Event Callbacks: Ensure event handlers execute efficiently by avoiding complex calculations or DOM manipulation within them. Consider using asynchronous tasks to avoid blocking the main thread.
- Minimize Presentation Delay: Reduce the time it takes for the browser to paint the updated UI after receiving the user’s interaction. Techniques like optimizing CSS calculations, minimizing DOM mutations, and using efficient layout techniques can help.
3. Focus on Rendering:
- Avoid Large, Complex Layouts: Break down complex layouts into smaller, reusable components to reduce paint time.
- Minimize Layout Thrashing: Avoid dynamic changes that trigger repeated layout calculations. Use CSS media queries and sticky positioning effectively to reduce layout adjustments.
- Optimize DOM Size: Keep the DOM tree structure lean and efficient by avoiding unnecessary nesting and minimizing the number of elements.
By following these steps and utilizing the available tools, you can effectively optimize your site for INP and improve its responsiveness and user experience. Remember, iterative testing and analysis are crucial in identifying the most effective improvements for your specific site. Iterate and play!
You may be wondering why Core Web Vitals matter for SEO. Well, they have a direct impact on your search rankings, user experience, and bounce rates. If your website doesn’t meet the Core Web Vitals metrics, it could result in lower visibility in search results, frustrated users, and higher bounce rates.
Improving Core Web Vitals is crucial for SEO because it directly impacts search rankings. The better your website performs in terms of loading speed, interactivity, and visual stability, the higher it will rank in search engine results. Here are five reasons why Core Web Vitals matter for SEO:
- Better user experience: Websites that provide a seamless and enjoyable user experience tend to have lower bounce rates and higher engagement rates, which search engines take into account when determining search rankings.
- Mobile optimization: With the increasing use of mobile devices, search engines prioritize websites that are optimized for mobile, including fast loading times and responsive design.
- Competitor advantage: By prioritizing Core Web Vitals, you can gain an edge over competitors who neglect this aspect of SEO.
- Increased visibility: As your website ranks higher in search results, it becomes more visible to potential visitors, leading to increased organic traffic.
- Improved conversion rates: A fast and user-friendly website leads to higher conversion rates, as visitors are more likely to stay, explore, and make a purchase.
Optimizing Core Web Vitals is essential for SEO because it directly impacts:
- User experience
- Website visitors expect fast-loading pages and a smooth browsing experience
- Core Web Vitals like Largest Contentful Paint (LCP), First Input Delay (FID), Interaction to Next Paint (INP), and Cumulative Layout Shift (CLS) play a crucial role in meeting these expectations
- LCP measures how quickly the main content of a page loads
- FID & INP gauge interactivity
- CLS assesses visual stability
- Bounce rates
- If Core Web Vitals are not optimized, users may become frustrated and abandon the site, resulting in high bounce rates
- Search engines prioritize sites that provide a positive user experience
- Improving Core Web Vitals can lead to better rankings and increased organic traffic
Here are some other tools I may go into in future posts. These are going to be more run of the mill, and most likely be the tools one would use to tune a web site for the purposes of core web vitals:
- Google Search Console
- This report offers a comprehensive overview of your website’s Core Web Vitals performance based on real-world user data (CrUX).
- It allows you to identify pages with poor Core Web Vitals scores and prioritize optimization efforts.
- Search Console also provides valuable insights into the distribution of your Core Web Vitals scores across different user segments (e.g., mobile vs. desktop).
- This Chrome extension audits your web page and provides a detailed report on its performance, including Core Web Vitals metrics.
- You can run Lighthouse directly on any webpage to gain real-time insights into its performance.
- Lighthouse also integrates with various development tools and workflows, making it a convenient option for developers.
There are other tools out there (some paid, some free) but they all essentially engage with your site/pages, assess the performance, and then give pointers on how to fix. At the end of the day, GSC is really where you want to start. This is Google themselves telling you what to look at and what to fix in order to help drive your rankings!
This was kind of a geek out post. I hope by going into the Chrome Dev Tools it helped some folks get a better understanding of what is being measured as part of Core Web Vitals. A deeper understanding helps identify the things that really need to be fixed on a page or site and can really have a positive impact on SEO and rankings.
- Core Web Vitals: A Guide to Improving Page Speed (semrush.com)
- Core Web Vitals report – Search Console Help (google.com)
- Core Web Vitals: What They Are & How to Improve Them (backlinko.com)
Are core web vitals a ranking factor?
Yes, core web vitals are a confirmed Google search ranking factor as of May 2021. Specifically, Google uses the core web vitals metrics – Largest Contentful Paint, First Input Delay, and Cumulative Layout Shift – to help determine search rankings. Sites that have “good” core web vitals measurements tend to rank higher than those with “poor” metrics.
What are core web vitals?
Core web vitals are a set of 3 key metrics that Google considers essential to providing users with a great browsing experience:
Largest Contentful Paint (LCP): Measures loading performance – specifically when the main content of a page is rendered. Values below 2.5 seconds are considered “good”.
First Input Delay (FID): Quantifies responsiveness – how fast a page responds when a user clicks or taps on it. Values below 100 milliseconds are considered “good”.
Cumulative Layout Shift (CLS): Captures visual stability – unintended movement of page elements as the page loads. Values below 0.1 are considered “good”.
Input to Next Paint (INP): Measures interactivity – the time from when a user interacts with a page to when that interaction’s effect is visually displayed. INP highlights gaps between user inputs and visual feedback. Lower INP values indicate better interactivity. This metric provides additional insight into a site’s real-world responsiveness beyond only First Input Delay.
Together, these metrics help web developers quantify, measure, and optimize the real-world experience their sites are providing to users. By focusing efforts on improving core web vitals measurements, sites can deliver faster loading speeds, respond quicker to interactions, and avoid unexpected content jumps. This leads to happier users as well as better SEO through improved Google search rankings.
Why are core web vitals important?
Core web vitals are important because they directly measure key aspects of a user’s browsing experience. Fast loading times, responsive interactions, and visual stability are essential to providing a great site visitor experience.
Specifically, good core web vitals scores help:
Boost user engagement and retention
Improve site conversion rates
Enhance brand reputation and trust
Unlock better SEO through higher Google search rankings
Optimizing for core web vitals also results in performance optimizations like faster page loads, efficient scripts, and minimal interface lag. Users prefer sites that feel fast and responsive. By making core web vitals a priority, web developers can quantify and deliver excellent real-world site experiences that users notice and appreciate. This drives positive business impacts over time across metrics like more page views, lower bounce rates, and increased revenue.
What is CLS core web vitals?
Cumulative Layout Shift (CLS) is one of the three core web vitals metrics that quantify user experience. CLS specifically measures visual stability – how much content shifts unexpectedly as the page loads.
CLS is quantified by calculating shifts for each visible element and summing their individual layout shift scores over the entire loading period. The final CLS score is thus the total cumulative shift of all elements across multiple shifts.
Values below 0.1 are considered “good” CLS by Google. A score under 0.25 is rated as “needs improvement” while above 0.25 is “poor”. Optimizing pages to minimize layout shifts as elements load improves perception of site responsiveness. It reduces frustration from having to re-find content that abruptly moves. Thus, CLS is a key metric in assessing real user experience.
What is INP core web vitals?
Input to Next Paint (INP) is an emerging core web vitals metric that measures interactivity. Specifically, INP traces the time from when a user first interacts with a page (i.e. when the input event happens) to when the browser is able to produce the next visual change reflecting that interaction (i.e. when the next paint occurs).
INP highlights gaps between user inputs and visual feedback. Lower INP values indicate better interactivity by quantifying how long users must wait to see the results of their actions represented visually. Values under 100ms are considered “good”.
While First Input Delay focuses on initial responsiveness, INP more directly captures the ongoing interaction experience. Monitoring INP identifies opportunities to optimize interactivity even if initial input delay is good. INP will likely join LCP, FID and CLS as a key component of measuring overall user experience and site performance with core vitals.
What is LCP core web vitals?
Largest Contentful Paint (LCP) is one of the three core web vitals metrics that quantify user experience. LCP specifically measures loading performance – identifying the point when the main content of a page is fully rendered.
LCP is calculated by tracing from the initial navigation start to when the largest image or text block visibly renders. Values below 2.5 seconds are considered “good” LCP by Google. A score under 4.0 seconds is rated as “needs improvement” while above 4.0 seconds is “poor”.
Optimizing pages to decrease LCP reduces the waiting time that users perceive before they can start interacting with page content. This improves engagement during the all-important initial loading sequence. Thus, LCP is a key metric for assessing real site loading speeds and user perception of performance.
What is FCP core web vitals?
First Contentful Paint (FCP) is an important web performance metric, but it is not classified as a Core Web Vital by Google.
The Core Web Vitals currently include Largest Contentful Paint (LCP), First Input Delay (FID), and Cumulative Layout Shift (CLS). FCP tracks the time from navigation start to when the browser renders the first bit of content.”
What is FID core web vitals?
First Input Delay (FID) is one of the three current core web vitals metrics that quantify user experience. However, Input to Next Paint (INP) will replace FID as a more direct measure of interactivity in March 2024.
FID specifically measures responsiveness – quantifying the time from when a user first interacts with a page to the time when the browser is actually able to respond to that interaction.
FID is calculated by tracing from when the initial input event (such as tap, click, etc.) happens to when the main thread is available to reactively process a handler in response. Values below 100 milliseconds are considered “good” FID by Google. A score under 300 ms is rated as “needs improvement” while above 300 ms is “poor”.
Optimizing to decrease FID improves user perception of site readiness and responsiveness. It reduces latency between a user action and the interface providing feedback. Thus, FID is a key metric for assessing real world interactivity.