Rendering strategy review

Why rendering strategy matters

Where and when HTML is produced shapes almost every metric a user feels. Server rendering tends to show content sooner and ship less JavaScript, at the cost of server work and a slower first byte. Static generation gives a fast, steady first byte but struggles with personalized or fast-changing pages. Client-side rendering keeps servers simple but makes the browser download and run JavaScript before anything useful appears, and that code tends to grow with the app. These trade-offs are set out well in Google's long-running guide to rendering on the web, last updated in January 2026, which also recommends mixing strategies per page rather than forcing one choice everywhere (source 1).

Frameworks have made mixing easier. Next.js lets a single route combine a prerendered shell with dynamic parts streamed through Suspense, using the 'use cache' directive and Cache Components (source 2). React 19.2 added Partial Pre-rendering APIs that prerender static parts ahead of time and resume rendering for the dynamic rest (source 3). Astro renders pages as HTML and lets only marked components hydrate as islands, with server islands for slow, personalized fragments (source 4). The options are good; the hard part is choosing well for each route.

What the review looks at

• Route inventory. Every important route, how it renders today, how often its data changes and whether it is personalized.
• Data shape. Which data is shared by all users, which is per user, and which can be a few minutes stale without harm.
• Measured cost. Time to first byte, first contentful paint and the gap between paint and interactivity on throttled devices, so the comparison starts from evidence.
• JavaScript weight per route. How much code each route ships and how much of it exists only to rebuild markup the server already sent.
• Caching and hosting. What your CDN and hosting can cache, how cache invalidation works today and what a change would require.
• Search and sharing. Whether routes need complete HTML for crawlers and link previews, which affects how far client rendering can go.
• Team cost. Build times, local development, testing and the skills on the team. A strategy that saves 300 ms but doubles build time may not be worth it.

How we run it

1. 01

   Inventory and interviews

   A short call with the people who own the routes, followed by a written route list we agree together.

2. 02

   Baseline traces

   We trace each route family on a fast and a throttled profile and record how long content and interactivity take today.

3. 03

   Option sketches

   For the routes where a change looks promising, we sketch the alternatives in your framework's terms, for example a static shell with streamed dynamic sections, or islands instead of full hydration.

4. 04

   Prototype where it helps

   If a decision depends on a number we cannot estimate safely, we build a small throwaway prototype of one route and measure it. This is agreed in the quote, not added later.

5. 05

   Recommendation

   A written recommendation per route with the expected direction of change, the costs and the order we would tackle them in.

What you receive

A route-by-route table listing the current mode, the recommended mode, the reasoning and the risks; a narrative report explaining the bigger choices; diagrams of the proposed rendering flow for the main routes; and a 60-minute walkthrough. If we prototyped a route, you also receive the prototype code and its traces.

The review is honest about uncertainty. Where we expect a change to help but cannot size the gain before it ships, the report says that, and suggests how to measure it safely, for example by moving one route first and comparing field data.

Who this suits

Teams planning a framework upgrade or migration, teams whose client-rendered app has grown heavy, and teams that adopted server rendering everywhere and now pay for it in hydration time. It also suits product leads who need a clear explanation of the options before committing engineering months to one of them.

Signs your current strategy no longer fits

• A client-rendered app whose first load has grown slow as features were added, while most of its routes show content that could be rendered earlier.
• A server-rendered app where the first byte is slow under load because pages that could be cached render per request.
• Pages that look ready quickly but stay unresponsive while the whole app hydrates.
• Personalized fragments, such as a signed-in name or a cart count, forcing whole routes to render per request.
• Build times that have grown because thousands of static pages rebuild on every deploy.

Any one of these is a reason to look again at how routes render. None of them, on its own, says what the answer is; that depends on the route.

What a recommendation looks like

Each route family gets a short entry. An invented example: "Product detail pages. Today: server-rendered per request, full hydration. Recommended: cached shell with shared product content, personalized price and stock streamed through Suspense; reviews hydrate on view. Why: product content changes a few times a day, while price and stock are per user and per minute. Expected direction: earlier first byte from cache, less hydration work. Risks: cache invalidation when product content changes; personalized parts need loading states that do not shift layout." The table in the report gathers these entries, and the narrative explains the reasoning behind the bigger moves.

Questions about strategy reviews