There are three primary ways that web pages are rendered today: SSG (Static Site Generation), SSR (Server-Side Rendering), and CSR (Client-Side Rendering). These are the processes by which the contents of a web page are generated & delivered to a viewer’s browser. These methods describe when & where content is generated before it appears in a user’s browser.

When

Content can be generated before the user visits the site (static site generation), when a page is requested (server-side rendering), or dynamically using JavaScript after the page loads in the browser (client-side rendering).

Where

Rendering can happen in three places: on the server (when a request is processed before its sent to the browser), in the browser (after the browser loads a blank HTML page & JavaScript renders the content) or at build time (from a previously-generated static file).

Why

So, why does this matter? Each of these methods affects key areas of the user experience as well as back-end processes. For the user, the rendering method primarily impacts performance & interactivity. Delivering static HTML is much faster than handling complex JavaScript. But, while sending pure HTML is fine for static sites, sites that are interactive, like an ecommerce site or a web application, will have components that need to update in real time. This requires client-side JavaScript, which calls for more browser resources for it to render content.

On the back-end, SEO, hosting & the developer experience are impacted by the rendering method. Search engines need to see content easily, which means that statically-generated sites & server-side rendered sites perform best for SEO. Client-side rendering don’t make use of permanently-stored web pages, so web spiders can’t crawl the pages – their content doesn’t exist until they’re rendered. In the case of server-side rendered sites, the server generates content per request, so it exists in the HTML at the time of request & spiders can see it. For web applications, SEO is often unimportant, but user interactivity & the developer experience are vital, which makes client-side rendering favorable.

SSR

The original rendering method was SSR (server-side rendering). Its how the web worked in the beginning – a user typed a URL into the browser, the browser sent a request to the web server, the server ran some back-end code & generated HTML. This HTML was then sent back to the browser which then rendered it.

Content generated this way is always fresh, which is a strength for pages with data that frequently changes on the back-end. Its also good for SEO since the content is included in the HTML. However, its slower than SSG because HTML is generated every time the server receives a request. This also means that websites with high traffic will put more pressure on their servers to generate content to satisfy requests.

Ecommerce product pages that show real-time data like pricing & inventory are good candidates for this approach. Tools like Next.js, Express coupled with a frontend library or framework like React or Vue & traditional PHP sites make use of this method.

CSR

Client-side rendering is a method in which the browser loads a basic HTML page with a JavaScript bundle. Once loaded, the browser runs the JavaScript to render the content. It was developed as websites became more interactive (think Gmail, Facebook, dashboards, etc.) & developers moved more logic to the browser. Data is grabbed after the page loads using APIs like fetch() & Axios.

CSR is dynamic & interactive. Applications built using the approach feel like a desktop application. Its great for single-page applications (SPAs). Because all of the rendering is done by the client, no server rendering is needed, so hosting is simpler, often only needing a front-end to be deployed. However, there’s often a slower initial load because the content isn’t included in the HTML & its not good for SEO unless combined with tools like pre-rendering. Its possible for applications to flash blank or loading states (loading spinners) before content appears.

This approach is commonly used when building dashboards or web applications (like Trello or DevLeads). React, Vue, Angular and headless frontends that call APIs all make use of this method.

SSG

Static-site generation is a method in which the HTML for each page is generated ahead of time, at build time, and stored as plain .html files. When a user visits the site, the server just sends that static HTML file. Because of this, its very fast. Its just sending out static files from a CDN or server. The static pages are good for SEO because the content is already in the HTML & its secure because there’s no backend code running at request time. Backend code can still run at build time.

Blogs and brochure sites are good candidates for SSG. Tools like Astro, 11ty, Hugo & Next.js (in SSG mode) make use of this approach. However, its not ideal for pages with content that changes frequently or need to be personalized per user & site rebuilds can be slow if there are a lot of pages to be generated.

Moar, plz

There are now additional hybrid rendering methods available as well. They build on the traditional three methods above & are used by modern front-end web frameworks to optimize different use cases. For example, Incremental Static Regeneration (ISR) combines the speed of SSG with the flexibility of SSR by allowing pages to be updated after deployment without a full rebuild. Other techniques like partial hydration and streaming help balance performance and interactivity by only rendering parts of a page as needed.