Glossary of Web Performance Metrics

Backend

Sometimes also called "Time to First Byte" or "TTFB". The time from the start of the initial navigation until the first byte of the base HTML page is received by the browser (after following redirects). In RUM this is responseStart from Navigation Timing specification. This typically includes the bulk of backend processing: database lookups, remote web service calls, stitching together HTML, etc. This is a good approximation of the time it takes your server to generate the HTML on the server and then deliver it over the network to the user's browser.

Cumulative Layout Shift (CLS)

Cumulative Layout Shift is a score that captures how often a user experiences unexpected layout shifts as the page loads. Often ads that load late in the page load can push important content around while a user is already reading it. Aim for a score less than 0.1. Here's how the score is calculated.

Cumulative Layout Shift is one of Google's Core Web Vitals, along with Largest Contentful Paint and Interaction to Next Paint.

First Contentful Paint (FCP)

First Contentful Paint (FCP) is provided by browsers as part of the Paint Timing spec. It's the time at which users can start consuming page content. Specifically, it is "the time when the browser first rendered any text, image (including background images), non-white canvas or SVG." As of January 2019, this is available from Chrome, Opera and Android.

Frontend

The backend time is the time it takes the server to get the first byte back to the client. The frontend time is everything else. This includes obvious frontend phases like executing JavaScript and rendering the page. It also includes network time for downloading all the resources referenced in the page. Specifically it is loadEventStart minus responseStart from Navigation Timing.

Fully Loaded

The Fully Loaded time is measured as the time from the start of the initial navigation until there was 5 seconds of no network activity after Document Complete. This will usually include any activity that is triggered by JavaScript after the main page loads.

Interaction to Next Paint (INP)

Measures the time from when a user initiates an interaction until the next frame is painted. Only the following interactions are observed: mouse click, touchscreen tap, and a physical or onscreen key press.

INP has replaced First Input Delay (FID) as a core web vital as of March 2024.

Interaction to Next Paint is one of Google's Core Web Vitals, along with Largest Contentful Paint and Cumulative Layout Shift.

Largest Contentful Paint (LCP)

Largest Contentful Paint is provided by browsers via the Largest Contentful Paint API. It's the time at which the largest element in the viewport is rendered. It's only tracked on certain elements, e.g., IMG and VIDEO (see more here). As of August 2019, this is available in Chrome 77+.

Largest Contentful Paint is one of Google's Core Web Vitals, along with Cumulative Layout Shift and Interaction to Next Paint.

SPA: LCP may be present for a SPA navigation if the LCP candidate rendered during the transition is larger than the previous LCP. This is not considered a reliable metric for SPAs given that is it not a true 'continuous' metric.

Page Load

The Page Load time is measured as the time from the start of the initial navigation until the beginning of the window load event (onload). For SPAs using SpeedCurve RUM, it's the time between LUX.init and LUX.send.

While Page Load can be a useful metric it can also be deceiving as depending on how the page is constructed it doesn't always represent when content is rendered to screen and the user can interact with the page. Unfortunately many organizations and other monitoring tools still default to reporting Page Load as an important performance metric. It's in no way a good measure of the user's experience and something the industry needs to move on from.

Start Render

The Start Render time is measured as the time from the start of the initial navigation until the first non-white content is painted to the browser display. Any CSS and blocking JS you have on the page has to be downloaded and parsed by the browser before it can render anything to screen. This is called the critical rendering path and the Start Render metric is very important in understanding how long users have to wait before anything is displayed on screen.

In RUM, Start Render is the value of First Paint from the Paint Timing spec. As of January 2019, this is not available in Safari and Mobile Safari, In synthetic, it's based on analyzing the tenth-of-a-second screenshots to see when rendering begins.

Time to Interactive

Formerly known as Time to Consistently Interactive. Renamed to be consistent with Lighthouse 3.0.

Time to Interactive (TTI) measures how long it takes a page to become interactive. "Interactive" is defined as the point where:

• The page has displayed useful content, which is measured with First Contentful Paint.
• Event handlers are registered for most visible page elements.
• The page responds to user interactions within 50 milliseconds.

Specifically, it is the first span of 5 seconds where the browser main thread is never blocked for more than 50ms after First Contentful Paint with no more than 2 in-flight requests. In other words, it's the same as First CPU Idle but it also checks the number of in-flight network requests.

Total Blocking Time (TBT)

Total Blocking Time (TBT) is one of Google's recommended Core Web Vitals metrics for lab/synthetic testing. While it's great that Web Vitals includes a CPU metric, there are a couple of caveats you should be aware of if you're tracking Total Blocking Time (you can read more about those caveats here):

1. Total Blocking Time only tracks the long tasks between First Contentful Paint (FCP) and Time To Interactive (TTI). For this reason, the name "Total Blocking Time" is a bit misleading. Any long tasks that happen before FCP and block the page from rendering are NOT included in Total Blocking Time. TBT is not in fact the "total" blocking time for the page. It's better to think of it as "blocking time after start render".
2. TBT doesn't include the first 50ms of each long task. Instead, it reports just the time spent over the first 50ms. A user still had to wait for that first 50ms. It would be easier to interpret TBT if it included the first 50ms and better represented the full length of time a user was blocked by a long task.

User Timing

User Timing allows you to measure the performance of specific page elements that you've identified as essential to the user experience for your own pages. The W3C User Timing spec provides an API for developers to add custom timing metrics to their web apps. This is done via two main functions:

• performance.mark records the time (in milliseconds) since navigationStart
• performance.measure records the delta between two marks

There are other User Timing APIs, but mark and measure are the main functions. Once you've added marks and measures on your pages, you can collect data with both RUM and Synthetic.

Visually Complete

Visually Complete is the time at which all the content in the viewport has finished rendered and nothing changed in the viewport after that point as the page continued loading. It's a great measure of the user experience as the user should now see a full screen of content and be able to engage with the content of your site.