This recipe covers spot-checking web performance with Lighthouse. For operationalized performance monitoring — scheduled runs, trend tracking, aggregated reports, and alerting — talk to your QA Wolf team about full-service performance testing.
Examples
Run a Lighthouse audit and assert on the performance score:The double navigation is intentional. Lighthouse measures the second load so that cookie banner dismissal steps don’t skew the metrics.
When to use
- Your team wants a quick sanity check that a page meets minimum performance thresholds before or after a deploy.
- You want to catch regressions in Core Web Vitals — LCP, CLS, or FCP — introduced by new code.
- You need a lightweight performance gate in CI without a full monitoring setup.
- You want to verify that a specific page (checkout, landing page, dashboard) hasn’t degraded after a significant change.
Performance thresholds
For more on what each metric means and why it matters, see Web performance metrics, explained.Notes
- The sample test below runs in Google Chrome only, using port
9222, which is the Chrome DevTools Protocol port. Lighthouse connects to an already-running Chrome instance via CDP rather than launching its own. playAuditrequires a Playwrightpageobject with an active navigation. Call it afterwaitForLoadStateto ensure the page has settled.- Lighthouse runs in a simulated environment — results will vary slightly between runs. Avoid very tight thresholds (e.g.
≤ 100msfor TBT) that will produce flaky results. - Thresholds are declared as named constants at the top of the file so they are easy to find and adjust per environment.
onlyCategories: ["performance"]scopes the audit to performance only. Lighthouse can also score accessibility and SEO.