Keeping Page Weight Under Control With a Performance Budget

Websites rarely become slow because someone approves a single enormous feature called “Make page slow.” They gain an analytics tool, another font, a larger hero image, and a chat widget. Each addition looks manageable; six months later, the page is three times heavier.

A performance budget makes that growth visible while the team can still make a choice about it.

Put numbers on what the page can afford

A basic budget might say:

Homepage total size: under 1 MB
JavaScript: under 150 KB
Hero image: under 250 KB
Third-party JavaScript: under 100 KB

These are examples, not universal limits. A photography portfolio and a documentation page do different jobs. The useful part is agreeing on limits before every feature asks for an exception.

One way to split a transfer-size budget is:

HTML        30 KB
CSS         50 KB
JavaScript 150 KB
Images     700 KB
Fonts      100 KB

Total:

1.03 MB

Now a new 300 KB dependency has a visible cost rather than disappearing into a growing waterfall.

Budget outcomes as well as bytes

File size is easy to enforce, but it does not describe the whole experience. Add targets for user-facing metrics too:

LCP under 2.5 s
CLS under 0.1
INP under 200 ms

I like using both kinds. A metric can reveal a slow image or unstable layout, while byte limits catch gradual growth before it changes a score.

Small is not automatically fast, but page weight affects mobile data, download time, JavaScript processing, image decoding, and cache use. It is hard to accidentally publish a 2 MB hero when the image budget says 250 KB.

Separate the costs most likely to escape

A content site might set a tight JavaScript budget:

JavaScript budget: 50 KB

An application will probably need more. Choose the number from the product’s job, not from a fashionable benchmark.

I would track third-party code separately:

Third-party JavaScript: maximum 100 KB

Analytics, ads, chat, and testing tools otherwise tend to grow outside the main bundle while still running on the visitor’s device.

Images deserve their own limits as well. A photography site could distinguish the jobs:

Hero: 300 KB
Gallery image: 200 KB
Thumbnail: 60 KB

Responsive sources then stop a phone from downloading the desktop candidate merely because both appear in one design.

A broken budget should trigger a decision

If a widget adds 250 KB beyond the limit, the budget has done its job. The team can:

remove something else
↓
load the widget only after interaction
↓
find a lighter tool
↓
decide the feature is worth raising the budget

Raising a budget is allowed. Doing so explicitly records the trade-off; silently ignoring it turns the number into decoration.

Build tools and CI can check asset sizes automatically. On a static site, even inspecting the generated public directory catches unexpected growth. Keep the rules few enough that someone remembers them: total page size, JavaScript, largest image, third parties, and a small set of performance metrics are plenty to begin with.

Performance is easier to protect than recover after every dependency becomes part of the product. A useful budget changes the conversation from “How do we make this fast again?” to “Is this addition worth what every visitor will pay for it?”