Server-Side Rendering

SSR operates on a per-request basis. When a user or bot requests a URL, the server executes the application code, fetches necessary data from APIs or databases, renders the complete HTML, and sends it back. This is distinct from Static Site Generation (SSG), which serves pre-built files.

• Dynamic Data: HTML reflects the most current data at the time of the request.
• Server Runtime: Requires a Node.js, Python, or similar server environment capable of executing the rendering logic.
• No Client-Side Data Fetching: The initial page load contains all content, eliminating loading spinners for critical information.

The primary architectural advantage of SSR is delivering a fully formed HTML document to search engine crawlers. Social media bots and search engines like Google can immediately parse all content, metadata, and structured data without needing to execute JavaScript.

• Eliminates Empty First Paint: Crawlers do not encounter blank <div> tags waiting for JavaScript to populate them.
• Structured Data Integrity: JSON-LD and Schema.org markup are rendered directly into the source, ensuring reliable parsing.
• Social Share Previews: Open Graph and Twitter Card meta tags are present in the initial HTML, generating accurate link previews.

SSR creates a distinct performance profile. The Time to First Byte (TTFB) is typically higher than static serving because the server must execute logic before sending the first byte. However, the First Contentful Paint (FCP) is often faster because the browser receives a complete HTML payload and can render it immediately.

• TTFB Cost: Server processing time, database queries, and API calls add latency before the response begins.
• FCP Benefit: The browser can paint content without downloading, parsing, and executing large JavaScript bundles first.
• Caching Mitigation: Implementing a CDN with stale-while-revalidate caching strategies can dramatically reduce TTFB for subsequent requests.

After the server sends the static HTML, the browser displays a non-interactive page. The client-side JavaScript bundle then downloads, parses, and executes, attaching event listeners to the existing DOM nodes in a process called hydration. The page is visible but not interactive until hydration completes.

• Time to Interactive (TTI): The delay between FCP and full interactivity can be significant on large pages.
• Progressive Hydration: An advanced technique where individual components hydrate independently, prioritizing interactive elements.
• Islands Architecture: A pattern where mostly static SSR pages contain isolated 'islands' of interactive client-side components, minimizing the JavaScript required for hydration.

Modern frameworks support streaming SSR, which sends HTML chunks to the browser as they are generated, rather than waiting for the entire page to render on the server. This significantly improves TTFB and FCP for pages with slow data dependencies.

• Out-of-Order Streaming: The server can send a static shell immediately and stream in deferred content blocks as data resolves.
• Suspense Boundaries: Components waiting on data can be wrapped in a boundary; the server sends a fallback (e.g., a skeleton) and streams the real content later.
• Backpressure Handling: The server respects the client's ability to receive data, preventing memory overload.

The critical distinction lies in when the HTML is generated. SSR generates HTML on-demand for each request, making it ideal for dynamic, frequently updated content. SSG generates HTML at build time, serving the same file to every user.

• SSR Use Cases: Personalized dashboards, real-time data displays, e-commerce product pages with live inventory.
• SSG Use Cases: Marketing pages, documentation, blog posts.
• Hybrid Approaches: Incremental Static Regeneration (ISR) allows static pages to be updated in the background without a full rebuild, blending the benefits of both models.

A rendering method that pre-builds all HTML pages at build time, serving them directly from a CDN. Unlike SSR, which generates HTML on each request, SSG creates static assets once and reuses them. This eliminates server compute at request time, resulting in the fastest possible Time to First Byte (TTFB). Ideal for content that does not change frequently, such as documentation, blogs, and marketing pages. Frameworks like Next.js, Gatsby, and Hugo implement SSG. The trade-off is that content updates require a full or incremental rebuild.

A hybrid technique that allows developers to update static pages on a per-page basis without rebuilding the entire site. ISR combines the speed of static generation with the flexibility of SSR. When a request arrives for a stale page, the server serves the cached version while triggering a background regeneration. Subsequent requests receive the updated page. This is critical for large-scale content sites where full rebuilds are prohibitively slow. Key parameters include the revalidation interval and fallback behavior for uncached pages.

The client-side process where JavaScript attaches event listeners and state to the static HTML sent by the server. After SSR delivers fully rendered HTML, the browser downloads and executes the JavaScript bundle. Hydration makes the pre-rendered page interactive by connecting the DOM nodes to their corresponding component logic. A common performance pitfall is the uncanny valley where a page looks ready but is unresponsive until hydration completes. Frameworks like React use the hydrateRoot API to perform this reconciliation.

A serverless function that runs at the edge of a CDN network, executing custom logic geographically close to the user. Edge functions enable SSR at the edge, dramatically reducing latency by avoiding round trips to a centralized origin server. Common use cases include:

• Authentication and authorization checks
• A/B testing and feature flagging
• URL rewriting and redirects
• Geolocation-based content personalization Platforms like Cloudflare Workers, Vercel Edge Functions, and Deno Deploy provide this capability. The constraint is a limited runtime environment with restricted CPU and memory.

A set of standardized metrics defined by Google that measure real-world user experience for loading performance, interactivity, and visual stability. SSR directly impacts these metrics:

• Largest Contentful Paint (LCP): SSR improves LCP by delivering fully rendered HTML immediately, eliminating client-side rendering delays.
• First Input Delay (FID) / Interaction to Next Paint (INP): SSR can worsen interactivity if hydration is slow.
• Cumulative Layout Shift (CLS): SSR reduces layout shifts by sending complete markup with defined dimensions. These metrics serve as direct ranking factors, making SSR a strategic SEO decision.

The process of purging or updating cached content when the origin data changes, ensuring end-users receive the most current version. In SSR architectures, HTML responses are often cached at the CDN level to reduce server load. Cache invalidation strategies include:

• Time-to-Live (TTL): Expire cached entries after a fixed duration.
• Surrogate Keys: Tag cached objects with identifiers for targeted purging.
• Purge by URL or prefix: Remove specific cached paths. Poor invalidation logic leads to stale content being served to users and search engine crawlers, undermining the freshness benefits of SSR.