Frontend Performance Budgets: A Pattern That Sticks

What you actually need to know

• Budget for bundle size, LCP, CLS, INP, and total page weight.
• Enforce in CI. PRs fail when budget is exceeded.
• Track both lab and field metrics.
• Document the exception process.
• Dynamic import heavy code to keep the initial bundle within budget.

Metric

Recommended threshold

Initial JS bundle compressed

Under 200 KB

LCP

Under 2.5 seconds

CLS

Under 0.1

INP

Under 200 ms

FID

Under 100 ms

Total page weight

Under 1 MB

Time to Interactive

Under 4 seconds

Number of requests

Under 50 per page

The core argument

Frontend performance budgets are one of those engineering disciplines that quietly prevent years of drift. Without a budget, the bundle grows a few kilobytes at a time, one PR after another, and no single addition ever looks large enough to question. A year later the bundle has doubled, the site is noticeably slower, and nobody can point to the moment it happened, because there wasn't one.

The fix is a documented threshold enforced in CI: the bundle cannot grow past a line, the Core Web Vitals cannot regress past a line, and the build fails the moment either one is crossed. The team has to address the issue before merging. That is what actually stops the drift, not good intentions.

The setup itself is small. Lighthouse CI for the Core Web Vitals, a bundle size check for the bundle, both running on every PR. For a team starting from nothing, the configuration is roughly a sprint, and the ongoing maintenance after that is light. The payoff is performance that simply does not drift.

The real discipline is in how exceptions are handled. Some changes genuinely need more bundle. The exception process makes that cost visible instead of hidden: the reviewer approves with a stated justification, the exception gets logged, and the team revisits the budget if exceptions start piling up. The goal is not zero exceptions. It is making every one of them a decision instead of an accident.

Teams that adopt this stop having quarterly performance crises, because the budget catches regressions the moment they are introduced rather than a year later. Teams that skip it tend to rediscover the problem every six months, when the cumulative drift finally produces a site nobody wants to use.

The patterns that work

Pattern

Detail

Lighthouse CI on every PR

Core Web Vitals enforced

Size limit check

Bundle size enforced

Per route budgets

Different routes have different thresholds

Field metric tracking

RUM data informs reality

Exception process

Documented and visible

Quarterly review

Adjust budgets as needed

Dynamic imports

Heavy code not on initial load

Performance regression alerts

Catch issues fast

How much does this cost

The cost of the setup is roughly a sprint of work. The ongoing cost is the handful of PRs that need exception conversations or rework to fit the budget. The savings is the performance crises that do not happen.

Features the budget system must have

• Documented budgets per metric per route.
• CI enforcement that fails the build.
• Field metric tracking via RUM.
• An exception process that is visible.
• A quarterly budget review.
• Dynamic import discipline.
• Performance regression alerts.
• A retrospective on misses.

Expert opinion

Performance budgets enforced in CI are the cheapest way to hold frontend performance over years. The setup is small. The enforcement removes the politics from individual PR conversations. The reviewer is not arguing with the engineer about bundle size. The CI is. The team has to address the issue or get an exception. The discipline is mechanical and effective.

Yashveer Singh, founder of Yashveer Labs

How this played out on a real project

A client SaaS had let frontend performance drift over two years. The LCP had grown from 1.8 seconds to 4.1 seconds. The bundle had grown from 200 KB to 540 KB. The team was facing a quarterly performance project to recover.

We set up performance budgets in CI. Lighthouse CI for the Core Web Vitals. Size limit for the bundle. We brought the metrics back to budget with a focused project. The budget then held the metrics across the next year of feature work.

The team did not have to spend another quarter on performance recovery. The PRs that would have caused regressions were rejected by CI. The engineers either fit the new code into the budget or got an exception. The slow drift stopped.

For more on the related work, see the real numbers behind a fast web app in 2026 and bundle size the quiet killer of mobile web performance.

Common mistakes teams make

1. No budget. Performance drifts.
2. Budget without CI enforcement.
3. No field metric tracking. Lab only.
4. No exception process. Either too rigid or invisibly bypassed.
5. Bundle on first load includes everything.
6. No per route budgets.
7. No quarterly review. Budgets get stale.
8. Treating performance as a quarterly project rather than a continuous discipline.

A two week setup plan

1. Week one. Pick the metrics and thresholds. Document the budget.
2. Week two. Set up Lighthouse CI and size limit. Wire to PR gating. Train the team.

For more on the related work, read the real numbers behind a fast web app in 2026 and bundle size the quiet killer of mobile web performance. On the broader performance side, the performance regression that hides in CI is the natural next read.

FAQ

Frequently asked

• What metrics should I budget for?
• What are reasonable thresholds?
• How do I enforce in CI?
• What about field versus lab metrics?
• How do I handle exceptions?
• What about new features that need more bundle?
• What is the worst budget mistake?

Author

The person behind Yashveer Labs

Yashveer Singh, founder of Yashveer Labs. I build full stack systems for clients who care that the thing actually works two years later, not just on launch day. The arc I am on points at machine learning, AI engineering, and cybersecurity. Everything I write here comes from the codebase, not from a content brief. That is the difference and it shows.

Start the conversation See the work DM on Instagram