Web Performance Metrics
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.
Load time milestones
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.
First Paint (FP)
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.
First Contentful Paint (FCP)
The First Contentful Paint occurs when text or an image has rendered.
Render-blocking stylesheets or web fonts can delay the First Contentful Paint.
Largest Contentful Paint (LCP)
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.
Time to Interactive (TTI)
A page is interactive when there are:
- No more than two GET requests are in progress (network quiet)
- No more main-thread CPU tasks taking longer than 50ms (CPU quiet)
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
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
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.
Page weight is usually dominated by images and JavaScript code.
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) |
|---|---|---|
| Green | 1.5MB | 2MB |
| Yellow | 3MB | 4MB |
| Red | >3MB | >4MB |
Responsiveness
These metrics try to measure how long it took for the browser to respond to user interaction (in a field environment), or how long it would take for the browser to respond (in a lab environment without user input).
First Input Delay
First Input Delay (FID) measures how soon after the user input the browser starts processing the event. It only considers the first user interaction on the page.
Interaction to Next Paint
Interaction to Next Paint (IFP) measures how long it takes from the user input to the next UI update.
Total Blocking Time
Total Blocking Time (TBT) is a lab metric that measures for how much time the main thread is "blocked", meaning there's an ongoing CPU task that takes more than 50 milliseconds. If the user were to interact with the page during those times the FID and INP scores could be high.
CPU activity
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.
JavaScript (JS)
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.
JavaScript timings can be further categorized into:
- Parsing
- Compilation
- Execution
Style/Layout
This describes time spent calculating where to display page elements and how much space they take up.
HTML Parsing
HTML parsing involves taking the HTML text and turning it into the DOM that can be rendered.
Painting
This involves drawing the boxes, texts, and image so that they can be displayed.
Garbage Collection
Browsers automatically manage memory for you. When a JavaScript object or DOM node is no longer need it will be removed, freeing up memory. Identifying these objects and deleting them is called Garbage Collection.
Lighthouse scores
Lighthouse scores range from 0 to 100, with scores above than 90 shown in green.
Performance
The Lighthouse Performance score combines multiple performance metrics into one:
- First Contentful Paint
- Speed Index
- Largest Contentful Paint
- Time to Interactive
- Total Blocking Time
- Cumulative Layout Shift
You can use the Lighthouse Score Calculator to get a better understanding of how your Performance score is determined.
Accessibility
This category includes audits that detect common accessibility issues. This includes:
- not using image alt tags
- not having sufficient color contrast
- not providing labels for form elements
Not all accessibility problems can be detected automatically, so you also need to test your website manually.
Best Practices
This score encompasses various good practices, for example
- using HTTPS
- not requesting unnecessary permissions (like for notifications or geolocation)
- using the correct doctype to avoid quirks mode
- not having browser errors in the console
SEO
This category includes various audits for on-page Search Engine Optimization.
- invalid robots.txt
- no title element
- no meta description
- poor mobile UX (small font sizes or links/buttons)
- and more
Other metrics
Cumulative Layout Shift (CLS)
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
Core Web Vitals is a term Google uses for three key performance-related user experience metrics:
- Largest Contentful Paint
- First Input Delay (Total Blocking Time in a lab environment)
- Cumulative Layout Shift
The Core Web Vitals can affect the search engine ranking of your website.
JavaScript Memory Consumption
This metric captures how much memory is used by the JavaScript Heap.
Note that this is not the full amount of memory used by the page.
Time to First Byte (TTFB)
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.
Console output
This tracks how many log entries are shown in the console when loading your page.
Errors indicate that some JavaScript code is broken, or that a file couldn't be loaded.
Warnings often indicate that a browser feature is deprecated.
HTML validation
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.
