Web Performance as Architecture
Why treating performance as a late-stage optimization fails, and how to design systems that are fast by default.
Contents
The most common performance failure mode in modern web development is treating speed as a bug to be fixed at the end of a project.
Teams spend months building a massive React application for a documentation site, ignoring the growing bundle size. When the site launches and mobile performance is abysmal, they attempt to “optimize” it by adding memoization, complex caching layers, and lazy-loading boundaries.
It rarely works. You cannot optimize your way out of a fundamentally heavy architecture. Performance is not a cleanup pass; it is the structural consequence of your rendering model and how much JavaScript you demand the browser execute.
The Cost of the Hydration Tax
For the last decade, the default mental model for building a frontend was the Single Page Application (SPA). To make SPAs load faster, the industry adopted Server-Side Rendering (SSR).
But SSR introduced the Hydration tax.
Hydration is the process where the browser downloads the HTML, then downloads the JavaScript, and then executes that JavaScript to re-attach event listeners and rebuild the state tree. During hydration, the main thread is blocked. The page looks ready, but if the user clicks a button, nothing happens.
The Device Reality
Developers usually evaluate performance on M-series MacBooks on gigabit fiber. This produces false certainty.
On a budget Android device on a 3G network, the hydration tax is catastrophic. Parsing and executing 500KB of JavaScript takes milliseconds on a developer’s laptop, but can take seconds on a mid-tier phone. During those seconds, the device is frozen.
Architectural Responses to the Performance Crisis
If indiscriminately hydrating the entire page is the problem, the solution is selective execution. The industry has produced three distinct architectural responses to this problem.
Rendering Model Comparison
Here is how the modern rendering models solve the hydration tax.
| Model | How it Works | The Benefit | The Trade-off |
|---|---|---|---|
| Full Hydration (Standard Next/Nuxt) | Server renders HTML. Client loads all JS and re-hydrates the entire page. | Unified mental model; easy to build complex global state. | Heavy CPU cost. Slow Time-to-Interactive on mobile. |
| Islands Architecture (Astro) | Page is static HTML. Only specific, marked components load JS and hydrate. | Zero baseline JS. Unbeatable performance for content sites. | Developer must manually declare interactive boundaries. |
| Resumability (Qwik) | Server serializes event handlers into HTML. Client “resumes” without running component code. | Instant interactivity. Zero hydration tax regardless of app size. | Unorthodox mental model; tight coupling to framework compiler. |
| Server Components (RSC) | Server executes components and sends a proprietary payload to the client. | Backend access directly in UI code; smaller client bundles. | Requires a Node/Edge runtime; complex caching semantics. |
Worked Examples: What Not to Hydrate
To build performant systems, you must develop an instinct for what does not need to be interactive.
Example 1: The Documentation Page (Should remain static)
You are building an article page like this one. It has 2,000 words of text, a few code blocks, and a sidebar navigation menu.
The Bad Architecture: Rendering this in a standard SPA. The browser downloads the entire article as a JSON payload, plus the React runtime, plus the router, and then builds the DOM elements on the client. The Good Architecture: Render it as static HTML. The only JavaScript required is a tiny script to toggle the mobile navigation menu.
Example 2: The E-Commerce Product Page (Hybrid)
You have a product page with a static description, a carousel of images, and an “Add to Cart” button that updates a global cart counter.
The Bad Architecture: Hydrating the entire page so the “Add to Cart” button can talk to the header. The browser wastes CPU cycles hydrating the footer and the static product description. The Good Architecture (Islands): The product description and footer are static HTML. The Image Carousel is one Island. The “Add to Cart” button is another Island. They communicate via lightweight custom events or a tiny shared store (like Nano Stores), without waking up the rest of the page.
Decision Rules for Content-First Systems
If you are building a publication, marketing site, or knowledge base, adopt these heuristics:
- Default to HTML: Start with zero JavaScript. Demand justification for every byte of JS added.
- Isolate Interactivity: If you need a complex calculator on an article page, build it as an Island. Do not make the article pay the performance cost of the calculator.
- Avoid Desktop-Only Evaluation: Never sign off on a rendering strategy without throttling your CPU to 4x slowdown and your network to Fast 3G in DevTools.
- Architect for the 90th Percentile: If 90% of your site is reading material and 10% is interactive forms, choose an architecture optimized for reading (like Astro), not an architecture optimized for complex state (like a full SPA).
You can always add an interactive island to a static page, but you cannot easily strip the hydration tax out of an SPA.
Related Guides and Terms
Deepen your understanding:
- Choosing the Right Stack for Content vs App — How this applies to framework choice.
- What Frontend Architecture Really Is — How boundaries affect performance.
- MDX, Content Collections, and Content-as-Architecture — Implementing performance-conscious publishing.