Server-Side Rendering

As SPAs spread, a new set of problems emerged. Until the browser receives the empty HTML, downloads the JavaScript, executes it, and renders the screen, the user sees a blank page or a loading spinner. On a slow network or a low-powered device, this wait can stretch to several seconds. The larger problem is search engines. When a search bot visits a page and does not execute JavaScript, it sees only empty HTML, and the content is not indexed. For services like blogs, news sites, and product pages where users arrive through search, this results in losing traffic entirely. When a URL is shared on social media, an empty preview card also reduces click-through rates. SSR solves both of these problems at the root by sending completed HTML from the server.

In the early web, every page was rendered by the server. Server-side template languages like PHP, JSP, and ASP generated HTML per request, and this was the natural way. The arrival of SPAs shifted rendering responsibility to the browser and enriched the user experience, but gave up the longtime advantages of initial load speed and SEO. From the mid-2010s, the frontend framework ecosystem began to embrace the idea: 'if the same components can be rendered on the server, we can have the advantages of both'. As universal (or isomorphic) rendering -- executing the same code on both server and browser -- became possible, modern SSR took hold: the server completes the initial HTML and the browser picks up from there to handle interaction.

The operation of SSR breaks down into four stages. First, the user requests a URL and the server receives it. Second, the server queries the data needed for that page from a database or API. Third, it inserts the queried data into the component tree and generates a completed HTML string -- this is the server-side rendering step. Fourth, the completed HTML is sent to the browser, where the user can immediately see the content. This is not the end. After the browser displays the HTML and loads the JavaScript bundle, a process called Hydration begins. Event handlers are attached to the already-rendered HTML, and subsequent interactions are handled by client-side JavaScript. From the user's perspective, the page appears immediately, and shortly afterward interactions like button clicks become active. Because the time spent generating HTML on the server directly affects response time, slow data queries make users wait just as long. This is why caching strategies and techniques like streaming SSR are commonly used alongside SSR.

SSR and SSG (Static Site Generation) are similar in that both involve the server completing the HTML, but they differ in when this happens. SSR generates HTML on the server each time a user requests it, while SSG pre-generates HTML files at build time. This difference determines appropriate use cases. SSG is suited for blogs, documentation sites, and marketing pages where content does not change frequently. Pre-built files served directly from a CDN require almost no server load and deliver fast responses. SSR is suited for pages that show different content based on login state or must reflect real-time data. The tradeoff is that the server must perform rendering for every request, which requires server resources. Compared to SPAs, SSR shows the first screen quickly and is favorable for SEO but incurs server costs, while SPAs are fast for navigation after the initial load but weak on the initial screen and SEO. Modern frameworks allow SSR, SSG, and client-side rendering to be mixed per page, making this boundary increasingly flexible.

SSR delivers its clearest benefits on content pages where search engine traffic is important, product detail pages, and news sites. Pages that need OG tags in completed HTML when shared on social media are also natural candidates for SSR. From an operational standpoint, SSR requires the server to perform rendering on every request, so server resource consumption grows significantly with high traffic. Without a caching strategy, the same page is regenerated every time, creating unnecessary waste. Combining CDN caching, page-level caching, and data caching to manage server load is the core operational challenge of SSR. Hydration also cannot be ignored. Although the HTML sent by the server appears immediately, there is a window before JavaScript has loaded and Hydration is complete during which button clicks do not respond. The user sees the screen but cannot interact with it. Techniques like Selective Hydration and Server Components are advancing to close this gap. Not every page needs to be SSR. A practical hybrid strategy is to use SSR or SSG for public pages and client-side rendering for post-login dashboards.