GitHub

Testing, Monitoring & Debugging

Synthetic Testing: Lab Tools for Controlled Measurement

Synthetic (lab) testing runs automated performance audits under controlled, repeatable conditions — fixed device profile, network throttling, and geographic location. Lab results are essential for debugging specific issues and verifying optimizations, but don’t reflect real-user variability.

Lighthouse

Lighthouse (Google, open-source) is the foundational performance auditing tool. It scores pages across Performance, Accessibility, Best Practices, and SEO on a 0–100 scale, with specific metrics (LCP, INP, CLS, FCP, TTFB, Speed Index) and actionable recommendations. As of mid-2025, Lighthouse is transitioning to Insights audits (Lighthouse 12.7+/13) — a new audit format shared between Lighthouse and Chrome DevTools’ Performance panel, providing more visual, trace-annotated analysis. PageSpeed Insights is also being updated to show Insights by default.

Run Lighthouse in multiple ways: Chrome DevTools (Lighthouse tab) for quick local audits, PageSpeed Insights (pagespeed.web.dev) for combined lab + CrUX field data, Lighthouse CLI (npx lighthouse <url>) for scripted/automated runs, and Lighthouse CI for CI/CD pipeline integration. Always run at least three times in incognito and average results — scores fluctuate 5–10 points between runs due to variability.

WebPageTest

WebPageTest (webpagetest.org, open-source) provides the deepest technical analysis available. Its waterfall diagrams, filmstrip views, connection view charts, and video recordings expose exactly where time is spent during page load — down to individual resource timing. Key capabilities: testing from 40+ global locations, real devices (not just emulation), custom network throttling profiles, multi-step transaction testing (e.g., add-to-cart → checkout flow), Lighthouse integration, and scripted test sequences.

The waterfall view is the single most useful performance debugging tool. It shows every resource request as a horizontal bar, revealing: which resources block rendering, how long DNS/TLS/download take, whether resources are loaded in parallel or sequentially, and the impact of third-party scripts. If you learn to read a WebPageTest waterfall fluently, you can diagnose most performance problems visually.

Other Synthetic Tools

GTmetrix — combines Lighthouse scoring with its own waterfall and video analysis; simpler than WebPageTest for quick checks. DebugBear — Lighthouse-based monitoring with change tracking, third-party analysis, and resource hint validation. Unlighthouse — scans entire sites with Lighthouse, generating per-page scores for site-wide audits.

Resources:

Chrome DevTools Performance Panel: The Developer’s Microscope

Chrome DevTools’ Performance panel is the most powerful client-side debugging tool available. It records a detailed trace of everything the browser does — parsing, style calculation, layout, paint, compositing, JavaScript execution, garbage collection, and network activity — all on a unified timeline.

Key workflows:

LCP debugging: Record a page load, find the LCP marker in the Timings track, and inspect the LCP by Phase insight (TTFB, resource load delay, resource load time, element render delay). The Performance panel now shares Insights audits with Lighthouse, providing annotated recommendations directly on the trace.

INP debugging: The Interactions track shows every user interaction with its processing duration. Long interactions (>200ms) are highlighted. Expand an interaction to see the event handlers, their execution time, and whether the delay is in input delay (main thread busy), processing time (handler execution), or presentation delay (rendering after handler).

Long Animation Frames (LoAF): Chrome 123+ exposes Long Animation Frames in the Performance panel, showing exactly which scripts caused frames longer than 50ms. This is more precise than the older Long Tasks API, as it attributes the delay to specific scripts and functions.

Layout shift debugging: The Experience track shows every layout shift with a visualization of which elements moved and by how much. Click a shift to see the culprit elements in the DOM.

Coverage tab (Sources panel → Coverage): Shows which bytes of CSS and JavaScript were actually used on the page. Red = unused, blue = used. This is invaluable for identifying CSS frameworks with 90% unused rules or JavaScript bundles with dead code.

Network panel insights: Filter by third-party to see external script impact, check the size vs transferred size to verify compression is working, and look for render-blocking resources (CSS/JS that appear before first paint in the waterfall).

Resources:

Real User Monitoring (RUM): Measuring What Actually Happens

Synthetic tests tell you what could happen. Real User Monitoring tells you what does happen — across real devices, real networks, real geographic locations, and real user behavior. RUM captures Core Web Vitals (LCP, INP, CLS) and other metrics from actual page loads, providing the P75 data that Google uses for Search ranking.

The web-vitals Library

Google’s web-vitals library (npm) is the standard for collecting Core Web Vitals in production. It’s tiny (~1.5KB gzipped), measures LCP, INP, CLS, FCP, and TTFB with attribution data (what caused the value), and matches exactly what CrUX reports:

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

onLCP(metric => sendToAnalytics('LCP', metric));
onINP(metric => sendToAnalytics('INP', metric));
onCLS(metric => sendToAnalytics('CLS', metric));

The attribution build (web-vitals/attribution) adds diagnostic data: for LCP, it tells you the element, the resource URL, and the time breakdown (TTFB, resource load delay, render delay). For INP, it identifies the interaction type, the target element, and the longest script. For CLS, it lists the shifted elements and their shift sources.

CrUX: Chrome User Experience Report

CrUX is Google’s public dataset of real-user performance metrics from opted-in Chrome users. It powers the “field data” in PageSpeed Insights and the Core Web Vitals report in Google Search Console. CrUX data is aggregated at the origin level (your whole domain) and URL level (individual pages with enough traffic). It reports P75 values — meaning 75% of page loads achieve this score or better.

CrUX is the source of truth for Google’s ranking signal. If your CrUX data shows good Core Web Vitals (LCP ≤ 2.5s, INP ≤ 200ms, CLS ≤ 0.1), your pages receive the ranking boost. Lab scores don’t directly affect rankings.

Access CrUX data via: PageSpeed Insights (field data section), Google Search Console (Core Web Vitals report), CrUX Dashboard (Looker Studio template), CrUX API (programmatic access), BigQuery (raw dataset for advanced analysis).

RUM Tool Landscape 2026

The RUM ecosystem spans from simple analytics to full observability platforms:

Lightweight/focused: web-vitals library (DIY), Vercel Analytics (built into Vercel), Cloudflare Web Analytics (privacy-first, no cookies), PostHog (open-source product analytics with web vitals).

Dedicated web performance: DebugBear (Lighthouse-based synthetic + RUM, excellent for tracking changes over time), SpeedCurve (synthetic + RUM, competitive benchmarking, Lux RUM), Calibre (CI/CD integration, performance budgets), Treo (CrUX-powered insights).

Full observability: Sentry (error monitoring + Performance tracing + web vitals), Datadog RUM (APM + RUM + session replay), New Relic Browser (full-stack APM), Raygun (real user monitoring + crash reporting).

Self-hosted/open-source: SigNoz (OpenTelemetry-native, self-hosted), BasicRUM (lightweight self-hosted RUM collector).

Resources:

CI/CD Integration: Catching Regressions Before Production

Performance testing belongs in your deployment pipeline, not as an afterthought. A single unoptimized image or unguarded third-party script added in a PR can regress LCP by hundreds of milliseconds — and without automated checks, you won’t know until users complain or CrUX data shifts weeks later.

Lighthouse CI

Lighthouse CI (LHCI) runs Lighthouse in CI/CD and can assert that scores and metrics meet thresholds. It stores historical results for trend tracking and can comment on PRs with performance diffs:

# .lighthouserc.json
{
  "ci": {
    "assert": {
      "assertions": {
        "categories:performance": ["error", { "minScore": 0.9 }],
        "largest-contentful-paint": ["error", { "maxNumericValue": 2500 }],
        "interactive": ["error", { "maxNumericValue": 3500 }],
        "cumulative-layout-shift": ["error", { "maxNumericValue": 0.1 }]
      }
    }
  }
}

Run with lhci autorun in your CI pipeline (GitHub Actions, GitLab CI, CircleCI). Configure it to fail the build when critical thresholds are exceeded.

Bundle Size Budgets

Size-limit (by Andrey Sitnik) checks JavaScript bundle sizes in CI and fails if they exceed a budget. It calculates the real cost — download time on slow 3G — not just bytes:

// package.json
{
  "size-limit": [
    { "path": "dist/index.js", "limit": "50 kB" },
    { "path": "dist/vendor.js", "limit": "150 kB" }
  ]
}

Bundlewatch provides similar functionality with GitHub PR status checks, showing the size diff for every bundle in a visual report.

Performance Budgets in Build Tools

Vite and webpack both support performance budgets natively. Webpack’s performance.hints: 'error' fails the build when assets exceed configurable thresholds. For Vite, use rollup-plugin-size or vite-plugin-bundle-analyzer with CI assertions.

The key principle: make performance a blocking check, not an advisory warning. If LCP regresses past your budget, the PR doesn’t merge. This is the only reliable way to maintain performance over time in a team environment.

Resources:

Continuous Monitoring: Tracking Performance Over Time

Point-in-time audits catch issues; continuous monitoring catches trends. The most insidious performance problems are gradual regressions — each PR adds a little JavaScript, each new feature adds a third-party script, and over months your LCP drifts from 1.8s to 3.5s without anyone noticing.

Set up synthetic monitoring (scheduled Lighthouse/WebPageTest runs on your key pages, daily or hourly) alongside RUM (continuous real-user data). Configure alerts for:

  • LCP P75 exceeding 2.5s (or your budget)
  • INP P75 exceeding 200ms
  • CLS P75 exceeding 0.1
  • Total JavaScript size exceeding your budget
  • Third-party script count or impact increasing
  • TTFB regression (indicates server/CDN issues)

DebugBear, SpeedCurve, and Calibre all provide trend dashboards that show metric changes over time with annotations for deployments, making it easy to correlate a performance regression with the specific deploy that caused it.

Google Search Console’s Core Web Vitals report provides a monthly view of your CrUX pass/fail rates broken down by URL group. A shift from “Good” to “Needs Improvement” here directly affects your search ranking — this is the dashboard your SEO team should be watching.

Resources: