Key web performance metrics in 2024

Key web performance metrics in 2024

Updated: 10 Jan 2024

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.

Jump to a metric:

What are the Core Web Vitals? Jump to heading

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):

  1. Largest contentful paint (LCP)
  2. Cumulative layout shift (CLS)
  3. First input delay (FID), to be replaced by Interaction to next paint (INP) in March 2024

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? Jump to heading

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.

What are the key performance metrics in 2024? Jump to heading

Now that we have a bit of context, let's cover each of the most popular ones in 2024. I've broken these up into three categories:

  1. Loading speed metrics: The Core Web Vitals focuses on largest contentful paint (LCP) for how a user perceives loading speed. It's one of the last steps for loading speed, so several things must happen before LCP. This is why time to first byte (TTFB) and first contentful paint (FCP) are useful metrics to track. They can break down that time to LCP in smaller chunks each with its own causes for slowness.
  2. Responsiveness metrics: Here, when I say "responsive", I'm talking about how the browser responds to user interaction. "Interactivity" is another way to think of it. Either way, JavaScript is usually what's to blame when a user attempts an action but the response is delayed. Currently, the Core Web Vitals metric is first input delay (FID), but that will soon switch to interaction to next paint (INP) in March. Total blocking time (TBT) also helps us better understand the picture.
  3. Frustration metrics: Technically, all of these metrics lead to frustration. However, cumulative layout shift (CLS) is the only one that affects frustration but not speed.

Let's dive into each metric...

Loading speed: Time to first byte (TTFB) Jump to heading

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.

Request arrow from client (laptop) to server, and response arrow from server to client
TTFB includes the time from when the request started to when the first byte of information returns to the client (browser).

A TTFB of less than 0.8s is considered good, and over 1.8s is poor.

Things that impact that TTFB are server response times (complex queries, high traffic) and distance to that server (no CDN).

If you're a Shopify merchant, most of this is out of your control except for the rendering of your website. Complex Liquid loops can make the server slower to respond. Check out How to Do an In-depth Liquid Render Analysis with Theme Inspector to learn more about how to measure your site and the common pitfalls.

Loading speed: First contentful paint (FCP) Jump to heading

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.

Screenshots from a load showing a blank screen for several frames then only the navbar then finally the full page
FCP occurs when the first non-white content is rendered on the page, in this case at 2.0 seconds.

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. Learn more about how the browser renders a page and how to fix this issue in How to Eliminate Render-Blocking Resources: a Deep Dive.

Loading speed: Largest contentful paint (LCP) Jump to heading

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.

Chevrons indicating time showing that TTFB feeds into FCP and LCP, and FCP feeds into LCP
LCP includes TTFB and FCP. The differences between each of these metrics can help us figure out root causes for slow load times.

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 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.

Learning how to use a tool like WebPageTest is key for finding and fixing problems related to both FCP and LCP. Check out our post How to benchmark and compare tests using WebPageTest if you want to get started.

Responsiveness: First input delay (FID) Jump to heading

First input delay, or FID, is the amount of time the browser takes to start responding to a real user interaction (click, tap, or other input). You might be wondering how you could measure this in Lighthouse. You can't! It's only a field or real-user metric.

A user clicks a button but the main thread is busy with another script. Then it's finally free (FID), and can process the click event, run a script for it, and finally do layout/paint to show the visual change to the user.
FID measures when the main thread is capable of responding to a user interaction.

A FID of less than 100ms is considered good, and over 300ms is poor.

Too much JavaScript running on the main thread is the primary culprit for FID 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 app and third party bloat. Remove ones that are no longer used, and evaluate the rest in terms of the trade-offs between performance and feature benefits.

Responsiveness: Total blocking time (TBT) Jump to heading

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 resouces have finished loading and the main thread can reliably respond to user input. Remember how FID 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 FID or INP (more on INP coming).

The Chrome Dev Tools performance panel showing lots of red.
This example from the Chrome Dev Tools performance panel shows all the scripts that had long tasks blocking the main thread using red fills and triangles.

A TBT of less than 200ms is considered good, when tested on average mobile devices. The same causes for poor FID lead to poor TBT.

Responsiveness: Interaction to next paint (INP) Jump to heading

Interaction to next paint, or INP, is a new metric that measures the amount of time it takes for the browser to paint the next frame (show a change on screen) after a 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. Similar to FID, this can only be measured with real users. Unlike FID, it is measured for the duration of a session, not just for the first interaction, and reports the worst or nearly worst time.

A user clicks a button but the main thread is busy with another script. Then it's finally free (FID), and can process the click event, run a script for it, and finally do layout/paint to show the visual change to the user (INP).
INP measures when a visual change happens after a user interaction.

An INP of less than 200ms is considered good, and over 500ms is poor.

For slow INP, the same causes for poor FID and TBT lead to poor INP. 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.

Frustration: Cumulative layout shift (CLS) Jump to heading

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 filmstrip of screenshots showing page elements shifting around as new content arrives.
WebPageTest filmstrip view of all the layout shifts occuring on load of [The Metric Times](https://www.webpagetest.org/themetrictimes/index.php). Shifted content is highlighted in red.

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 webfont
  • An animation

Make sure you reserve space for images and try to provide better fallbacks for webfonts.

Resources Jump to heading

Check Using the Chrome UX Report on PageSpeed Insights for the latest metric thresholds.

Header photo by Mitchel Boot on Unsplash

CONTENTS

Read similar articles tagged...

Back to blog