Awesome Pagespeed Metrics

⚡Metrics to help understand page speed and user experience
Alternatives To Awesome Pagespeed Metrics
Project NameStarsDownloadsRepos Using ThisPackages Using ThisMost Recent CommitTotal ReleasesLatest ReleaseOpen IssuesLicenseLanguage
Waka Readme Stats2,731
a month ago48mitPython
This GitHub action helps to add cool dev metrics to your github profile Readme
Awesome Influxdb737
2 years ago5
A curated list of awesome projects, libraries, tools, etc. related to InfluxDB
Awesome Pagespeed Metrics597
2 years ago5cc0-1.0
⚡Metrics to help understand page speed and user experience
Awesome Monitoring542
10 months ago2Go
Awesome Observability303
2 months agocc0-1.0
Awesome observability page
Awesome Proxmox Ve294
5 months agocc0-1.0
A collection of awesome Proxmox VE documentation, tools, api, blogs, site
Awesome Dropwizard80
5 years ago1Shell
Awesome Web Performance Budget69
2 years agocc0-1.0
⚡️Articles, Websites, Tools and Case Studies to implement performance budget to a website. (PR 's welcomed)
Awesome Metrics48
6 years ago
A curated list of awesome metrics platforms & frameworks, resources and other awesomeness.
Awesome Beam Monitoring47
4 years agocc-by-sa-4.0
Curated list of awesome BEAM monitoring libraries and resources
Alternatives To Awesome Pagespeed Metrics
Select To Compare

Alternative Project Comparisons

Awesome Page Speed Metrics Awesome

Metrics to help understand page speed and user experience.

If you're just getting started check out first.



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).
  • - A set of open source performance monitoring tools.
  • Calibre - Web performance monitoring SaaS.
  • - Web performance monitoring SaaS.
  • SpeedCurve - Web performance monitoring SaaS.
  • AwesomeTechStack - Website awesomeness monitoring Tool.

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).

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 Total Blocking Time (TBT) and First Input Delay (FID) you have to understand long tasks and how to avoid them as much as possible.

User-centric metrics

It's important to track metrics relevant to users and their experience. To measure the perceived performance we can choose metrics by framing them around a few key questions.

  • Docs - 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. LCP)
  • Is it usable - Can users interact with the page, or is it still busy loading? (e.g TBT)
  • Is it delightful/smooth? - Are the interactions smooth and natural, free of lag and jank?

Rendering metrics

First Contentful Paint (FCP)

The First Contentful Paint (FCP) metric measures the time from when the page starts loading to when any part of the page's content is rendered on the screen. For this metric, "content" refers to text, images (including background images), <svg> elements, or non-white <canvas> elements.

Largest Contentful Paint (LCP)

The Largest Contentful Paint (LCP) metric reports the render time of the largest content element visible within the viewport.

Cumulative Layout Shift (CLS)

A layout shift occurs any time a visible element changes its position from one frame to the next. CLS measures the sum total of all individual layout shift scores for every unexpected layout shift that occurs during the entire lifespan of the page.

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. (e.g. WPT measures this using a color histogram of the page based on video/screenshots recording).

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.

(Hero) Element Timing

Element Timing captures when specific elements are painted by the browser. Hero elements can be defined as the largest h1, img or background image (or custom ones using the Element Timing API)

Interactivity metrics

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). Sometimes called Consistently Interactice and not to be confused with First Interactive or First CPU Idle. (Warning: one of the most confusing and misunderstood metrics).

Total Blocking Time (TBT)

The Total Blocking Time (TBT) metric measures the total amount of time between First Contentful Paint (FCP) and Time to Interactive (TTI) where the main thread was blocked for long enough to prevent input responsiveness.

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.

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.

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

// 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.

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.





To the extent possible under law, Csaba Palfi has waived all copyright and related or neighboring rights to this work.

Popular Metrics Projects
Popular Awesome List Projects
Popular Operations Categories
Related Searches

Get A Weekly Email With Trending Projects For These Categories
No Spam. Unsubscribe easily at any time.
Awesome List
Web Performance