The fastest line of JavaScript is the one you didn't ship. The fastest server response is the one served from a CDN edge. These two truths, applied with discipline, make most "performance optimisation" engagements unnecessary — but they require resisting framework defaults that ship a kilobyte of runtime to render five lines of static text.
A practical example. The site you are reading is rendered on a small VM in Frankfurt. Each page is generated server-side per request, but the response is cached at the CDN for an hour, and the cache is purged on content change. The HTML is roughly 14 KB compressed. There is no JavaScript framework, no hydration, no rehydration, no streaming SSR. The cold-cache server response averages 38 ms; the warm-cache response averages 18 ms from the closest edge.
The trick is not magic. It is the result of one decision: to treat HTML as the product, not as something the framework happens to emit. Once HTML is the product, every subsequent decision is calibrated to keep it small, semantic, and cacheable. JavaScript becomes an enhancement, layered on as needed, never as a precondition.
This is not nostalgia. It is the architecture that won the web in 1995 and is still the cheapest way to serve content to a billion devices in 2026. The frameworks, when used judiciously, build on this foundation; when used by default, they obscure it.