Speed Analysis Lab and RUM metrics (A-Z list)

The DOM Complete measures the time to fully build the DOM. 

Understanding DOM Complete
All scripts within the DOM, including those with the async attribute, have been executed. All the page’s sub-resources defined in the DOM are loaded (images, iframes, etc.).

The Load Event Start  immediately follows DOM Complete. In most cases, these 2 metrics are equals. The only additional delay that could be introduced before Load Event Start would be caused by treatments handled by onReadyStateChange.

Collected from: Web Browser (API)

The DOMContentLoaded (DCL) is an event fired by the web browser. It has a start and an end as listeners can be attached at the event to trigger JavaScript execution when the event fires (that's basically what's jQuery.ready is doing).

The DOMContentLoaded event fires when the initial HTML document has been completely loaded and parsed (without waiting for images, and iframes to finish loading).

Blocking JavaScript will delay the event. Make your JavaScript asynchronous to optimize DOMContentLoaded.

Note: If DOMContentLoaded End is significantly higher than DOMContentLoaded Start, it means the page has listeners attached to this event triggering significant code execution and/or relying on network.

DOMContentLoaded Start immediately follows DOM Interactive. Between DOMInteractive and DCL Start, the only treatments are related to async scripts with a module type.

Collected from: Web Browser (API)

The DOMInteractive event is triggered when the DOM is loaded and the blocking scripts for the web page have been executed. At this stage, The scripts with the defer attribute aren't executed yet. Some style sheets may still be loading and block the page rendering.

Collected from: Web Browser API

Cumulative Layout Shift (CLS) measures page stability, by monitoring significant movements of elements on the page that may frustrate or mislead the user, during the entire page lifespan.

CLS is part of the Core Web Vitals. Google has been using Core Web Vitals as a search ranking signal since 2021.

Understanding Cumulative Layout Shift (CLS)
Cumulative Layout Shift measures the total sum of all individual layout shifts that occur during the entire lifespan of the page (including after the user has started to interact with the page), taking into account the size of the concerned area, and the distance of the shift. 

The CLS algorithm monitors every layout shift in the current context, thus excluding the content of iframes.

Layout shifts that happen 500 ms after an active user interaction (like a click, a keystroke, or the resize of the window) have no impact on the CLS. Hovering, scrolling, and update flinging are not considered active interactions.

Each of the other layout shifts are scored according to the total affected area and the distance covered by the moved elements. Cumulative Layout Shift is the sum of all the considered layout shifts scores.

According to Google guidelines, your web pages should have a CLS under 0.1 for at least 75% of your users (including both desktop and mobile traffic). 

Optimization example
To improve your Cumulative Layout Shift, make sure that the browser can allocate the right space for your images and iframes (including ads), even before it starts loading them, by defining their width and height, or aspect-ratio.

Collected from: Web Browser (API)

First Contentful Paint (FCP) measures the time it takes for content to start appearing on the page.

Understanding First Contentful Paint (FCP)
The definition of FCP is very close to that of Start Render. However, FCP is not computed through video analysis, but provided directly by the web browser (via the Paint Timing API).

Despite its definition, FCP can be triggered even when nothing is visible yet. For example when the text is available on the page, but invisible, because a custom font (web font) is still loading.

Collected from: Web Browser API 

First Input Delay (FID)  measures the time between a user’s first interaction and how long it takes for the interaction to be processed (interaction can be clicking or tapping a link or button). 

The Max Potential First Input Delay (Max Potential FID) is the worst value a First Input Delay could have. First Input Delay (FID) is the delay a user experiences when interacting with the page for the first time (example: delay to get a feedback from the page when clicking an element).

The FID depends on the business of the page (tasks preventing responsiveness) and when the user interacts. 

FID is collected from a given interaction of a real user, whereas the Max Potential FID can be computed without a user, the value is the delay that a user would face by interacting with the page when the page is least responsive (worst case scenario).

According to Google guidelines, your web pages should have a FID under 100ms for at least 75% of users (including both mobile and desktop traffic)

How it’s calculated
Max Potential First Input Delay is computed by finding the longest task after the First Contentful Paint (as we can assume a user would not attempt to interact with a page before any content is displayed).

Collected from: Web Browser (API)

Interaction to Next Paint (INP) is a metric that assesses the responsiveness of a web page. It measures how much time elapses between a user interaction, such as a click or key press, and the next time the user sees a visual update on the page. (Please note, that the visual update may be unrelated to the interaction).

Google announced that FID will be replaced by INP in march 2024. FID will no longer be used for ranking websites but INP will (along with LCP and CLS).

Differences between INP and FID 

• FID only measures the first interaction of the page whereas INP measures all page interactions.
  
  
• FID measures the delay between the user interaction and when the browser is actually able to begin processing.
  
  
• INP measures the details between the user interaction and when there is a subsequent UI change.

INP is much more representative of the potential visual delay of user’s experience when interacting with a page . FID focuses more on a technical delay in the beginning of the page view (first interaction only).

 

How does INP work?

INP aims to capture the duration between a user initiating an interaction and the subsequent rendering of the next frame, striving to achieve this for the most, if not all, user interactions.

INP value is the worst delay observed (for page views with more than 50 interactions, the outliers are excluded as INP will be the 98th centile value)

Interactions observed for INP are:

• Clicking with a mouse
• Tapping on a device with a touchscreen
• Pressing a key on either a physical or onscreen keyboard

Note: Mouse hover and scrolls are not considered in INP.

According to Google guidelines, your web pages should have an INP under 200ms for at least 75% of users (including both mobile and desktop traffic).

Collected from: Web Browser (API)

Largest Contentful Paint (LCP) measures loading performance and is part of the Core Web Vitals. Google has been using Core Web Vitals as a search ranking signal since 2021.

Understanding Largest Contentful Paint (LCP)

Largest Contentful Paint (LCP) measures the render time of the largest content element visible within the viewport (so before the users scroll).

LCP focuses on the speed of delivering the largest (excluding background images, and excluding content displayed outside the viewport e.g. below the fold) and consistent content (temporary content such as loaders or splash screens are ignored).

According to Google guidelines, your web pages should have a LCP under 2.5s, for at least 75% of your users (including both desktop and mobile traffic). 

Common causes of slow LCP include large design elements such as images, videos and third party scripts.

Optimization example
Optimize resources, use lazy load and trim JS to the essentials.

Collected from: Network traffic analysis

Time necessary for the web page to fully load (until Speed Analysis detects no further network activity).

Understanding Fully loaded

The fully load time is affected by all the requests related to the page loading, including the downloaded resources as the requests don't directly impact the user experience (retargeting, etc.).

Collected from: Web Browser API

The onload event is triggered when the Document Object Model (DOM) is loaded and the page's dependencies have been loaded and processed (images, CSS, JavaScript, etc. but not iframes).

It has a start and an end as listeners a (piece of JavaScript that is observing the page events to execute some code) can be attached at the event to trigger JavaScript execution when the event fires. The Load event fires when the initial HTML document has been completely loaded and parsed (without waiting for images, and iframes to finish loading).

External scripts with a "defer" and/or "async" attribute have also been executed at this stage. As well as stylesheets with the async attribute.

Collect from: Video analysis

Speed Index is an index which reflects the average display speed of the page components.

Understanding Speed Index
Speed Index transcribes the average display speed of the pixels included in the visible part of the tested web page (above the fold line). As a result, this indicator takes into account the display progressiveness of the different elements composing the page  (the lower the speed, the better). 

Google recommends a Speed Index of less than 1000s.

Optimization example
Avoid synchronous calls to external static resources, host locally important CSS & JS

Reduce JS payload or move them to footer

Collected from: Video analysis

Start Render marks the first display that is visible on the user’s screen (before this, the page remains blank). Start Render is determined from the video analysis of the web page’s loading.

Understanding Start Render
As the video analysis only concerns the visible part of the tested web page (above the foldline) please note that the first element to render isn't necessarily a significant one (it may be a minor element as a background color, a text or anything else).

Optimization examples
Make critical content available in the web page, without additional API calls.
Provide CSS needed for the content at the top of the page early, ideally inlined.

Collect from: Network traffic analysis

Time to First Byte (TTFB) indicates the time elapsed between the browser requesting a page and the reception of the first piece of data by the user (the HTML code of the related web page).

Understanding Time to First Byte
Time to First Byte is calculated from the web server response time added to the network latency, a DNS resolution and time to establish a TCP connection (and to establish a secure connection if your web page uses HTTPs).

Redirecting delays (not only 301 & 302 but also client-side JavaScript redirects) are included in the TTFB, as we are considering the first "valuable" byte related to the web page to be loaded.

Google recommends that your website TTFB should be 200 milliseconds (0.2s) or less. Slowness can be due to the the context (high-latency bandwidth), server status, length of the  certificate chain, or redirections, among other things)., 

Optimisation example
Investigate cache issues in the front of the backend.

Collected from: Network traffic analysis

Time to Last Byte measures the delay between the request sent by the browser and the reception of the last byte of the related response (the last piece of the HTML document). 

Understanding Time to Last Byte (TTLB)
TTLB directly follows the Time to First Byte. The Time to Last Byte counts an additional delay compared to the Time to First Byte: the time to download the data.

Note: The difference between the start time (TTFB) and the end time (TTLB) is usually minor, except when the HTML page has a high page weight (relative to the downstream bandwidth used for the speed test).

 

Collected from: GoogleChromeLabs polyfill (waiting for native browser implementation)

Time To Interactive (as proposed by Google) is a complex indicator; Time to Interactive is not the time when a page becomes interactive. Time to Interactive is when the page is durably interactive. For clarity, we have named this indicator Time To (Consistently) Interactive in Speed Analysis.

What makes a page durably interactive?

The TTI algorithm is based on both JavaScript and network activity analysis. It determines the moment from which a user interaction with the page can take place without any risk about the fluidity of the reaction (no "jank", no perceptible delay between the action and the related reaction).

A page is considered durably interactive when all the conditions are met for at least 5 whole seconds for an interaction to happen in a satisfactory way. If a long task occurs within this 5 second window, then we start waiting for 5 seconds again. If not, then the Time to (Consistently) Interactive if defined at the beginning of the “quiet” range of 5 seconds.

If there is no respite in the emergence of Long Tasks (meaning that the browser repeatedly performs tasks that slow it down), then the Time to (Consistently) Interactive cannot be computed, nor can the metrics that are based on it, such as the Total Blocking Time.

Collected from: Web Browser (Long Task API + simple algorithm)

Total Blocking Time (TBT) measures the total amount of time that a page is blocked from responding to user input (clicks, keyboard presses, etc) after the page has started to render content.

How it’s calculated
The Total Blocking Time calculation is based on the Long Tasks. A Long Task is a treatment that monopolizes the web browser for a while (>50 milliseconds) and blocks other critical tasks from being executed (e.g. reacting to user input).

The Total Blocking Time is a sum, calculated by adding the blocking portion of all Long Tasks between First Contentful Paint and Time to (Consistently) Interactive. The blocking portion of the long task is the duration in excess of 50 ms.

Example of a page loading with 3 long tasks:
[longtask 1: 55 ms] FCP [longtask 2: 110 ms] [longtask 3: 200 ms] TTI

• longtask 1 is ignored as occurring prior to the FCP
• blocking portion of long task 2 is 60 ms (110 - 50).
• blocking portion of long task 3 is 150 ms (200 - 50).
  
  The Total Blocking Time thus is 210 ms (60 + 150).

Why is the Total Blocking Time sometimes not computed?
As the Total Blocking Time is computed between the First Contentful Paint (FCP) and the Time to (Consistently) Interactive, both metrics need to be defined for the TBT to exist. When there are recurring and repeated Long Tasks, there is not really a time when the interface is consistently interactive, so there is no “end” to the range of time TBT should be computed into.

If you need to track your Long Tasks but the TBT cannot be calculated, you can use the "Sum of Long Tasks" metric instead.

Collected from: Video analysis

Visually Complete calculates how long it takes for all content above the fold to be visible.

Understanding Visually Complete

Visually Complete measures the time necessary for the zone above the fold line to be rendered in its final form. (This metric is measured from the video analysis of the web page's loading).

This final rendering state is captured at the end of our analysis, that means when Speed Analysis has detected the end of the traffic related to the page loading. By analyzing the video, Speed Analysis then identifies when this final rendering state has been completed.

This final state detection may be affected by animations (as carousels), as the rendering may change several times while the web page seems totally loaded. In order to stabilize your results, Speed Analysis offers an option to deactivate the animations.

Optimisation example
Put the background in the dominant color to load inline with your CSS. E.g. Put a black background for a picture where black is dominant in order to book the space during its load time