Awesome web performance metrics
Awesome Page Speed Metrics ¶
Metrics to help understand page speed and user experience.
Concepts¶
Lab Data (Synthetic Measurements)¶
Make a request to your page with a tool and evaluate performance. Be sure to make it realistic (e.g. by throttling network and CPU) and reduce noise (e.g. by running multiple times).
- Lighthouse - 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).
- Google PageSpeed Insights - Free and hosted Lighthouse reporting (and more) by Google.
- WebpageTest - Free and hosted web performance testing (also an open source project).
- Sitespeed.io - A set of open source performance monitoring tools.
- Calibre - Web performance monitoring SaaS.
- treo.sh - Web performance monitoring SaaS.
- SpeedCurve - Web performance monitoring SaaS.
Field Data (Real User Monitoring - RUM)¶
Collect performance data from real users visiting your page. Be mindful of the actual overhead, as it runs in your user's browser and watch out for browser support of more recent metrics (e.g. compared to your user-base).
- Performance tracking with Google Analytics (GA)
- Chrome User Experience Report (CrUX)
- Load abandonment - Track
visibilitychange
to account for survivorship bias. - SpeedCurve LUX - Real User Monitoring SaaS.
- Akamai mPulse - Real User Monitoring SaaS.
- Sematext Experience - Real User Monitoring SaaS.
Critical rendering path¶
The critical rendering path is everything that happens between receiving network bytes and rendering something on the screen. To optimize any rendering metrics like First Contentful Paint (FCP) or Speed Index you have to understand how the critical rendering path works.
Long tasks¶
The browser Main Thread that handles user input is also the one executing JavaScript (among many other things). Blocking the Main Thread for too long can make your page unresponsive.
A user perceives any visual change within 100ms as instant. Any task blocking the Main Thread by taking longer than 50ms is considered a long task (as it might make the browser unresponsive to user input).
To optimize interactivity metrics like Time to Interactive (TTI) and First Input Delay (FID) you have to understand long tasks and how to avoid them as much as possible.
User-centric metrics¶
Users are typically looking for visual feedback and reassurance. To measure this perceived performance (at various stages of loading) we can choose metrics that directly answer the questions below.
- User-centric Performance Metrics
- Is it happening? - Did the navigation start successfully? Has the server responded? (e.g FCP)
- Is it useful/meaningful? - Has enough content rendered that users can engage with it? (e.g. FMP)
- Is it usable - Can users interact with the page, or is it still busy loading? (e.g TTI)
- Is it delightful/smooth? - Are the interactions smooth and natural, free of lag and jank?
Apdex score¶
Application Performance Index, or Apdex, is a measurement of your users’ level of satisfaction based on the response time of request(s) when interacting with your website or application.
Rendering metrics¶
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 - Lighthouse
- Spec - FCP - W3C
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 - Lighthouse
- 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 - Lighthouse
- Docs - Speed Index - WPT
- Talk - Speed Perception and Lighthouse
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
- 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
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
Hero Element Timing¶
Hero Element Timing captures when specific elements are painted by the browser (e.g. your h1
or your hero image, etc).
- Lab: WPT
- Field: N/A but see unmantained polyfill below
- W3C GitHub issue - Element Timing API
- Spec - Hero Element Timing
- Blogpost - Hero Element Timing - SpeedCurve
- Polyfill - Hero Element Timing - see also the announcement here
- Blogpost - User Timing for Element Timing - SpeedCurve
- Blogpost - Last Painted Hero coming to WebpageTest
- Docs - Element Timing Explainer
- Docs - Hero Text Element Timestamps
Cumulative Layout Shift (CLS)¶
A metric derived from the Layout Instability API. The cumulative layout shift (CLS) score is determined by calculating the sum of all unexpected (not within 0.5s of a user interaction) layout shift scores from page load until the page's lifecycle state changes to hidden.
- Lab: N/A
- Field: CrUX + Chrome 73+ (origin trial)
- Spec - Layout Instability
- Chrome - Origin Trial for Layout Stability API
-
Lab: N/A
- Field: N/A (Chrome: in development)
- Spec - Largest Contentful Paint
- Docs - Largest Contentful Paint
- Blogpost - Largest Contentful Paint
Interactivity metrics¶
First CPU Idle¶
First CPU Idle marks the first time at which the page's main thread is quiet enough to handle user input.
- Lab: Lighthouse, WPT (but it's called First interactive in WPT)
- Field: N/A
- Docs - First Interactive - WPT
- Docs - First CPU Idle - Lighthouse
Time to Interactive (TTI)¶
Time to interactive is the time it takes for the page to become fully interactive (as in Main Thread quiet for 5s). Not to confuse with First Interactive or First CPU Idle. (Warning: one of the most confusing and misunderstood metrics).
- Field: Not recommended as users interacting with your page can skew field measurements of TTI
- Polyfill - TTI
- Spec - TTI - Lighthouse
- Blogpost - TTI
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
First Interactive¶
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).
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: Lighthouse
- Field: N/A
- Docs - Estimated Input Latency - Lighthouse
Max Potential First Input Delay¶
The maximum potential First Input Delay that your users could experience. Basically equals to the duration of the longest long task on the browser Main Thread.
- Lab: Lighthouse
- Field: N/A
Total Blocking Time (TBT)¶
- Lab: Lighthouse
- Field: N/A
- Total Blocking Time
Network metrics¶
Network timing field data can uncover a non-optimized TLS setup, slow DNS lookups or server side processing and issues with CDN configuration. See also a separate section about measuring transferred bytes.
DNS latency¶
- Lab: DNS performance testing tools
- Field: IE9+, Safari 9+
// Measuring DNS lookup time
var pageNav = performance.getEntriesByType("navigation")[0];
var dnsTime = pageNav.domainLookupEnd - pageNav.domainLookupStart;
TCP and SSL/TLS latency¶
- Lab: See Qualys SSL Labs for an audit
- Field: IE9+, Safari 9+
// Quantifying total connection time
var pageNav = performance.getEntriesByType("navigation")[0];
var connectionTime = pageNav.connectEnd - pageNav.connectStart;
var tlsTime = 0; // <-- Assume 0 by default
// Did any TLS stuff happen?
if (pageNav.secureConnectionStart > 0) {
// Awesome! Calculate it!
tlsTime = pageNav.connectEnd - pageNav.secureConnectionStart;
}
Time to First Byte (TTFB)¶
- Lab: most server load testing tools report this
- Field: IE9+, Safari 9+
var ttfb = pageNav.responseStart - pageNav.requestStart;
Transferred bytes¶
You can measure the byte weight of your assets with a number of tools. You would normally track these Lab only as the numbers are usually the same in the Field (but be mindful of device type or geographical location specific pages).
Measuring own (and third-party) JavaScript bytes is crucial as JavaScript is the main cause of high TTI or FID values.
- Lab: Lighthouse (budgets), Sitespeed.io, custom tools
- Field: N/A - but numbers usually the same as in Lab
- Sitespeed.io PageXray
- Lighthouse Performance Budgets
- Can You Afford It?: Real-world Web Performance Budgets
- Which third party scripts are most excessive
Other metrics¶
Google PageSpeed Insights score¶
User Timing¶
The User Timing API allows the developer to create application specific timestamps that are part of the browser's performance timeline. e.g. you can create a user timing mark to measure when your JS has loaded for a specific component on the page.
- Lab: Lighthouse, WPT
- Field: IE 10+, Safari 11+ (and Chrome, Firefox of course)
- Spec - User 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.
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: Chrome and FF Devtools
- Field: No browser implements the Frame Timing API yet but you can roll your own fps meter using
requestAnimationFrame
- Docs - Frame Timing API
- Docs - Chrome Devtools - FPS
window.load¶
License¶
To the extent possible under law, Csaba Palfi has waived all copyright and related or neighboring rights to this work.