- Lab data (Synthetic measurements)
- Field data (Real User Monitoring - RUM)
- User-centric metrics
- Is it happening?
- Is it useful/meaningful?
- Is it usable?
- Is it delightful/smooth?
- Resource byte weights
- Page lifecycle (TODO)
- Network timing (TODO)
- Concepts (TODO)
Make a request to your page with a tool and evaluate performance.
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 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):
Sitespeed.io is a set of Open Source tools to monitor and measure the performance of your web site.
Collect performance data from real users visiting your page.
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.
- Web analytics tracking can also be used to track performance
- Blogpost - Performance tracking Google Analytics (GA)
Blogpost - User-centric Performance Metrics
Use the questions below to organize/prioritize your metrics from the user's perspective.
- Did the navigation start successfully?
- Has the server responded?
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 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 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
- Has enough content rendered that users can engage with it?
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 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 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 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
- Can users interact with the page, or is it still busy loading?
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");
}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 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
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 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 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) 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
- Are the interactions smooth and natural, free of lag and jank?
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
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).
- Lab: LH (custom audit), Sitespeed.io, custom tools
- Field: N/A - but numbers usually the same as in Lab
- Sitespeed.io PageXray
- page-weight cli - splits first-party and third-party
- byte-weight-breakdown - LH custom audit
- manually look at Chrome DevTools Network Tab
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.
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).
- Docs -
loador more specificallywindow.load
Blogpost - Navigation and Resource 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.