What they're testing
Whether you treat performance as something to defend continuously, or as a one-off project.
The short answer~30 seconds
Set budgets and fail CI when they're exceeded: bundle size per entry point, query count for the main endpoints, and Core Web Vitals measured on a production-like environment. The crux is that the threshold must BLOCK the merge — a dashboard nobody is blocked by merely documents the decline.
The long answer
A budget only works when the number comes from a requirement rather than from the status quo. "Keep it where it is today" locks in whatever is already bad; "LCP under 2.5s on 4G on a mid-range device" gives you a target you can state to people who don't write code. The second survives prioritisation arguments; the first doesn't.
Measuring in CI has a trap: CI machines vary, so timing directly produces flaky results and the team learns to ignore them. The STABLE metrics are the ones worth blocking on: byte size, query count, request count — deterministic and machine-independent. Measure LCP and INP on real user data and track the trend, rather than blocking PRs with them.
The hardest part isn't technical: when the budget blocks an important PR at 5pm on a Friday, someone will propose raising it. So the process needs an explicit escape hatch — exceeding the budget is allowed with a ticket recording the reason and a deadline. Without one, the budget gets removed entirely the first time it's inconvenient.
What they'll ask next
?How do you measure real-user Core Web Vitals?
The web-vitals library reporting to your own endpoint, or CrUX if the site has enough traffic. What matters is segmenting — device, country, page type — because a healthy median can completely hide the category page being terrible on low-end Android.
These lose points
- A dashboard with no blocking threshold. It records the page getting slower, and records it very accurately.