Why Rendering Patterns Matter More Than Ever

Every millisecond counts on the web. Google’s own research shows that a page loading in 2.5 seconds instead of 1 second can increase bounce rate by over 30%. Core Web Vitals — LCP, FID (now INP), and CLS — are ranking factors, and the rendering pattern you choose directly determines how well your site performs against them.

But here’s the challenge: there’s no single “best” approach. The right rendering strategy depends on your content type, update frequency, traffic volume, and infrastructure. That’s why understanding SSR, SSG, and ISR isn’t just a developer concern — it’s a business decision.

In this article, we’ll break down each rendering pattern, compare their performance profiles with real numbers, and help you decide which one fits your project.

The Three Main Rendering Patterns Explained

Before diving into benchmarks, let’s establish clear definitions.

SSR — Server-Side Rendering

With Server-Side Rendering (SSR), the server generates the full HTML page on every incoming request. The user’s browser receives a complete document, which it can display immediately while JavaScript hydrates in the background.

How it works step by step:

  1. User requests a page (e.g., /products/shoes)
  2. The server runs the page’s data-fetching logic (API calls, database queries)
  3. The server renders the React/Vue/Svelte component tree into HTML
  4. The complete HTML is sent to the browser
  5. The browser displays the page, then loads and hydrates JavaScript

Best for:

  • Pages with personalized or frequently changing content
  • Search results, dashboards, authenticated pages
  • Content that must be fresh on every request

Trade-offs:

  • Higher Time to First Byte (TTFB) — typically 200–600 ms depending on server and data source latency
  • Server costs scale linearly with traffic
  • Requires a running server (Node.js, Deno, etc.)

SSG — Static Site Generation

Static Site Generation (SSG) pre-renders every page at build time. The output is plain HTML, CSS, and JavaScript files that can be deployed to any CDN.

How it works step by step:

  1. During the build process, the framework fetches all necessary data
  2. Every page is rendered to a static HTML file
  3. Files are uploaded to a CDN (CloudFront, Vercel Edge, Cloudflare Pages, etc.)
  4. Users receive the pre-built HTML directly from the nearest edge node

Best for:

  • Blog posts, documentation, marketing pages
  • Product catalogs that update infrequently
  • Any content where freshness measured in minutes or hours is acceptable

Trade-offs:

  • Build times grow with the number of pages (10,000 pages can mean 10+ minute builds)
  • Content can become stale between builds
  • Not suitable for real-time or personalized content

ISR — Incremental Static Regeneration

Incremental Static Regeneration (ISR) is the hybrid approach popularized by Next.js. Pages are statically generated at build time and automatically regenerated in the background after a defined revalidation interval.

How it works step by step:

  1. At build time, pages are pre-rendered just like SSG
  2. A revalidate interval is set (e.g., 60 seconds)
  3. When a user visits after the interval expires, the stale page is served instantly
  4. In the background, the server regenerates the page with fresh data
  5. The next visitor receives the updated version

Best for:

  • E-commerce product pages (price and stock changes)
  • News sites, blogs with frequent updates
  • Any page that needs a balance of speed and freshness

Trade-offs:

  • Still requires a server/serverless function for regeneration
  • The first visitor after interval expiry sees slightly stale content
  • More complex caching logic

Performance Benchmarks: Head-to-Head Comparison

Let’s look at concrete numbers. The following table summarizes typical performance characteristics based on industry benchmarks and real-world measurements from projects delivered by agencies like Lueur Externe, which has been optimizing web performance since 2003.

MetricSSRSSGISR
TTFB200–600 ms10–50 ms10–50 ms (cached) / 200–600 ms (regeneration)
LCP1.2–3.0 s0.5–1.2 s0.5–1.5 s
Build time (10K pages)N/A8–15 min2–5 min (on-demand)
Content freshnessReal-timeBuild-time onlyConfigurable (seconds to hours)
Server cost at scaleHighVery low (CDN only)Low to moderate
SEO crawlabilityExcellentExcellentExcellent
PersonalizationFullNone (without client JS)Limited (without client JS)

These numbers assume a modern framework (Next.js 14+, Nuxt 3, or Astro) deployed on a CDN-backed platform.

The TTFB Gap Is Real

The most dramatic difference is TTFB. A statically generated page served from a CDN edge node 50 km from the user will consistently deliver a TTFB under 50 ms. The same page rendered via SSR on a server in us-east-1 will take 200+ ms for a European user — before any data fetching is even considered.

Over millions of page views, that 150–500 ms difference compounds into measurably higher bounce rates and lower conversion rates.

Choosing the Right Pattern: A Decision Framework

Here’s a practical framework to guide your decision:

Choose SSG When:

  • Content changes less than once per hour
  • You have fewer than 50,000 pages (or can tolerate longer builds)
  • You want the absolute lowest hosting cost
  • Maximum performance is the top priority
  • Examples: documentation sites, landing pages, portfolios, blogs

Choose SSR When:

  • Content is personalized per user (logged-in dashboards, account pages)
  • Data must be real-time (stock prices, live inventory)
  • Pages depend on request headers (geolocation, A/B testing)
  • Examples: SaaS dashboards, authenticated portals, search results

Choose ISR When:

  • Content updates regularly but not in real-time
  • You need SSG-level performance with better freshness
  • Your site has thousands of pages and build time is a bottleneck
  • Examples: e-commerce catalogs, news articles, CMS-driven marketing sites

Implementation Example: Next.js Page With ISR

Here’s a concrete example of how ISR is implemented in a Next.js 14 App Router project:

// app/products/[slug]/page.tsx

import { getProduct, getAllProductSlugs } from '@/lib/api';

// Generate static paths at build time
export async function generateStaticParams() {
  const slugs = await getAllProductSlugs();
  return slugs.map((slug) => ({ slug }));
}

// Fetch data with ISR revalidation every 60 seconds
async function ProductPage({ params }: { params: { slug: string } }) {
  const product = await getProduct(params.slug);

  return (
    <main>
      <h1>{product.name}</h1>
      <p>Price: €{product.price}</p>
      <p>{product.description}</p>
    </main>
  );
}

export const revalidate = 60; // ISR: revalidate every 60 seconds

export default ProductPage;

With just the revalidate = 60 export, this page behaves as a static page that automatically refreshes its data every 60 seconds. No full rebuild needed, no server-side computation on every request.

What This Gets You

  • First visit: served from CDN cache (TTFB ~30 ms)
  • After 60 seconds: next visit triggers background regeneration; user still gets cached version instantly
  • After regeneration: all subsequent visitors get the fresh page from CDN

This pattern is especially powerful for PrestaShop storefronts using a headless architecture, a setup that Lueur Externe has deployed successfully for e-commerce clients needing both the rich back-office of PrestaShop and the front-end performance of a modern JavaScript framework.

The Hybrid Approach: Mixing Patterns in One Project

Modern frameworks don’t force you to pick one pattern for your entire site. This is arguably the most important takeaway from this article.

In a single Next.js or Nuxt project, you can:

  • Use SSG for your /about, /contact, and /blog pages
  • Use ISR for /products/[slug] and /blog/[slug] pages
  • Use SSR for /dashboard, /cart, and /account pages
  • Use CSR (Client-Side Rendering) for interactive widgets that don’t need SEO

This per-route flexibility is a game-changer. It means performance optimization isn’t an all-or-nothing bet — it’s a surgical, page-by-page decision.

Mapping Rendering Patterns to a Typical E-Commerce Site

PagePatternWhy
HomepageISR (revalidate: 300)Updated promotions, but not real-time
Category pagesISR (revalidate: 60)Products/stock change, but CDN speed needed
Product detail pagesISR (revalidate: 60)Price/stock freshness balanced with performance
Blog / guidesSSGContent changes rarely
Cart pageSSR or CSRFully personalized, real-time
CheckoutSSRSecure, personalized, real-time
Account dashboardSSRAuthenticated, per-user data
Legal / CGV pagesSSGStatic content, rarely updated

Impact on Core Web Vitals and SEO

Google’s Core Web Vitals are directly influenced by your rendering choice:

Largest Contentful Paint (LCP)

SSG and ISR consistently deliver LCP under 1.5 seconds because the HTML is pre-built and served from edge locations. SSR pages often struggle to meet the 2.5-second “good” threshold, especially under heavy load or with slow databases.

Interaction to Next Paint (INP)

All server-rendered approaches (SSR, SSG, ISR) deliver HTML that displays before JavaScript loads. However, hydration cost — the time JavaScript takes to make the page interactive — is roughly the same across all three. The difference lies in how quickly the initial HTML arrives.

Cumulative Layout Shift (CLS)

Rendering pattern has minimal direct impact on CLS. Layout shift is primarily caused by images without dimensions, dynamically injected content, and web fonts. However, SSR and ISR can reduce CLS indirectly by delivering a complete HTML structure that prevents content jumping.

SEO Crawlability

All three patterns serve fully-rendered HTML, which means search engine crawlers can index content without executing JavaScript. This is a significant advantage over pure Client-Side Rendering (CSR), where Googlebot may not reliably index all content.

Common Pitfalls to Avoid

Even with the right pattern chosen, implementation details can sabotage performance:

  • Over-fetching data in SSR: Every millisecond of API/database latency is added to TTFB. Use parallel data fetching and aggressive caching.
  • Enormous JavaScript bundles: A 500 KB JavaScript payload negates the speed of a fast TTFB. Code-split aggressively.
  • Ignoring CDN configuration: SSG and ISR pages must be properly cached at the CDN level. Misconfigured cache headers can turn a static site into a slow one.
  • Setting ISR revalidation too low: A revalidate: 1 essentially turns ISR into SSR with extra steps. Use the highest interval your content freshness requirements allow.
  • Not monitoring real-user metrics: Lab benchmarks (Lighthouse) are useful, but field data from Chrome UX Report (CrUX) tells the true story.

What About Edge Rendering and Streaming?

The landscape continues to evolve. Two emerging patterns are worth watching:

Edge SSR

Platforms like Vercel, Cloudflare Workers, and AWS Lambda@Edge now support running SSR at the network edge — close to the user. This dramatically reduces TTFB for SSR pages (often to 50–100 ms), narrowing the gap with SSG.

Streaming SSR

React 18’s streaming architecture allows the server to send HTML in chunks as data becomes available. The browser starts rendering the page’s shell immediately while slower data loads in progressively. This improves perceived performance even when total processing time remains the same.

Both patterns are supported in Next.js 14+ and are worth exploring for performance-critical applications.

Real-World Impact: Numbers That Matter

Here are some performance improvements commonly observed when migrating from pure SSR or CSR to a hybrid SSG/ISR architecture:

  • TTFB reduction: 60–85% (from ~400 ms to ~50 ms on cached pages)
  • LCP improvement: 40–60% (from ~2.8 s to ~1.2 s)
  • Bounce rate decrease: 15–25% (directly correlated with faster load times)
  • Hosting cost reduction: 30–70% (fewer server invocations, more CDN hits)
  • Build time reduction (ISR vs full SSG): 50–80% for large sites

These numbers align with what the team at Lueur Externe has documented across multiple client projects spanning PrestaShop headless deployments, WordPress front-end rebuilds, and custom Next.js applications hosted on AWS.

Conclusion: Performance Is a Strategy, Not an Afterthought

Rendering patterns aren’t just technical implementation details — they’re strategic decisions that affect your Core Web Vitals scores, your SEO rankings, your bounce rate, and ultimately your revenue.

The key takeaways:

  • SSG delivers unbeatable raw speed for static content
  • SSR is essential for personalized, real-time pages
  • ISR offers the best of both worlds for content that updates periodically
  • The hybrid approach — mixing patterns per route — is almost always the optimal solution
  • Edge rendering and streaming are pushing performance boundaries even further

Choosing the wrong pattern (or not choosing deliberately at all) can cost you hundreds of milliseconds per page load — and with Google’s performance standards tightening every year, those milliseconds translate directly into lost rankings and lost customers.

If you’re planning a site migration, a headless commerce build, or simply want to audit your current rendering strategy, Lueur Externe can help. With over 20 years of experience in web development, certified expertise in PrestaShop, WordPress, and AWS architecture, and deep specialization in SEO and performance optimization, we help businesses in the Alpes-Maritimes and beyond build sites that are fast, scalable, and built to rank.

Get in touch with our team → and let’s find the rendering strategy that’s right for your project.