Server-Side Rendering vs. Static Site Generation

 

Many buzzwords get thrown around in the tech space. Two of these are Static Site Generation (SSG) and Server Side Rendering (SSR).

 

 

In this article I’m going to try and demystify SSR and SSG and learn where they can actually help us. We’ll start with a bit of history, then get into some real-world examples and technologies like Next.js and Gatsby.

This will be an interesting story, as we’ll do a full round trip through these technologies and approaches. We will go back to the future, then back to our origins. Let’s get to it!

 

In the Beginning…

 

In the beginning, there were only static web pages. Nothing dynamic. Purely static HTML documents were sent to the client.

 

When we accessed a website, a simple HTTP request was sent to the server, which responded with the actual HTML that our browser put on the screen. Easy.

 

Then, dynamic rendering and templating engines happened. Hello, PHP and all the rest!

 

These server side technologies let us dynamically build the HTML that was sent to the client. Every HTTP request originating from the client would go through the application server. This would add little dynamic pieces, like our usernames, the current date, data from the database, and so on.

 

This was the traditional server side rendering. The client (our browsers) would fetch the actual HTML to be shown.

 

AJAX and the Beginning of the Front-End Chaos

 

With AJAX, we were suddenly able to fetch data asynchronously, without the need for full page refreshes.

 

This was a big user experience improvement — no more annoying screen flashes. But let’s think about this for a second…

 

Asynchronous data, new data, new pages, new front-end components. The front-end is now responsible for generating the HTML it needs to render. Hello, client-side rendering!

 

With the need to render the visual markup client side, various libraries and frameworks started popping up. One of the most notorious of this gang is, of course, jQuery. These days we mainly use more modern technologies, like React, Vue and Angular.

 

So-called front-end fatigue started to get real, with new libraries and frameworks all over the place. Fortunately, it’s clear that there are a few winners, namely React and Vue, which are incredibly popular.

 

Single Page Applications and Some Problems

With the possibility of easily generating the visual markup client-side, we somehow fully abandoned our beloved servers for rendering purposes.

 

All of the HTML was now generated on the client side. The server would send the browser an empty HTML and some data in JSON or XML via AJAX, and we would use our preferred library/framework to fill the pages up with meaningful tags and styles. This was possible, of course, via client-side JavaScript.

 

Single Page Applications (SPAs) started to pop-up — pages that were fully client-side rendered and did not need any round trips to the server, only to fetch data through AJAX.

 

Unfortunately, rendering the whole web page client side also brought a whole other set of potential problems. For one, people started to get concerned about SEO — search engine optimization.

 

As Google’s web crawlers read and indexed websites (so your web page can be listed on Google), we were concerned that these “robots” would not pick up HTML that was not yet rendered. We were afraid that, Google or other <insert search engine name here>, would see only our root HTML tag in which we would eventually render all of the content via JavaScript. Basically, the crawlers would see an empty web page.

 

We’re a bit more relaxed now, as most of the web crawlers and indexers are executing the JavaScript needed for client-side rendering.

 

A second potential problem is performance. As the execution of (a lot of) JavaScript is needed in the browser in order to render the page, things might slow down, as a large percentage of web surfing happens on mobile devices with weak CPUs.

 

So, we thought, let’s use servers. Again.

 

Back to Our Origins

 

Server-side rendering started to be a thing again.

 

However, we would not use templating engines or server-side programming languages to generate the markup, we’d use modern JavaScript libraries and frameworks, like React. The difference between this approach and client-side rendering (as in SPAs) is that the markup generation would not run on the client’s device, but on our servers.

 

This was supposed to be faster, but it also aimed to solve potential SEO problems. Whenever a web crawler asked for our page, it would get it fully rendered — no more client-side JavaScript execution needed for rendering. The server does it all for every page request.

 

When we talk about server-side rendering, we are referring to this exact scenario. Generating a web page, server side, for every network request, using modern JavaScript libraries and frameworks.

 

Server Side Rendering (SSR)

 

It is crucial to understand that in order to have server side rendering of the UI, we must have a server in place.

 

You see, this is not needed for client side rendering (i.e. SPAs). Those projects can be cached and stored cheaply on CDNs (Content Delivery Networks). You shouldn’t run a virtual machine or Kubernetes pods to host your fully client-side rendered front end project. You do need that for SSR, though.

 

This is a potential negative aspect of server-side rendering as servers can become quite expensive.

 

Let’s recap. SSR works like this:

  1.The user agent (browser) requests a page

  2.The server generates the page’s HTML output and sends it back

  3.The browser renders the HTML

 

An extremely important question must be asked. If the server’s output for a page is always the same, why generate the output at every request?

 

Great question! This is actually what differentiates between Server Side Rendering and Static Site Generation.

 

Dynamic Content in SSR

 

If the page that gets generated contains dynamic sections, such as user specific content, it makes sense to use server-side rendering and re-generate the web page for each user (each request).

 

However, if the output is always the same (think of an “About us” page, for example), then it makes no sense to always regenerate the output. That could be stored (read: cached) somewhere, on a CDN, as a static (non-changing) resource that served quickly, anywhere in the world.

 

Static Websites

 

We’re back to where we began our journey!

 

Serving static web pages was the first approach in the world of web. Stored on a server and returned to the client when asked for, in an “as is” way.

 

This is the exact same idea behind Static Site Generation. However, instead of using plain old HTML and CSS, we’re using modern tools like React, Vue, and Angular, that generate a static output with the help of HTML, JSX, CSS, JavaScript, transpilers, bundlers, and so on.

 

You should choose static site generation whenever you lack highly dynamic data that needs to be unique for every user.

 

Here’s the flow for setting up a static web page:

 

1. Get the static build output from your favourite front end library, like React paired with Next.js or Gatsby. This will contain all the static assets.

2. Host it on a CDN (no expensive servers needed)

3. You have a fast and resilient front-end. You’re good to go!

 

As an example, think of a portfolio that you rarely, if ever, update — a web page for a restaurant or a blog, for example.

 

OK, let’s say it’s a blog. You certainly need to add blog posts to it. So, it’s dynamic, isn’t it? Server-side rendering to the rescue!

 

No, not so fast.

 

With modern technologies, static web pages can easily be rebuilt and redeployed when something changes. This is the core principle of modern static site generation.

 

Modern static sites

With the use of cutting edge technologies, our static sites are not actually that static these days. They can have a dynamic side.

 

Pioneers in this field are companies like Vercel (formerly Zeit) with Next.js, NuxtJS (for Vue fans), Netlify, Gatsby, Jekyll, and Hugo.

 

By using frameworks like Next.js or Gatsby, you can code a web app in React that fetches all the needed data for the website at build time.

 

It’s important to emphasize this: You can fetch any data from multiple sources (like products for an e-commerce website, blog posts etc.) but these are fetched only at build time (i.e. when you deploy or host the app on a CDN).

 

As a direct consequence, the data that the static site shows to its users is the data you fetched when you deployed/built your app. Whenever the information to show changes (let’s say you add a new blog post to your cool blog) then you must rebuild the project.

 

As this might seem complicated, but it’s really not. Modern-day tools let us do this extremely easily.

 

The Jamstack

 

Yet another buzzword, referring to a movement in technology and web development. However, it’s actually really cool!

 

The jam in jamstack stands for JavaScript, API, Markup.

 

Basically, this movement encourages people to use static websites that don’t use servers at all, making the hosting cheaper, and the application more resilient with no downtime. Fetching data to render the pages at build time is an essential characteristic of a Jamstack site.

 

There are a few great technologies that make Jamstack feasible.

 

Headless CMSs are starting to gain huge popularity. Basically these Content Management Systems help you store and fetch the data at build time. Netlify CMS and Contentful are two examples of headless CMSs.

 

For example, whenever you submit a new blog post through your headless CMS, it triggers a new build of your front-end static project. Neat! You’re still not paying for any servers and the data your app shows is quasi-dynamic.

 

Platforms where you can host your static websites and are Jamstack pioneers, like Netlify and Vercel, make the integration between the headless CMS and your actual static website seamless.

 

Just press a button to add a blog post and voila, your static site is regenerated and ready to be accessed with brand new content. And it’s still blazingly fast, through a CDN.

 

Server Side Rendering vs. Static Site Generation

 

That was a lot of information!

 

So, when should we use SSR and when should we use SSG? Let’s take a look at a few pros and cons.

 

Server-side rendering

 

Pros:

1. All the data shown is always up to date.

2. You can show user specific and dynamic data that can change frequently.

 

Cons:

1. You need a server to run the rendering on — this can get expensive.

2. You can’t use CDNs which help your app to load much faster (you could put a caching layer in front of your SSR app, but then you’d risk showing stale data).

 

Static site generation

 

Pros:

1.You would get a very fast website (as it can be deployed to a CDN).

2.There is no need to wait for server-side logic.

3. Doesn’t matter if the server is down (as we don’t need it!)

 

Cons:

1. Not ideal if the content is highly dynamic or user-specific.

2. Needs a rebuild when we want to show different or new data.

 

Apples to apples comparison?

 

It’s crucial to understand that SSR and SSG are not direct rivals. You will have certain use cases when one or the other is more appropriate.

 

A personal website or a brand’s site with a blog and some rarely changing data? You might be better off with static site generation.

 

A website unique to a user with personal data, dashboard? Maybe server-side rendering is a better choice.

 

A Hybrid Approach

 

Often with a larger product, you’ll find that certain pages can indeed be statically rendered, while others are better off with server-side rendering.

 

That’s fine — Next.js and similar technologies automatically statically render pages that need build time data (or no data at all) and server-side renders pages that need per request data.

 

Of course, with both of these approaches, client-side data fetching is still a thing.

 

You can choose to just do a simple AJAX request to refetch potentially stale data but otherwise have a static website. Let your creativity and context drive your decisions.

 

transfer from ：https://betterprogramming.pub/server-side-rendering-vs-static-site-generation-53a34872728c