Our JavaScript budget

JavaScript is powerful, but it is also one of the most expensive resources a browser can receive. It has to be downloaded, parsed, compiled, and executed.

Most content does not need JavaScript

A service description, article, portfolio entry, or documentation page is primarily content. We do not make those pages depend on browser-side React unless there is a reason.

Client components are treated as a cost

When we add a client component, we are adding runtime work. That does not mean client components are bad. It means the decision should be justified.

Third-party code counts too

Analytics tools, advertising scripts, chat widgets, schedulers, and embeds can add more JavaScript than the site itself. We evaluate them as part of the performance budget rather than pretending vendor code is free.

Avoid duplicate libraries

A site should not ship multiple libraries that solve the same small problem. Native browser APIs and simple CSS are often enough.

Measure before adding complexity

When a feature requires a heavier dependency, we ask whether the business value justifies the cost. Sometimes it does. Sometimes a small custom implementation is cleaner. A disciplined JavaScript budget is one of the biggest differences between a site built as a controlled system and a site assembled by stacking plugins until the page works.

The budget starts with a server-first default

The easiest JavaScript to optimize is JavaScript we never send. Most of our public content is rendered on the server or generated ahead of time, so the browser does not need a client-side data layer just to display the page. Interactive features are isolated. A modal can be a Client Component. A gallery can own keyboard state. A mobile navigation system can own its open and closed behavior. The rest of the route can stay server rendered.

That architectural split is the biggest part of our JavaScript budget.

We count vendor code too

A site can have a tiny application bundle and still be slow because advertising tags, chat widgets, schedulers, review embeds, and analytics all execute in the same browser. We treat those scripts as part of the same budget. The visitor does not care which company authored the long task that blocked the main thread.

On the connectrader site, analytics is deferred until interaction or a later timeout so the first rendering window is not dominated by tracking code. Another project may have different attribution requirements, but the decision is still conscious.

Small browser code should have a small lifecycle

One navigation implementation uses a passive scroll listener to update a class after the page moves beyond a small threshold. Gallery components attach keyboard listeners while they need them and remove those listeners during cleanup. Modal behavior restores body overflow when the component closes or unmounts.

Those details matter because client code that never cleans itself up becomes harder to reason about and can create subtle performance or interaction bugs.

Bundle analysis is a diagnostic tool

At least one of our image-heavy repos includes an optional bundle analyzer that can be enabled through an environment flag. We do not run bundle analysis because a chart looks impressive. We use it when the client payload becomes suspicious and we need to know which packages are actually responsible.

The correct response to a large dependency may be code splitting, replacement, or removal. The answer depends on whether the feature earns its cost.

There is no universal kilobyte number

A documentation page, ecommerce configurator, and authenticated dashboard have different legitimate JavaScript needs. We avoid pretending that one arbitrary bundle-size limit defines quality across all products. Our practical rule is simpler: browser code should correspond to browser behavior. If a feature is static information, we should have a very good reason before turning it into client-side application state.