There is a story teams tell themselves about performance: build the thing, then optimize it. Somewhere near the end of the roadmap sits a box called performance sprint, and inside that box the site gets fast.
It almost never works, because by then the decisions that made it slow are load-bearing. The carousel that ships four megabytes of JavaScript is now in the brand guidelines. The font family with nine weights is in every component. The optimization sprint trims edges off decisions that should have been different decisions.
Where speed actually comes from
Every fast site we have shipped got fast in the first week, not the last one. Speed came from choices that look like design choices and cost nothing at the time they are made:
One typeface instead of three. Static pages that ship no JavaScript unless a component genuinely moves. Images sized to their containers before anyone writes CSS. Motion that runs on the compositor, so a heavy main thread cannot make the interface stutter.
None of that is optimization. It is just the design, decided with the network in the room.
The budget is the brief
We put performance targets in the first document the client sees, next to the goals and the timeline. Largest paint under 1.2 seconds on 4G. Zero layout shift. Interaction under 100 milliseconds. Written down early, these numbers behave like any other design constraint: they quietly kill bad ideas before anyone falls in love with them.
Written down late, they become a fight with work someone already shipped.
A performance budget in week one is a constraint. In week twelve it is a confrontation.
The site you are reading follows its own advice. Most pages ship no script at all, and the ones that move stay under budget. Not because we optimized, but because we decided.