Most performance problems are not caused by a single bad decision. They accumulate: a date library here, an animation package there, a charting dependency someone added for one screen that now loads on every route. By the time anyone measures, the fix is a month of work.
A budget stops the accumulation. Pick a number for the JavaScript shipped on your most important route, check it on every pull request, and fail the build when it is exceeded.
Pick a number you can defend
For a marketing site, we aim for under 120 KB of compressed JavaScript on first load. For an authenticated application shell, 200 KB is a more realistic starting point. The exact figure matters less than having one, because the useful behaviour is the conversation that happens when a change breaches it.
The conversation is the feature
When a build fails on budget, someone has to decide: is this dependency worth 40 KB on every page load? Sometimes the answer is obviously yes. Often it turns out the library was solving a problem that forty lines of code also solve, and nobody had a reason to check until the build made them.
That decision is nearly impossible to make retroactively. Removing a dependency that has spread through a codebase for eighteen months is a refactor. Declining to add it is a five-minute discussion.
Server components move the line
Rendering on the server changes what counts against the budget. Content, layout and data formatting can happen before the response is sent, leaving only genuinely interactive parts to hydrate on the client.
The discipline this requires is drawing the client boundary deliberately. A single interactive element near the top of a tree will pull everything beneath it into the browser bundle, so interactivity belongs in small leaf components rather than in the page.
Measure the field, not the lab
Lab scores on a fast laptop are a development tool, not a result. What matters is the distribution of real sessions — the seventy-fifth percentile on a mid-range Android device over a mobile network.
Those numbers are frequently worse than expected, and they are the only ones that describe what your users are experiencing.
Working on something this touches on? Tell us about it — we are happy to talk it through whether or not it turns into a project.