Awesome Web Performance Metrics

Lab data (Synthetic measurements)
Field data (Real User Monitoring - RUM)
- Chrome User Experience Report (CrUX)
- Your web analytics
User-centric metrics
Is it happening?
Is it useful/meaningful?
Is it usable?
Is it delightful/smooth?
- Frame rate
Resource byte weights
- JavaScript weight (incl third-parties)
- HTML weight
Page lifecycle (TODO)
Network timing (TODO)
Concepts (TODO)
- Critical rendering path
- The Main Thread and Long tasks

Lab data (Synthetic measurements)

Make a request to your page with a tool and evaluate performance.

Google Lighthouse (LH)

Lighthouse is a tool built on Google Chrome to audit web pages. You can run it from Chrome DevTools, a Chrome Extension or from the command line (even with headless Chrome).

Docs - Lighthouse
Tools built on LH:

WebpageTest (WPT)

WebpageTest is an open source project to test web page performance. It supports multiple browsers, testing on real devices and has a free hosted version at webpagetest.org

Docs - WebpageTest (WPT)
Some tools were originally built on WPT (and now support LH as well):
- SpeedCurve

Sitespeed.io

Sitespeed.io is a set of Open Source tools to monitor and measure the performance of your web site.

Sitespeed.io

Field data (Real User Monitoring - RUM)

Collect performance data from real users visiting your page.

Chrome User Experience Report (CrUX)

The Chrome User Experience Report provides user experience metrics for how real-world Chrome users experience popular destinations on the web. Available as a Google BigQuery dataset.

Docs - CrUX

Your web analytics

Web analytics tracking can also be used to track performance
Blogpost - Performance tracking Google Analytics (GA)

User-centric metrics

Blogpost - User-centric Performance Metrics

Use the questions below to organize/prioritize your metrics from the user's perspective.

Is it happening?
Is it useful/meaningful?
Is it usable?
Is it delightful/smooth?

Is it happening?

Did the navigation start successfully?
Has the server responded?

Start render

The Start Render is the time from the start of the initial navigation until the first non-white content is painted to the browser display.

Lab: WPT
Field: N/A but similar to First Paint (FP)
Docs - Start Render - WPT

First Paint (FP)

First Paint reports the time when the browser first rendered after navigation. This excludes the default background paint, but includes non-default background paint. This is the first key moment developers care about in page load – when the browser has started to render the page.

Lab: LightHouse JSON report includes it but not the HTML report, also similar to Start render in WPT
Field: Chrome 60+, Opera 47+, CrUX
Spec - FP - W3C

First Contentful Paint (FCP) ⭐

First Contentful Paint marks the time at which the first text or image is painted (including background images), non-white canvas or SVG. This includes text with pending webfonts. This is the first time users could start consuming page content.

Lab: Lighthouse
Field: Chrome 60+, Opera 47+, CrUX
Docs - FCP - LH
Spec - FCP - W3C

Is it useful/meaningful?

Has enough content rendered that users can engage with it?

Visually Complete

The Visually Complete is the time from the start of the initial navigation until the visible (above the fold) part of your page is no longer changing. (Measured using a color histogram based on video/screenshots recording).

Lab: WPT
Field: N/A
Docs - Visually Complete - WPT

First Meaningful Paint (FMP)

First Meaningful Paint measures when the primary content of a page is visible. It's essentially the paint after which the biggest above-the-fold layout change has happened, and web fonts have loaded.

Lab: Lighthouse
Field: N/A
Docs - FMP - LH
Spec - First Meaningful Paint

Speed Index ⭐

Speed Index shows how quickly the contents of a page are visibly populated (lower numbers are better). This is done by frequently measuring visual completeness during loading. The quicker the page is more visually complete the lower the value.

Lab: Lighthouse, WPT (but slightly different spec)
Field: N/A
Docs - Speed Index - LH
Docs - Speed Index - WPT
Talk - Speed Perception and Lighthouse

Hero Element Timing ⭐

Hero Element Timing captures when specific elements are painted by the browser (e.g. your h1 or your hero image, etc).

Is it usable?

Can users interact with the page, or is it still busy loading?

User Timing marks

The User Timing API allows the developer to create application specific timestamps that are part of the browser's performance timeline. You can create a user timing mark to measure when your JS has loaded (e.g. for a specific component).

Lab: LH, WPT
Field: IE 10+, Safari 11+ (and Chrome, Firefox of course)
Spec - User Timing

componentDidMount() {
    performance.mark("yourcomponent.usable");
}

First Interactive

See First CPU Idle. WPT still calls it First Interactive but Google/Lighthouse renamed to First CPU Idle to avoid confusing this with Time to Interactive (TTI)

First CPU Idle ⭐

First CPU Idle marks the first time at which the page's main thread is quiet enough to handle input.

Lab: Lighthouse, WPT (but it's called First interactive in WPT)
Docs - First Interactive - WPT
Docs - First CPU Idle - Lighthouse

Consistently Interactive

See Time to Interactive (TTI). WPT still refers to TTI as Consistently Interactive but it's only available for Chrome and not surfaced on the UI (only in raw results XML/JSON).

Time to Interactive (TTI) ⭐

Time to interactive is the time it takes for the page to become fully interactive. Not to confuse with First Interactive or First CPU Idle.

Lab: Lighthouse, WPT (it's called Consistently interactive in WPT, also only in Chrome even in WPT and not shown on the UI at all)
Field: Chrome 58+ with polyfill
Polyfill - TTI
Spec - TTI - LH

Estimated Input Latency

Estimated Input Latency is an estimate of how long your app takes to respond to user input, in milliseconds, during the busiest 5s window of page load. If your latency is higher than 50 ms, users may perceive your app as laggy.

Lab: LH
Field: N/A
Docs - Estimated Input Latency - LH

First Input Delay (FID) ⭐

First Input Delay (FID) measures the time from when a user first interacts with your site to the time when the browser is actually able to respond to that interaction. An interaction can be when users click a link, tap on a button, or use a custom, JavaScript-powered control.

Lab: N/A (as it requires the user to interact with the page)
Field: IE9+ (and Safari, Chrome, Firefox) (with polyfill - 0.4KB)
Docs - FID
Polyfill - FID

Is it delightful/smooth?

Are the interactions smooth and natural, free of lag and jank?

Frame rate

The frame rate is the frequency at which the browser can display frames. A frame represents the amount of work a browser does in one event loop iteration such as processing DOM events, resizing, scrolling, rendering, CSS animations, etc. A frame rate of 60 fps (frames per second) is a common target for a good responsive user experience. This means the browser should process a frame in about 16.7 ms.

Lab: N/A
Field: No browser implements the Frame Timing API yet
Docs - Frame Timing API
Docs - Chrome Devtools - FPS
Docs - Firefox Developer Tools - Frame rate

Resource byte weights

You can measure the byte weight of your assets with a number of tools. These can be tracked Lab only as the numbers are usually the same in the Field (but be mindful of device type or geographical location specific pages).

JavaScript weight (incl third-parties)

Measure and keep track of the compressed (and uncompressed) byte weight of your own JS bundles and all thirdparty JS loaded on your page. Third parties can be analytics, marketing tags, customer support chat widget, etc.

Loading lots of JavaScript is usually the root cause of high TTI or FID values.

HTML weight

Your initial HTML document is alway number one on your critical rendering path. Be sure not excessively embed resources like SVGs or large amount JS or CSS. (Some critical CSS or JS is ok, the key here is how much).

Is your HTML bloated? A flamegraph can tell you why

Page lifecycle (TODO)

DOMContentLoaded

Docs - DOMContentLoaded

window.load

Docs - load or more specifically window.load

Load abandonment

Network timing (TODO)

Blogpost - Navigation and Resource Timing

Navigation Timing

Spec - Navigation Timing

Resource Timing

Spec - Resource Timing

Server Timing

Surface any backend server timing metrics (e.g. database latency, etc.) in the developer tools in the user's browser or in the PerformanceServerTiming interface.

Docs - Server Timing

Concepts (TODO)

Critical rendering path

Critical rendering path

The Main Thread and Long tasks

theJC/awesome-web-performance-metrics

ErrorLooks like something went wrong!

About

Resources

Uh oh!

Stars

Watchers

Forks

Releases

Packages 0

Error
Looks like something went wrong!

Packages