Main area
Agency
web-development

Rendering Strategies for Fast Websites

Redaktion ·

Rendering Strategies for Fast Websites

How and where a page produces its HTML largely decides how fast it loads and how costly it is to run. There are several rendering strategies, and none is universally “the best” — each has a clear strength profile. This article looks at them from the development and performance perspective: what each strategy means for TTFB and LCP, for maintainability and cost — and when each fits. The SEO and crawlability view of the same terms is covered in the article SSR, CSR, SSG and hydration.

Static rendering / prerendering

With static rendering, the HTML is generated ahead of time at build — one finished file per URL. On a request, the server (or a CDN) serves that file directly, computing nothing.

  • TTFB: Best possible and consistent — there’s nothing to render, only to serve.
  • LCP/FCP: Very fast, the HTML is there immediately.
  • Interactivity: Low blocking time, as long as little JavaScript is added.
  • Maintainability/cost: Cheap and robust; the catch is that content only changes at the next build.

Ideal for content that rarely changes and has predictable URLs — classic marketing sites, blogs, documentation.

Server-side rendering (SSR)

With SSR, the server generates the HTML per request, freshly. Every call runs through the render logic before the response goes out.

  • TTFB: Depends on server load and data fetching — potentially slower than static, because it computes per request.
  • LCP/FCP: Usually fast, because no extra client round trips for data loading are needed.
  • Interactivity: Often good, because the main thread is blocked less during load.
  • Maintainability/cost: Higher compute cost and more server infrastructure.

Fits anywhere content is personalized or live — dashboards, logged-in areas, real-time data.

ISR / on-demand revalidation

Incremental Static Regeneration (ISR) combines both worlds: pages are served statically but rebuilt in the background after an interval expires or on demand. The user gets the fast static HTML, and the content still stays current — without a full rebuild of the whole site.

  • TTFB: Static-fast for the served version.
  • Freshness: Configurable — from “to the minute” to “rebuild only on change”.
  • Maintainability/cost: Cheaper than pure SSR at large page counts, but more complex in cache behavior.

The ideal choice for large sites with many pages that change occasionally — shops with many products, large content portals.

Edge rendering

Edge rendering moves the computation closer to the user — onto distributed nodes in a CDN instead of a single central data center. It’s not a render type of its own but a place: SSR or revalidation running at the edge.

  • TTFB: Significantly lower, because the physical distance to the user shrinks.
  • Limitation: Edge runtimes are lightweight; not every server logic (large dependencies, long database access) runs well there.

Sensible for globally distributed users and logic that must decide fast and close to the user — geo-personalization, A/B switches, simple SSR.

Hydration — making static HTML interactive

Whatever the server strategy: for the page to be interactive in the browser, the served HTML has to be “brought to life” with JavaScript. This step is called hydration.

Remedies are partial or progressive hydration and the islands architecture: hydrate only the parts that genuinely need to be interactive, instead of the whole page. web.dev explicitly recommends preferring static rendering or SSR over a full rehydration approach.

Which strategy when?

  • Marketing site / blog: Static (prerendering). Fast, cheap, robust.
  • Large content or shop site with many pages: ISR / on-demand revalidation. Static speed plus governed freshness.
  • App with login / live data: SSR, ideally at the edge for lower TTFB.
  • Globally distributed users: Edge rendering as the place for SSR/revalidation.
  • Always: Use hydration sparingly — only where interactivity is genuinely needed.

The basic rule: as static as possible, as dynamic as necessary. Estimating the freshness need honestly avoids expensive SSR where static HTML would long have sufficed.

FAQ

What’s the difference from the SSR/CSR/SSG article? This article looks at rendering strategies from the dev and performance angle: TTFB, LCP, maintainability, cost, and the choice by use case. The other article covers the same strategies under SEO and crawlability aspects.

Which strategy is fastest? Static rendering. The HTML is built ahead of time and only served, so TTFB is consistently low. The price is that content only becomes current at the next build or revalidation.

When is SSR worth it over static? When content is personalized or live — logged-in areas, real-time data, user-specific views. For unchanging content, SSR is usually more expensive and slower than necessary.

What does edge rendering give you? It moves computation closer to the user and thereby lowers TTFB. But edge runtimes are lightweight — heavy logic with large dependencies doesn’t necessarily belong there.

Why is hydration a performance risk? Because it costs main-thread time: the page looks loaded but only responds once the JavaScript has executed. That worsens TBT and INP. Fix: partial hydration or islands — hydrate only the interactive parts.

Themenuebersicht

Web DevelopmentPerformance