Web Performance Checklist

Chapter 1 of 8 · 4 checks · 3 min

Measure before you optimise

Know which metric is failing for real users before you change anything. These checks set up field data, lab tools and the right targets.

Show
  1. Read field data for your key pages before optimisingMust

    Why it matters and how to check

    Lab tests run on one device and one network. Real users have slower phones, worse connections and different behaviour, so a page that scores well in a lab can still fail Core Web Vitals in the field. Start with field data: the Chrome User Experience Report (CrUX), PageSpeed Insights and the Core Web Vitals report in Search Console all show LCP, INP and CLS from real Chrome users.

    To verify, open PageSpeed Insights for your home page and your two or three most visited templates, such as a product or article page. Note the field values for LCP, INP and CLS on mobile and on desktop separately. Write down which metric fails on which template; that decides which chapter of this checklist you work on first.

    Do

    • Check mobile and desktop separately, since they often fail different metrics

    Avoid

    • Optimising for a lab score alone without looking at field data
  2. Use the official thresholds at the 75th percentileMust

    Why it matters and how to check

    The good thresholds are LCP of 2.5 seconds or less, INP of 200 milliseconds or less and CLS of 0.1 or less. They are measured at the 75th percentile of page loads, split by mobile and desktop, and a page passes only if all three are good at that percentile. INP above 500 milliseconds is poor, and CLS above 0.25 is poor.

    Averages hide the slow sessions, which is why the 75th percentile is used. To verify, check that your dashboards and alerts use p75, not the mean or median, and that they use these exact numbers. If your team tracks a different target, write down why.

  3. Send Core Web Vitals from real users to your analyticsShould

    Why it matters and how to check

    CrUX only covers pages with enough Chrome traffic and lags behind your releases. Collecting the metrics yourself gives you every page, every browser that supports the APIs, and data the same day you ship. The web-vitals JavaScript library is the recommended way to measure all three metrics: import onLCP, onINP and onCLS and send each value to your endpoint, using navigator.sendBeacon() when available and fetch() as a fallback.

    To verify, open a page, interact with it, then switch tabs or close it. In the Network panel you should see a beacon request carrying the metric name and value, and the data should appear in your analytics within minutes.

    Example

    JavaScript
    import { onCLS, onINP, onLCP } from 'web-vitals';

function send(metric) {
  const body = JSON.stringify({ name: metric.name, value: metric.value, id: metric.id });
  (navigator.sendBeacon && navigator.sendBeacon('/vitals', body)) ||
    fetch('/vitals', { body, method: 'POST', keepalive: true });
}

onCLS(send);
onINP(send);
onLCP(send);
  4. Debug with DevTools and Lighthouse, knowing what each can measureShould

    Why it matters and how to check

    Lab tools are for finding causes, not for judging the result. Chrome DevTools can measure LCP, INP and CLS while you use the page. Lighthouse measures LCP and CLS but not INP, because it does not interact with the page; it reports Total Blocking Time (TBT) as a lab proxy for responsiveness.

    To verify, record a trace in the DevTools Performance panel with CPU throttling turned on while you load the page and click the main controls. Confirm you can see the LCP element, any layout shifts and the longest interaction in the trace. If your team only runs Lighthouse, add a manual interaction trace for INP to your release routine.

    Avoid

    • Treating a good Lighthouse score as proof of good INP