Browser checks & Core Web Vitals
Render each page in a real browser to catch what static analysis can’t.
Why a real browser
Build and deep checks read your source. Browser checks load each page in headless Chromium — on mobile and desktop — and observe the rendered, executed result. That surfaces problems only a browser sees:
| Check | Catches |
|---|---|
| Core Web Vitals | Slow LCP, layout shift (CLS), long blocking time — fail a budget like LCP < 2.5s |
| No console errors | A script that throws on load and leaves the page blank |
| Layout & overflow | Horizontal scroll on mobile; jumpy layout |
| Broken rendered resources | Images, fonts, and scripts that 404 or fail to decode |
| Accessibility (axe) | Computed contrast/ARIA/role violations |
| Visual regression | A page that looks different from the previous run |
| Rendered SEO | Title/meta as the crawler sees them after JavaScript runs |
Setting a Web Vitals budget
Add the Core Web Vitals check and set budgets (ms, except CLS):
{ "lcp": 2500, "cls": 0.1, "tbt": 200 }The run fails if any page exceeds a budget on either device.
Visual regression
The first run captures a baseline screenshot of each page. Every later run diffs against the previous run and fails when a page changes more than your threshold. If a change is intentional, the new screenshot simply becomes the next baseline — no manual approval step.
Running them
Browser checks run in the same flow as everything else — upload a build ZIP (we serve it locally so you can test before deploying) or give a list of live URLs. Because they’re heavier, runs finish in the background: poll the run or use a webhook. Browser runs visit up to 25 pages each.
Core Web Vitals here are lab measurements taken during a fresh page load (no simulated throttling). Treat them as a fast regression signal, not a substitute for field data from real users.