Performance budgets: keeping your web app fast as it grows
What a performance budget is, which limits make sense and how to enforce it in your CI pipeline so your web application stays fast with every new feature.
In short: A performance budget is a hard limit on metrics such as load time, JavaScript size or Core Web Vitals that a web application must not exceed. It stops an app from getting a little slower with every new feature, tracking script and library until nobody can ignore it. It only works once an automated check in your CI pipeline flags or blocks violations.
Why web applications get slow
Hardly any application gets slow on purpose. It happens gradually: a date library here, a chat widget there, a bigger hero image, one more analytics script. Each change looks harmless on its own. Added up, the page loads noticeably slower a year later and nobody can say when it happened.
Load time has direct consequences. Google uses Core Web Vitals as a page experience signal in ranking, and slow pages lose visitors before they see the first content. A performance budget turns speed into a requirement with a clear limit, just like accessibility or security.
What belongs in the budget
User-centric metrics
Core Web Vitals are the best starting point because they measure what users experience. Google's thresholds for a "good" rating are: Largest Contentful Paint (LCP) up to 2.5 seconds, Interaction to Next Paint (INP) up to 200 milliseconds and Cumulative Layout Shift (CLS) up to 0.1. INP replaced First Input Delay in March 2024 and rates responsiveness across the whole visit.
Quantity-based metrics
Load times vary by device and network. So add quantities that measure consistently: compressed JavaScript per page, total page weight, number of requests, image and font sizes. Keep the JavaScript budget and INP and load time usually stay in line too.
Setting the numbers
Measure where you are now and set the budget just above that or at a realistic target. A budget that is broken from day one gets ignored. Also measure on a throttled connection with an average mid-range phone, not on a developer laptop over office Wi-Fi.
Enforcing the budget in the pipeline
Check bundle size
Tools such as size-limit check on every pull request whether the JavaScript bundle exceeds a set size. The comment on the pull request shows exactly which change added how much, so the new 70-kilobyte library gets noticed before it is merged.
Lighthouse CI
Lighthouse CI measures key pages on every build and compares them against your limits. If a limit is exceeded, the build fails or raises a warning. Our post on CI/CD pipelines for web applications shows how such checks fit into a pipeline.
Watch real user data
Lab measurements show trends; real users show the truth. The web-vitals library lets you capture Core Web Vitals from real visits and analyze them. Google also provides field data through the Chrome UX Report and Search Console. Our article on monitoring and observability covers how this data feeds into your monitoring.
What to do when the budget breaks
A broken budget is a prompt for a decision. The usual levers are well known: code splitting so each page loads only its own code, replacing heavy libraries with lighter ones or loading them on demand, serving images in modern formats like AVIF or WebP at the right sizes, limiting fonts to the weights you need, and auditing and deferring third-party scripts.
Architecture often helps too. Server rendering and React Server Components move work from the browser to the server and cut client-side JavaScript. Our post on server-side vs. client-side rendering explains when each approach fits.
Sometimes a feature is worth the extra kilobytes. In that case the budget is adjusted deliberately, with a reason, rather than quietly exceeded.
Frequently asked questions (FAQ)
When is a performance budget worth setting up?
Ideally from the start of a project, when it is easiest to keep. For existing applications, set the budget at the current level and lower it step by step. At the very least, that stops things getting worse.
Which metric matters most?
For most web applications, JavaScript size is the strongest lever because it affects both load time and responsiveness. For search visibility and how users perceive you, Core Web Vitals from real user data count most.
Does a performance budget slow down development?
Hardly, if it is automated. The check runs in the pipeline and only speaks up when a limit is crossed. Over time it saves effort, because after-the-fact performance projects are far more work than ongoing discipline.
Who decides when a feature blows the budget?
Settle that in advance, usually between product ownership and technical lead. What matters is that the exception is decided consciously and documented.
Conclusion
A performance budget turns speed into a checkable rule that does not depend on any one developer's instinct. With a few metrics, automated checks and real user data, your application stays fast for years. If you want to build a fast web application or make a slow one fast again, talk to us about web development.
Related posts
- React vs. Vue vs. Svelte: A Frontend Framework Comparison
React, Vue or Svelte for your next web project? A sober comparison of concepts, ecosystem, performance, hiring and long-term maintainability.
- Why we chose Next.js as our default web framework
Why we build web apps with Next.js by default: rendering options, SEO, TypeScript, self-hosting in Germany, and when we deliberately choose otherwise.
- Testing React Applications: Unit, Integration and E2E Tests
How to test React applications sensibly: which tests pay off, which tools fit, and how a test strategy catches bugs early instead of slowing the team down.
- Clean code in TypeScript: principles for maintainable projects
Practical clean code rules for TypeScript: strict types, clear names, small functions and validated boundaries, with examples and the mistakes to avoid.