explaingit

googlechrome/web-vitals

8,495JavaScriptAudience · developerComplexity · 2/5LicenseSetup · easy

TLDR

web-vitals is a tiny JavaScript library from Google that measures your website's real-world loading speed and responsiveness using the exact signals Google uses for search rankings.

Mindmap

mindmap
  root((web-vitals))
    Metrics
      LCP loading speed
      INP interactivity
      CLS layout shift
      FCP first paint
      TTFB server speed
    Usage
      npm install
      Callback function
      CDN script tag
    Output
      Google Analytics
      Custom analytics
      Console logging
    Attribution build
      Pinpoint elements
      Diagnose root cause
Click or tap to explore — scroll the page freely

Code map

Detail Auto

An interactive map of this repo's files and how they connect — its source is parsed live in your browser. Click Visualize to build it.

filefunction / class

Things people build with this

USE CASE 1

Track Largest Contentful Paint and Cumulative Layout Shift on your live site to match exactly what Google measures for search rankings.

USE CASE 2

Send real-user Core Web Vitals data to Google Analytics or a custom analytics endpoint with just a few lines of code.

USE CASE 3

Use the attribution build to pinpoint exactly which element or interaction is causing a poor LCP, INP, or CLS score.

Tech stack

JavaScript

Getting it running

Difficulty · easy Time to first run · 5min
Apache 2.0, use freely including in commercial products, with attribution.

In plain English

web-vitals is a small JavaScript library from Google that measures how a website performs for the actual people visiting it. It tracks the specific signals Google uses to evaluate page experience in search rankings and developer tools, so the numbers you see in your own monitoring match what Google sees. The library covers three Core Web Vitals that Google considers the most important: Largest Contentful Paint, which measures how long it takes for the main content of the page to appear, Interaction to Next Paint, which measures how quickly the page responds when a user clicks or taps something, and Cumulative Layout Shift, which measures how much the page layout unexpectedly moves around while loading. It also captures two additional signals: First Contentful Paint and Time to First Byte, which relate to how quickly the server starts delivering content. You can install it from npm and import it into your JavaScript code with a couple of lines. For each metric, you provide a callback function that runs whenever a measurement is ready. From there, you decide what to do with the data: log it for debugging, send it to your own analytics system, or forward it to Google Analytics or Google Tag Manager. The library is intentionally small, roughly 2 kilobytes in its compressed form, so it adds very little overhead to your page. A second build called the attribution build is available for teams who want to understand not just what their score is but why it is low. It attaches extra diagnostic information to each metric report pointing to the specific element or interaction that caused the poor result. The library can be loaded via npm or directly from a CDN using a script tag. It is designed to be loaded after other content rather than early in the page, since it uses a browser feature that gives it access to performance data even when loaded late. The full README is longer than what was shown.

Copy-paste prompts

Prompt 1
Add the web-vitals library to my React app and send LCP, INP, and CLS scores to Google Analytics 4 on each page view.
Prompt 2
Using the web-vitals attribution build, log which specific DOM element is causing my Cumulative Layout Shift to the browser console.
Prompt 3
Set up web-vitals in a plain HTML page using a script tag from a CDN and log all five Core Web Vitals to the console.
Prompt 4
Write a Next.js reportWebVitals function that sends each metric to my custom /api/vitals analytics endpoint as a POST request.
Prompt 5
How do I measure Time to First Byte with web-vitals and alert when it exceeds 800ms in my monitoring setup?
Open on GitHub → Explain another repo

← googlechrome on gitmyhub — every repo by this author, as a profile.

Verify against the repo before relying on details.