Tools like DebugBear and Lighthouse capture many different metrics to describe the speed of your website. This guide explains what these metrics mean and how to work with them.
Page load timings measure how much time has elapsed since the browser started navigating to a URL. Each timing describes a different progress event, from the initial rendering of the page to the page having fully loaded.
The lower these timings are, the faster the website loads for the user.
This timing indicates that the user started seeing something other than a blank page. This might just be a page background color or outline without useful content.
The First Contentful Paint occurs when text or an image has rendered.
Render-blocking stylesheets or web fonts can delay the First Contentful Paint.
This metric describes when the largest contentful element on the page is rendered. Images and elements with background images count as painted only once the image has loaded.
For example, in this filmstrip the Largest Contentful Paint only occurs after 7.5s, when the video preview image finishes loading.
A page is interactive when there are:
The Time to Interactive generally indicates when the page has fully loaded. Lighthouse ends its test when both the network and CPU have reached an idle state. On DebugBear you can control this behavior with Page Loaded Conditions.
User timings are custom timings created by your website by calling performance.mark.
Unlike other metrics, user timings can track the metrics that are most important to your users. General-purpose browser metrics can sometimes be misleading, for example when a page reaches an interactive state while the app is still loading data and just rendering a spinner.
Page weight measures how much data the browser has to download in order to display your page. It especially affects user experience when large amounts of data need to be loaded early on before the page starts to render.
Preloading additional code or resources after the page has rendered will increase page weight, but may not greatly hurt performance.
This screenshot shows a reduction in page weight after the site replaced PNG images with the more compact WebP format.
Another way to reduce image file size is to make sure they are loaded at an appropriate size. You don't want to load a 512x512 pixel image to display a 16x16 pixel icon.
Page weight is rated as follows on DebugBear.
|Rating||Max page size (Mobile)||Max page size (Desktop)|
These timings describe how much processing time was used on the browser main thread. While the page main-thread is busy the user can't interact with the page.
For example, this timeline shows a large amount of data being rendered. Even though the data has finished loading 5s after navigation, the UI doesn't update until 7s later.
Many website today run large amounts of code. This applies especially to client-side applications. Third-parties, like chat widgets or ads, also often require significant amounts of processing.
This describes time spent calculating where to display page elements and how much space they take up.
HTML parsing involves taking the HTML text and turning it into the DOM that can be rendered.
This involves drawing the boxes, texts, and image so that they can be displayed.
Lighthouse scores range from 0 to 100, with scores above than 90 shown in green.
The Lighthouse Performance score combines multiple performance metrics into one:
You can use the Lighthouse Score Calculator to get a better understanding of how your Performance score is determined.
This category includes audits that detect common accessibility issues. This includes:
Not all accessibility problems can be detected automatically, so you also need to test your website manually.
This score encompasses various good practices, for example
This category includes various audits for on-page Search Engine Optimization.
When DOM elements change position after being first rendered this increases the Cumulative Layout Shift.
For example, this filmstrip shows a video preview being rendered, but then an ad appears and pushes down the content.
The optimal Cumulative Layout Shift metric is 0, but anything below 0.1 is fine.
Core Web Vitals is a term Google uses for three key performance-related user experience metrics:
The Core Web Vitals can affect the search engine ranking of your website.
Note that this is not the full amount of memory used by the page.
The TTFB describes how long the server took to respond to the initial document request.
In Chrome DevTools and on DebugBear the TTFB does not include any roundtrips required to set up the TCP connection to the server.
Unless otherwise specified, the TTFB metric describes the initial document request. This is usually the most important metric, as the browser can't render anything or make additional requests until it has received an HTML response from the server.
However, every request has a Time to First Byte. In this example, a 5s TTFB for an Ajax request is the most important factor affecting page performance.
This tracks how many log entries are shown in the console when loading your page.
Warnings often indicate that a browser feature is deprecated.
HTML validation errors might be incorrectly closed tags or misspelled CSS properties.
Not all validation errors are important, and sometimes the validation incorrectly flags newer browser features as invalid.