Frontend performance testing measures how quickly a web application loads, renders, and responds to user interaction. Google's Core Web Vitals — Largest Contentful Paint (LCP), Cumulative Layout Shift (CLS), and Interaction to Next Paint (INP) — are the most actionable metrics for this purpose because they are directly tied to user experience, used as ranking signals in Google Search, and measurable in both lab and field conditions. Including Core Web Vitals measurement in the QA pipeline catches performance regressions before they reach production users.

Understanding Core Web Vitals

Largest Contentful Paint measures how long it takes for the largest visible element — typically a hero image, a large text block, or a video poster — to finish rendering. Good LCP is under 2.5 seconds. Poor LCP is above 4 seconds. LCP regressions are most commonly caused by large unoptimised images, slow server response times (TTFB), or render-blocking resources that delay the main content from loading.

Cumulative Layout Shift measures unexpected layout movement — elements that jump around as the page loads because images without dimensions, late-injected ads, or dynamically inserted content above the fold push content downward. Good CLS is under 0.1. CLS regressions are introduced by removing explicit size attributes from images, changing font loading strategy, or injecting elements above existing content without reserving space. Interaction to Next Paint measures the responsiveness of the page to user input — clicks, taps, and keyboard interactions. Good INP is under 200ms. INP regressions are typically caused by long JavaScript tasks blocking the main thread during user interactions.

Lab vs. Field Measurement

Lab measurement runs performance tests in a controlled environment — a fixed device configuration, a fixed network speed, and a headless browser. Tools like Lighthouse, WebPageTest, and Playwright's performance APIs produce lab measurements. Lab measurement is reproducible and can be integrated directly into a CI pipeline as a regression gate. Field measurement collects real performance data from actual users via the Chrome User Experience Report (CrUX) or a Real User Monitoring (RUM) SDK. Field data reflects the actual distribution of devices, network conditions, and user behaviour patterns that lab tests cannot replicate. A complete performance testing strategy uses lab tests for regression detection in CI and field data for understanding production impact.

Integrating Core Web Vitals into a CI Pipeline

Lighthouse CI is the standard tool for integrating Core Web Vitals measurement into a CI pipeline. It runs Lighthouse against a deployed URL or a local server, produces JSON results, and can be configured with performance budgets that fail the CI step when a metric exceeds the defined threshold. Configure Lighthouse CI with a lighthouserc.json file that specifies the target URLs, the number of runs (3 runs and take the median removes outlier measurements), and the budget assertions.

Budget assertions for Core Web Vitals should match Google's thresholds: LCP under 2500ms, CLS under 0.1, and INP under 200ms. Add a budget for Total Blocking Time (TBT) as a lab proxy for INP, since INP is a field metric that cannot be fully measured in a headless environment. Set a TBT budget under 200ms. Run Lighthouse CI as a required step in the pull request pipeline so that performance regressions are caught before merge.

Using Playwright for Performance Assertions

Playwright's built-in tracing and performance APIs allow collecting Web Vitals during end-to-end test runs. Use the web-vitals JavaScript library injected into the page context to collect LCP, CLS, and INP values during a Playwright test. Assert that these values fall within acceptable ranges as part of the test assertion step. This approach integrates performance measurement into existing end-to-end tests rather than requiring a separate Lighthouse CI run for every test scenario.

For teams using Astaqc's performance testing services or building on test automation services, Playwright performance tracing provides detailed timings at the network request level — waterfall charts, long task markers, and layout shift event records — that complement the high-level Core Web Vitals metrics with root cause data.

Frequently Asked Questions

How do I prevent LCP regressions in CI without running a full browser?

Use Lighthouse CI in headless Chrome mode, which runs a full browser in a CI container without a display server. Lighthouse in headless mode produces LCP measurements that are representative of lab conditions. Run it against a staging deployment or a localhost server started in the CI job. The measurements will differ from field data but are consistent enough to catch regressions between runs.

What causes CLS regressions and how do I find them in code review?

The most common CLS regression patterns are: adding an img tag without explicit width and height attributes, adding a div or banner above the fold without a fixed height, changing the font-display strategy so that fonts swap after content is rendered, and injecting third-party widgets or ads above existing content. In code review, flag any markup change that introduces unsized media elements above the fold or inserts elements into the DOM after initial render.

Is it possible to test INP in a CI environment?

INP requires real user interaction to measure in field conditions. In lab conditions, Total Blocking Time (TBT) is the best proxy — it measures the total time the main thread is blocked by long tasks during page load. A TBT budget under 200ms correlates well with good INP in field data. Playwright can also simulate user interactions and measure the time to first response, providing a synthetic approximation of INP.

How often should we run performance tests in CI?

Run Lighthouse CI on every pull request targeting the main branch. Performance regressions are easiest to attribute and fix immediately after the commit that introduced them. Running performance tests only on a nightly schedule means a regression may be several commits deep before it is detected, increasing the investigation cost.