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, 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.
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.
So, we thought, let’s use servers. Again.
Server-side rendering started to be a thing again.
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.
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.
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.
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.
Yet another buzzword, referring to a movement in technology and web development. However, it’s actually really cool!
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.
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.
1. All the data shown is always up to date.
2. You can show user specific and dynamic data that can change frequently.
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
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!)
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