Nextjs Performance Budget Guard

A Next.js build summary or route list goes in. Out comes (1) a per-route budget table — First Load JS and page size per route, plus Core Web Vitals target thresholds — (2) a finding for every route over budget with its likely causes, and (3) an ordered fix plan. This is a gate you set up before deploy, not a repair job after users complain and not a general audit: budgets are decided first, then every build is measured against them.

Ask these five questions if the answers are not already in the request. Do not set budgets before you have at least questions 1–3.

1. App type: marketing site, SaaS / product app, internal tool, e-commerce, docs / content site, or a mix?
2. Route mix: which routes are marketing, which are app / dashboard, which are docs / content? List the top routes if the full table is long.
3. Strictness: startup-lean (small team, public users on mid-range phones, every kilobyte argued for) or enterprise (desktop-first, authenticated, heavier client code is a real product need) — or balanced in between?
4. CWV priorities: which vital hurts most right now — LCP (content appears slowly), INP (page answers slowly), or CLS (page jumps around)? Rank the top one; name a second if close.
5. CI usage: should this gate run in CI on every pull request and fail the build, or is it a manual pre-release check for now?

How the answers change the work (this is not decoration):