← Back to Course Index

Module 2.7 — Measurement Workflow

Phase: Phase 2 — Performance Engineering (Core Web Vitals)

Fixing Core Web Vitals without a disciplined measurement workflow is like adjusting a car engine with the hood closed. You need to know exactly what you're measuring, why lab numbers and field numbers disagree, and which tool to use at each stage of diagnosis, implementation, and verification. This module builds that end-to-end workflow from first measurement through confirmed improvement.

1. The Two Realities: Lab Data vs Field Data

Before touching any tool, you must internalize this distinction — it governs every decision in performance work.

1.1 Field Data (Real-User Monitoring / RUM)

Field data is collected from real users on real devices, real networks, in real conditions. It reflects what people actually experience. The canonical public source is the Chrome User Experience Report (CrUX), a dataset Google builds from opted-in Chrome browser telemetry.

Field data is the ground truth for Google's ranking signal. If PageSpeed Insights shows a green Lighthouse score in the lab but your CrUX field data is red, your users are experiencing a poor page — and Google knows it. Fix field data, not lab scores.

1.2 Lab Data (Synthetic Testing)

Lab data is collected in a controlled, simulated environment — fixed device, fixed network, no other browser tabs, no real user variability. The primary lab tool is Lighthouse, which runs inside Chrome DevTools, as a CLI, or via PageSpeed Insights.

1.3 Why They Disagree — and Which to Trust

Decision rule: Use field data to understand the problem and measure success. Use lab data to diagnose the root cause and iterate quickly without waiting days for CrUX to update.

2. The Measurement Toolkit

2.1 Chrome DevTools — Performance Panel

The Performance panel is your surgical instrument. It records a full trace of everything that happens in the browser during page load or interaction.

How to use it effectively:

What to look for in the trace:

2.2 Lighthouse

Lighthouse gives you a structured report with scored audits, not just a raw trace. It is best used for:

Key Lighthouse audits for CWV work:

Run Lighthouse in an incognito window to avoid extension interference. Run it three times and average the scores — single runs have natural variance.

2.3 WebPageTest

WebPageTest (webpagetest.org) is the most powerful free synthetic testing tool available. Unlike Lighthouse (which runs on your local machine), WebPageTest runs from real infrastructure in real global locations against a real server — so TTFB, CDN behavior, and geographic differences are all real.

Key capabilities:

WebPageTest is the gold standard for diagnosing LCP root causes because it shows you exactly when the LCP resource was discovered, when it started downloading, and when it finished rendering.

2.4 The web-vitals JavaScript Library

This is Google's official library for measuring Core Web Vitals in real users' browsers. It is the foundation of any production RUM setup. 

// Install
npm install web-vitals

// Measure all Core Web Vitals and send to your analytics endpoint
import { onLCP, onINP, onCLS } from 'web-vitals';

function sendToAnalytics(metric) {
  const body = JSON.stringify({
    name: metric.name,       // 'LCP', 'INP', 'CLS'
    value: metric.value,     // the metric value
    rating: metric.rating,   // 'good', 'needs-improvement', 'poor'
    id: metric.id,           // unique ID for deduplication
    navigationType: metric.navigationType,
  });

  // Use navigator.sendBeacon for reliability (fires even if tab closes)
  navigator.sendBeacon('/analytics', body);
}

onLCP(sendToAnalytics);
onINP(sendToAnalytics);
onCLS(sendToAnalytics);

Send this data to Google Analytics 4, BigQuery, or any custom backend. This gives you field data segmented by your traffic — by device type, geography, page template, user cohort — unlike CrUX which is an aggregate. This is critical for finding that, say, your LCP is good for desktop users but catastrophic for mobile users in Southeast Asia.

Important notes on web-vitals metric delivery:

3. The End-to-End Measurement Workflow

This is the repeatable process you follow every time you work on a CWV problem. Each stage has a specific purpose — do not skip stages.

Stage 1: Identify the Problem in Field Data

  1. Open Google Search Console → Core Web Vitals. Note which URL groups are "Poor" or "Needs Improvement" and which metric is failing.
  2. Open PageSpeed Insights for a representative URL from the failing group. Look at the field data section (CrUX). Confirm which metric(s) are failing and at what values.
  3. Check whether the problem is at the URL level (one specific page) or the origin level (a systemic pattern across your whole site).
  4. Prioritize by traffic and business value — fix the highest-traffic, highest-revenue URL groups first.

Stage 2: Reproduce and Diagnose in the Lab

  1. Load the failing URL in Chrome in an incognito window.
  2. Run Lighthouse from DevTools (throttled: Slow 4G, 4× CPU). Read the LCP phase breakdown, TBT value, and CLS contributors in the audit list.
  3. Run the DevTools Performance panel with throttling. Find the LCP candidate, the CLS-causing layout shifts, and any long tasks blocking interaction.
  4. Run WebPageTest from a location matching your primary user geography. Study the waterfall for late-discovered LCP resources, render-blocking scripts, and third-party load order.
  5. Note the exact root cause for each failing metric. Write it down explicitly:
    • Example LCP: "Hero image is discovered late because it has loading='lazy' and is not in the initial HTML — fetching doesn't start until the browser renders the page."
    • Example CLS: "Ad slot at the top of the article has no reserved height — when the ad loads at 3s it shifts all content down by 210px."
    • Example INP: "Clicking 'Add to Cart' triggers a 650ms long task: a third-party analytics event fires synchronously in the click handler."

Stage 3: Implement the Fix

  1. Implement only one fix at a time where possible, so you can isolate which change moved which metric.
  2. Document what you changed: the file, the specific code modification, the expected impact on which metric.
  3. If you cannot deploy to production immediately, use a staging environment or WebPageTest's "Experiments" feature to simulate the fix.

Stage 4: Verify the Fix in the Lab

  1. Re-run Lighthouse on the same throttling settings. Compare numbers directly with your Stage 2 baseline.
  2. Re-run WebPageTest. Compare the waterfall — does the LCP resource now start earlier? Do layout shifts disappear from the filmstrip?
  3. Re-run the DevTools Performance panel. Are the long tasks shorter? Is the LCP timing improved?
  4. Produce a before/after comparison table. You need specific numbers, not vague impressions: 
    Metric     Before Fix    After Fix     Target
LCP        4.2s          2.1s          < 2.5s
TBT        680ms         120ms         < 200ms
CLS        0.24          0.04          < 0.1

Stage 5: Confirm Improvement in Field Data

  1. Deploy to production.
  2. Wait 28 days for a full CrUX collection cycle. (CrUX is a 28-day rolling window; you'll start seeing change after ~7 days but the full picture takes 28 days.)
  3. Re-check PageSpeed Insights field data for the URL. Compare the field LCP, INP, and CLS values before and after.
  4. Re-check Google Search Console Core Web Vitals to confirm the URL group has moved status.
  5. Check your RUM data (if you have web-vitals implemented) segmented by device and geography — confirm the improvement is real for your actual users, not just the CrUX aggregate.

4. Building a Before/After Evidence Package

A documented before/after comparison is your proof of work. It protects you when stakeholders ask "did this actually help?", and it is the standard of advanced technical SEO — not anecdote, but measurement.

Your evidence package should contain:

5. Continuous Monitoring — Don't Measure Once

Performance degrades silently. A new marketing script, a CMS update, a new image uploaded without compression, a third-party A/B testing tool — any of these can undo months of CWV work overnight. Set up monitoring so you find out immediately, not weeks later from a GSC warning.

5.1 Lighthouse CI in Your Deploy Pipeline

Lighthouse CI runs Lighthouse automatically on every pull request or deploy and fails the build if performance budgets are exceeded. 

# .lighthouserc.js (minimal example)
module.exports = {
  ci: {
    collect: {
      url: ['https://staging.example.com/', 'https://staging.example.com/products/'],
      numberOfRuns: 3,
    },
    assert: {
      assertions: {
        'largest-contentful-paint': ['error', { maxNumericValue: 2500 }],
        'total-blocking-time':      ['error', { maxNumericValue: 200 }],
        'cumulative-layout-shift':  ['error', { maxNumericValue: 0.1 }],
      },
    },
    upload: {
      target: 'temporary-public-storage', // or your LHCI server
    },
  },
};

This ensures regressions are caught before they reach production and real users.

5.2 Scheduled Synthetic Monitoring

5.3 Always-On RUM with web-vitals

With the web-vitals library deployed, you have a continuous stream of real-user metric data. Set up alerts in your analytics platform to notify you when the 75th percentile of LCP, INP, or CLS crosses the "Good" threshold for any meaningful traffic segment.

6. Common Measurement Mistakes to Avoid

Summary: The Measurement Workflow at a Glance

Milestone Task

Select a live URL that has field data in PageSpeed Insights (use your own site, a client site, or a publicly accessible site with enough traffic for CrUX data).

  1. Record the field data baseline: LCP, INP (or FID if INP is not yet available), and CLS values at the 75th percentile for mobile.
  2. Run Lighthouse (throttled), a DevTools Performance trace, and a WebPageTest run. Write down the precise root cause of whichever metric is weakest.
  3. Implement or mock a fix. Re-run all three lab tools and produce a before/after table with specific numbers.
  4. Write a one-page diagnosis document: what was failing, the root cause, what you changed, the lab evidence of improvement, and the plan to confirm in field data after 28 days.

You have completed this module when you can walk through all five stages of the measurement workflow — from identifying a field data problem to producing a documented, quantified, before/after evidence package — without referring to these notes.