Web Vitals
Popular metrics measuring many of the various aspects of performance relevant to users:
- First Contentful Paint (FCP): measures the time from when the page starts loading to when any part of the page's content is rendered on the screen. (lab, field)
- Largest Contentful Paint (LCP): measures the time from when the page starts loading to when the largest text block or image element is rendered on the screen. (lab, field)
- First Input Delay (FID): measures the time from when a user first interacts with your site (when they click a link, tap a button, or use a custom, JavaScript-powered control) to the time when the browser is actually able to respond to that interaction. (field)
- Interaction to Next Paint (INP): measures the latency of every tap, click, or keyboard interaction made with the page, andâbased on the number of interactionsâselects the worst interaction latency of the page (or close to the highest) as a single, representative value to describe a page's overall responsiveness. (lab, field)
- Time to Interactive (TTI): measures the time from when the page starts loading to when it's visually rendered, its initial scripts (if any) have loaded, and it's capable of reliably responding to user input quickly. (lab)
- Total Blocking Time (TBT): measures the total amount of time between FCP and TTI where the main thread was blocked for long enough to prevent input responsiveness. (lab)
- Cumulative Layout Shift (CLS): measures the cumulative score of all unexpected layout shifts that occur between when the page starts loading and when its lifecycle state changes to hidden. (lab, field)
- Time to First Byte (TTFB): measures the time it takes for the network to respond to a user request with the first byte of a resource. (lab, field)
Each Core Web Vitals metric has associated thresholds, which categorize performance as either "good", "needs improvement", or "poor":
| Good | Poor | Percentile | |
|---|---|---|---|
| Largest Contentful Paint | â¤2500ms | >4000ms | 75 |
| First Input Delay | â¤100ms | >300ms | 75 |
| Cumulative Layout Shift | â¤0.1 | >0.25 | 75 |
Web Performance
There are several other types of metrics that are relevant to how users perceive performance.
- Perceived load speed: how quickly a page can load and render all of its visual elements to the screen.
- Load responsiveness: how quickly a page can load and execute any required JavaScript code in order for components to respond quickly to user interaction
- Runtime responsiveness: after page load, how quickly can the page respond to user interaction.
- Visual stability: do elements on the page shift in ways that users don't expect and potentially interfere with their interactions?
- Smoothness: do transitions and animations render at a consistent frame rate and flow fluidly from one state to the next?
To address such cases, the Web Performance Working Group has also standardized lower-level APIs that can be useful for implementing your own custom metrics:
- Performance Observer API
- User Timing API
- Long Tasks API
- Element Timing API
- Event Timing API
- Resource Timing API
- Navigation Timing API
- Server Timing API
Read More: https://web.dev/articles/custom-metrics