The first step to addressing your website’s speed is knowing how long it takes your website to load. There are many metrics you can use to evaluate your website’s load time, but you don’t need to track every single one of them. In this article, I will review the key speed metrics you should use to evaluate your website’s performance, including an in-depth look at Google’s Core Web Vitals. 

Understanding Google’s Core Web Vitals

Core Web Vitals is part of Google’s Page Experience algorithm, which evaluates a website based on its user experience. Keep in mind that Core Web Vitals are only one of the things that make up a good page experience. Other factors include security, page layout, and removing distracting ads.

There are three metrics evaluated as part of Core Web Vitals: Interaction to Next Paint (INP), Largest Contetful Paint (LCP) and Cumulative Layout Shift (CLS).

Field Data vs. Lab Data

Google measures Core Web Vitals with performance timing data for actual, real-world people who visited your website using a Chrome browser over the last 28 days. This is referred to as field data. You can view the field data for your website’s pages using PageSpeed Insights. Note that not all websites will have field data because they do not have a sufficient number of visitors. As well, only indexable pages are considered as part of the field data.

PageSpeed Insights also provides lab data. Lab data is based on a simulated test of your website’s performance. While useful, lab data is not as important as field data because only field data represents the speed experienced by real people visiting your site.

Learn more about using PageSpeed Insights and other ways of measuring Core Web Vitals.

Are Core Web Vitals a Google Ranking Factor?

Sort of, but Google hasn’t made this all that clear. In 2024, Google said that they never said Core Web Vitals was a ranking factor. However, their latest guidelines updated in 2025 say that “Core Web Vitals are used by our ranking systems.” There has also been an idea that Core Web Vitals operates as a tie breaker, however, in 2021, Google said “just because your website is faster with regards to Core Web Vitals than some competitors doesn’t necessarily mean that …you will jump to position number one in the search results.”

Bringing all this together, my take is that speed in general and Core Web Vitals in particular have a lot of ways it affects how your website ranks in search results. Many of those ways will be indirect. For example, slower websites are harder to crawl and websites that are harder to crawl will not rank as well. 

Even if it is a ranking factor, I think we can safely conclude that Core Web Vitals is not a primary ranking factor. Google will not rank a website highly in results simply because it loads fast. As well, there are plenty of slow-loading websites that rank highly in search results. Google prioritizes high-quality content over fast websites, but if you can have a fast website along with high-quality content, that will make the website easier to use for your visitors and improve overall site performance. 

Interaction to Next Paint (INP)

INP measures the time between a user interacting with a webpage (like clicking a button or a link) and the result of that interaction appearing on the user’s screen. If there is a longer delay between the visitor’s action and the result of that action, the website will feel broken and unresponsive to visitors. Slow interaction times will deter people from interacting with the website and keep people from converting.

When somebody interacts with a website, there are three phases to that interaction: 

  • Input delay: The time between a user interaction and when the webpage begins to respond.
  • Processing time: The time it takes the website’s code to process the response.
  • Presentation delay: The time it takes the browser to render and paint the result to the user’s screen.

To help you understand that better, consider the following image from Web.dev. This image shows the full interaction process. The star with the mouse over it is when a user interacts with the page. There is a brief input delay, followed by the processing time and then the presentation. 

Note that this image also shows the difference between INP and the metric it replaced, First Input Delay (FID). INP and FID both measure aspects of an interaction, but INP is more comprehensive, covering all aspects of the interaction and measuring interactions across the entire page.

interaction process showing what INP and FID measure

A few other important things to note about INP:

  • INP observes click, tap, and key press interactions. Scrolling and hovering interactions are not observed (currently). 
  • INP observes all interactions with a webpage, not just the first interaction. 
  • The final INP value will only reflect the longest INP observed on that page.

Largest Contentful Paint (LCP)

Largest Contentful Paint (LCP) measures when the largest element on a given page of your website is rendered (displayed) in the browser. LCP doesn’t mean your entire website needs to load within time constraints. Instead, LCP is measuring how long a visitor to your website must wait before they can see the main content of a page. The longer people have to wait, the worse the experience of using that website.

Text, images, background images, and videos are all considered candidates for LCP. Some non-content items may be omitted from consideration, including placeholder images, invisible elements, and items that cover the whole screen that are likely background material.

An assumption about LCP is that the largest elements on a page represent the main content of the page. More often than not, that assumption proves to be true. Larger elements like images, videos, and blocks of text are typically more important for visitors to see and need to be visible as quickly as possible. 

If you find that larger elements on your page are less important for visitors, you may need to retool your page’s design. I’ve seen instances where the Largest Contentful Paint item was a large, decorative image. The image took a while to load, slowing LCP times, even though the actual important parts of the page loaded more quickly. 

LCP specifically measures what is rendered in the visible portion of the user’s browser, known as the viewport. This will evaluate the items in the first viewport people see on the page. Items outside this viewport are not counted toward LCP. Because the viewport changes depending on the device’s screen dimensions, one of the first steps to improving your LCP is measuring what viewport sizes your visitors are using.

Cumulative Layout Shift (CLS)

Cumulative Layout Shift (CLS) measures how much the various elements move around on the visitor’s screen in an unexpected manner while the page is loading. The goal is to minimize unexpected movement. A high CLS score makes the page visually unstable and much harder for visitors to use. A high CLS can also make it harder for AI agents to use your website.

CLS is based on a formula that produces a decimal value that measures the total amount of unexpected shifting that occurs on a website. This formula multiplies two metrics: impact fraction and distance fraction. 

  • Impact fraction: how much of the viewport is affected by the shift
  • Distance fraction: how much the shifting element moves

I think it is helpful to keep these two fractions in mind to have a more intuitive understanding of CLS. If your page has a high CLS score, start by understanding not only what moved, but how far it moved and how much of the viewport was affected by the shift. The more space the shifting element takes up, the bigger the problem. The larger the distance the element moves, the bigger the problem. 

Another thing to keep in mind is that the layout shift score is not measured as the total shifting across the entire session with the page. Instead, shifting is measured by evaluating session windows where the shifting occurs. A session window starts when the shift is detected and lasts up to five seconds. A window includes a group of one or more shifts that occur during those five seconds. The session window with the largest amount of layout shift is used for the page’s final CLS score.

This image from Web.dev provides an example of different session windows. Blue bars represent the scores of each individual layout shift.

Layout shift windows

Bringing this all together, to fix a high CLS score, you want to focus on minimizing the size of the elements that move and minimizing how far those elements move. You also want to reduce how much shifting happens at any given time.

Other Key Speed Metrics

There are a few basic speed metrics that should be measured for every website to help you understand important steps within the website loading process. These help us understand other aspects of how the website is loading and can also clarify how to improve Core Web Vitals.

  • Time to First Byte (TTFB): TTFB measures how long it takes from when a URL is requested to when the first byte of information is returned from the server. If TTFB is high, that indicates problems with your website server and hosting configuration, which will inherently slow down all other metrics. A high TTFB is the most common reason I see for slower Core Web Vitals, especially slower Largest Contentful Paint and Interaction to Next Paint times.
    • This is also related to Average Response Time, measuring how quickly Google crawls the files on your website.
  • First Contentful Paint (FCP): FCP measures how long it takes between the request for a URL and when content is painted, or displayed, on the page for visitors. A high FCP usually means your website is loading too many files (images, JavaScript, CSS, etc.) that are delaying the browser’s ability to paint the webpage. If FCP is slow, the rest of painting the website will be slow too, including Largest Contentful Paint (LCP).
  • Total Blocking Time (TBT): TBT measures the total amount of time a web browser is blocked by long tasks and is unable to respond to a visitor’s interactions, such as clicks, taps, or form inputs. A long task includes things like executing heavy JavaScript or calculating layouts. Technically, this measures the time between First Contentful Paint (FCP) and when the site can be interacted with (which can be measured by Time to Interactive, though this metric is no longer reported by PageSpeed Insights).
  • Transfer Size: Transfer size measures how many bytes of data need to be sent from the server to the browser to load the webpage. You can measure the overall transfer size for all files loaded on an entire webpage, or you can look at the transfer size of specific individual files. This can be confused with Resource Size. However, Transfer Size represents the data actually sent over the network, which is often reduced via compression, while Resource Size measures the byte size of the file after the browser has received and decompressed it. The more bytes that need to be sent, the slower the website will load.

How Fast Should Your Website Load?

As you begin measuring speed, the question becomes how fast your website should load. What are the benchmarks? What does Google require for Core Web Vitals? 

While you should aim to hit these benchmarks, remember that speed is relative. Your visitors are comparing your website’s speed relative to your competitors. If your competitors all have exceptionally fast websites that load more quickly than these benchmarks, then your website also needs to load that much faster.

Basic Speed Metrics Guidelines

  • TTFB: Below 800 milliseconds (over 1.8 seconds is slow).
    • Average Response Time: below 1,000 milliseconds
  • FCP: Below 1.8 seconds (over 3 seconds is slow).
  • TBT: Below 200 milliseconds (over 600 milliseconds is slow)
  • Transfer Size: Keep it as small as possible. As of May 2026, the median total transfer size is just over 3 megabytes on desktop and 2.6 megabytes on mobile.

Core Web Vitals Guidelines

  • INP: A “Good” score is an interaction response under 200 milliseconds, while over 500 milliseconds is poor.
  • LCP: The largest content element must load in 2.5 seconds or less, and anything greater than 4 seconds is considered slow.
  • CLS: A “Good” layout shift score must be 0.1 or less, while anything above 0.25 is poor.

Final Thoughts

Optimizing your website’s speed is about selecting the metrics that are most meaningful for your website and continually evaluating them to identify areas for improvement. If you have any questions or if you need help measuring and optimizing your website’s speed, please contact me. You can also find more details about each of these speed metrics and Core Web Vitals in my book Speed Metrics Guide.