Server-Side Rendering (SSR)

The browser receives a fully populated HTML document, eliminating the blank white screen while JavaScript bundles download and parse. The First Contentful Paint (FCP) metric is dramatically reduced because the server performs the initial render pass. This directly improves Core Web Vitals and perceived load speed, particularly on low-powered mobile devices where client-side JavaScript execution is a bottleneck.

Crawlers receive the final, data-rich HTML in the initial response payload, not an empty shell requiring JavaScript execution. This guarantees that all content, including dynamically fetched data, is discoverable without relying on the crawler's ability to execute and wait for asynchronous JavaScript. This is critical for SEO on content-heavy sites where dynamic rendering would otherwise be a fragile workaround.

The rendering process has direct, low-latency access to databases, internal APIs, and filesystems without exposing these endpoints to the public internet. This enables secure, authenticated data retrieval during the request lifecycle. The server can resolve all data dependencies before sending a single byte of HTML, avoiding the client-side data fetching waterfall and its associated loading spinners.

Because HTML is generated on-demand for each request, the server can inspect cookies, headers, and authentication state to render user-specific content directly into the markup. This enables serving personalized landing pages and authenticated dashboards without exposing client-side routing guards or flashing unauthenticated UI states before JavaScript hydrates the page.

Modern SSR frameworks support HTTP streaming, sending HTML chunks to the browser as they are generated rather than waiting for the entire page to render. The browser can progressively parse and paint content, unblocking critical resources like CSS and fonts early. This is a direct optimization over traditional buffered SSR, reducing Time to First Byte (TTFB) impact on total page load.

Frameworks like Next.js and Remix allow the same React or Vue components to execute on the server and the client. This eliminates the mental context-switching between a server-side templating language and a client-side framework. The hydration process then seamlessly attaches client-side interactivity to the server-rendered DOM without requiring a full re-render, preserving DOM state.

A build-time process that pre-renders every page into static HTML files. Unlike SSR, which generates HTML on each request, SSG creates all pages once at deploy time. This results in the fastest possible Time to First Byte (TTFB) because files are served directly from a Content Delivery Network (CDN) without server compute.

• Ideal for content that doesn't change frequently
• Zero server execution at request time
• Requires a full rebuild to update content

A hybrid strategy that bridges SSG and SSR. ISR allows individual static pages to be regenerated on-demand or on a time-based revalidation interval without rebuilding the entire site. The first request after a page expires triggers a background regeneration, while subsequent users still receive the cached version.

• Stale-while-revalidate caching pattern
• Per-page revalidation intervals (e.g., 60 seconds)
• Combines static speed with dynamic freshness

A technique specifically designed for search engine crawlers that struggle with JavaScript. When a crawler is detected, a pre-rendered static HTML snapshot is served instead of the client-side JavaScript bundle. Human users still receive the fully interactive experience.

• Acts as a bridge for JS-heavy sites
• Often implemented via a headless browser like Puppeteer
• Recommended by Google as a workaround, not a primary solution

The client-side process that makes SSR-delivered HTML interactive. After the browser receives the fully rendered HTML, the JavaScript framework downloads, parses, and attaches event listeners to the existing DOM nodes. Until hydration completes, the page appears functional but buttons and forms won't respond.

• Time to Interactive (TTI) depends on hydration speed
• Frameworks like React use hydrateRoot() for this process
• Partial hydration strategies reduce JavaScript payload

A rendering pattern where a mostly static page contains isolated, independent regions of interactivity called islands. Each island hydrates independently, allowing the majority of the page to ship as zero-JavaScript HTML. This contrasts with traditional SSR where the entire page tree must hydrate.

• Pioneered by frameworks like Astro and Fresh
• Dramatically reduces shipped JavaScript
• Islands can use different frameworks on the same page

A distributed paradigm that moves SSR workloads closer to users by executing server code at CDN edge nodes rather than centralized origin servers. This reduces latency by eliminating long round-trips to a single data center. Edge-rendered pages can achieve near-static performance with fully dynamic content.

• Deployed via platforms like Cloudflare Workers and Vercel Edge Functions
• Cold starts measured in milliseconds, not seconds
• Limited runtime APIs compared to full Node.js environments