The laptop you are reading this on is not representative. Neither is mine.
If you build and test a web product on a development machine over office broadband, you are optimising for a device and a network that most of your users do not have. This is not a new observation. It is just one that is easy to agree with and hard to act on, because acting on it means your work feels slower.
The budget is the design constraint
We set performance budgets before we design, not after we profile. On this site:
| Metric | Budget |
|---|---|
| Largest Contentful Paint | < 2.5s on 4G |
| Interaction to Next Paint | < 200ms |
| Cumulative Layout Shift | < 0.1 |
| Initial JavaScript on / | ≤ 220KB gzipped |
That last one does most of the work. A JavaScript budget is a design constraint disguised as a number: it rules out entire categories of solution before anyone opens Figma. You cannot budget 220KB and also ship a carousel library, an animation runtime, and a component kit that pulls in three of each.
What that bought us here
Concretely, on this site:
- Fonts are self-hosted. No request to a third-party origin in the critical path, no layout shift when the swap lands.
- The convergence diagram is SVG. No canvas, no animation library, no hydration. It renders on the server and costs nothing.
- Almost everything is a Server Component. The client-side JavaScript is the navigation, the forms, and the scroll reveals. Those need state. Nothing else does.
- Dark scenes are CSS variables, not a theming library and not a re-render.
None of these are clever. They are what happens when you decide the budget first and let it delete your options.
Why this is an accessibility issue
Performance work gets filed under "polish", which is exactly wrong. A page that takes twelve seconds on a mid-range Android has not delivered a degraded experience to that user. It has not delivered an experience at all — they left.
You cannot separate "can this person use the thing" from "how long does the thing take". The second question is a special case of the first.
So we test on the slow device first. Not last, when the budget is gone and the only remaining lever is deleting features somebody already paid for.