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.

  1. Load timings
  2. Page weight
  3. CPU timings
  4. Lighthouse scores
  5. Other metrics

Load timings

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.

Page rendering filmstrip showing First Paint, First Contentful Paint, and Largest 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.

Page filmstrip showing a late Largest Contentful Paint

Time to Interactive (TTI)

A page is interactive when there are:

  1. No more than two GET requests are in progress (network quiet)
  2. 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.

Charts showing custom user timings

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.

Chart tracking page speed over time

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.

CPU timings

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.

CPU timeline showing main-thread work blocking rendering

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:

You can use the Lighthouse Score Calculator to get a better understanding of how your Performance score is determined.

Lighthouse score calculator

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.

Filmstrip showing layout shift in UI

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.

JavaScript memory consumption chart

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.

TTFB chart for different requests

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.

Charts and details for console errors, warnings, logs, and other output

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.

Chart showing HTML validation errors over time


Still need help? Contact matt@debugbear.com for support.
DebugBear is a website monitoring tool built for front-end teams. Track performance metrics and Lighthouse scores in CI and production. Learn more.
© 2020 DebugBear Ltd