Performance Budgets: Setting Them Before You Design

What a performance budget actually is

A performance budget is a set of hard numeric limits — total JavaScript payload, total image weight, number of web font weights loaded, maximum LCP time — agreed on before design work begins, not measured after the fact and apologized for. Without one, "make it fast" is a value everyone agrees with in the abstract and nobody enforces in the specific decision that trades it away.

Setting budgets for the parts that matter most

• JavaScript payload — a reasonable target for a marketing page is well under 200KB of initial JS (gzipped); every animation library or embedded widget considered for the design gets weighed against this number before it's approved.
• Image weight — a total page image budget (e.g., under 500KB above the fold) forces a conversation about hero image size and format (AVIF/WebP) at design time, not as a post-launch optimization pass.
• Font loading — every additional font weight is a real cost; a budget of two weights per typeface (rather than the five a designer might default to) is a small constraint that measurably helps LCP.

Enforcing the budget in the build pipeline, not just in a document

A budget that only exists as a written guideline gets quietly exceeded the first time a genuinely nice design element doesn't fit inside it. Enforcing the numbers in CI — a bundle-size check that fails a build exceeding the JS budget, for instance — is what makes the budget a real constraint rather than an aspiration everyone privately ignores under deadline pressure.

What happens without one

Every individual addition to a page — one more animation, one more font weight, one more embedded widget — looks small in isolation. Without a budget forcing an explicit trade-off conversation, those additions compound silently until the page fails Core Web Vitals and a rebuild-scale optimization project is needed to fix what dozens of small, unexamined decisions caused. See the companion checklist on Core Web Vitals for Next.js for what those consequences actually look like in the metrics.

The right time to set this

Before the first mockup, not after the first Lighthouse report. A budget set at the design stage changes what gets proposed in the first place; a budget discovered at the audit stage only tells you what to apologize for.

Related reading