Skip to main content
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:
Assert on individual Core Web Vitals:
Save the audit report to team storage:
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.
  • playAudit requires a Playwright page object with an active navigation. Call it after waitForLoadState to ensure the page has settled.
  • Lighthouse runs in a simulated environment — results will vary slightly between runs. Avoid very tight thresholds (e.g. ≤ 100ms for 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.

Full sample test

Last modified on May 20, 2026