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

在科技领域，许多流行语被扔掉了。 其中两个是静态站点生成(SSG)和服务器端渲染(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.

在本文中，我将尝试使SSR和SSG神秘化，并了解它们在实际中可以为我们提供帮助的地方。 我们将从一些历史开始，然后进入一些真实的示例和技术，例如Next.js和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.

最初，只有静态网页。 没有动态。 纯静态HTML文档已发送到客户端。

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.

当我们访问一个网站时，一个简单的HTTP请求被发送到服务器，该服务器以浏览器显示在屏幕上的实际HTML作为响应。 简单。

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

然后，发生了动态渲染和模板引擎。 您好，PHP和所有其他内容！

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.

这些服务器端技术使我们能够动态构建发送给客户端HTML。 来自客户端的每个HTTP请求都将通过应用程序服务器。 这会增加一些动态内容，例如我们的用户名，当前日期，数据库中的数据等等。

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

这是传统的服务器端渲染。 客户端(我们的浏览器)将获取要显示的实际HTML。

AJAX与前端混乱的开始 (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.

使用AJAX，我们突然能够异步获取数据，而无需刷新整个页面。

This was a big user experience imprvement — 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!

异步数据，新数据，新页面，新前端组件。 现在，前端负责生成需要呈现HTML。 您好，客户端渲染！

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.

由于需要呈现可视标记客户端，因此开始弹出各种库和框架。 当然，这个帮派中最臭名昭著的之一就是jQuery。 如今，我们主要使用更现代的技术，例如React，Vue和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.

到处都有新的库和框架，所谓的前端疲劳开始变得现实。 幸运的是，很明显有一些获奖者，例如React和Vue，它们非常受欢迎。

单页应用程序和一些问题 (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.

现在，所有HTML都是在客户端生成的。 服务器将通过AJAX向浏览器发送一个空HTML和一些JSON或XML数据，并且我们将使用首选的库/框架来填充有意义的标签和样式的页面。 当然，这可以通过客户端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.

单页应用程序(SPA)开始弹出-页面完全在客户端呈现，不需要任何往返服务器的访问，仅通过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.

不幸的是，渲染整个网页客户端也带来了其他一系列潜在的问题。 首先，人们开始关注SEO-搜索引擎优化。

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.

当Google的网络爬虫读取网站并为其编制索引(以便您的网页可以在Google上列出)时，我们担心这些“机器人”将不会拾取尚未呈现HTML。 我们担心Google或其他<在此处插入搜索引擎名称>只会看到我们的根HTML标记，而最终我们将在其中通过JavaScript呈现所有内容。 基本上，爬虫会看到一个空的网页。

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

现在，我们有所放松，因为大多数Web搜寻器和索引器都在执行客户端呈现所需JavaScript。

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.

第二个潜在问题是性能。 由于在浏览器中需要执行(很多)JavaScript才能呈现页面，因此事情可能会变慢，因为大部分Web浏览发生在CPU较弱的移动设备上。

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.

但是，我们不会使用模板引擎或服务器端编程语言来生成标记，而是会使用现代JavaScript库和框架(如React)。 这种方法与客户端渲染(如SPA中)之间的区别在于，标记生成不会在客户端的设备上运行，而是在我们的服务器上运行。

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.

这本来应该更快，但也旨在解决潜在的SEO问题。 每当网络爬虫请求我们的页面时，它都会完全呈现它-不再需要呈现客户端JavaScript。 服务器为每个页面请求完成所有操作。

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.

当我们谈论服务器端渲染时，我们指的是这种确切的情况。 使用现代JavaScript库和框架，针对每个网络请求在服务器端生成一个网页。

服务器端渲染(SSR) (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.

至关重要的是要理解，为了使UI呈现服务器端，我们必须拥有一台服务器。

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.

您会看到，客户端渲染(即SPA)不需要这样做。 这些项目可以缓存并廉价地存储在CDN(内容交付网络)上。 您不应该运行虚拟机或Kubernetes Pod来托管完全由客户端渲染的前端项目。 不过，您确实需要SSR。

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

这是服务器端渲染的潜在负面影响，因为服务器可能变得非常昂贵。

Let’s recap. SSR works like this:

让我们回顾一下。 SSR的工作方式如下：

1. The user agent (browser) requests a page
   用户代理(浏览器)请求页面
2. The server generates the page’s HTML output and sends it back
   服务器生成页面HTML输出并将其发送回
3. The browser renders the HTML
   浏览器呈现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.

好问题！ 这实际上是区分服务器端渲染和静态网站生成的原因。

SSR中的动态内容 (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.

但是，如果输出始终相同(例如，以“关于我们”页面为例)，则始终重新生成输出是没有意义的。 可以将其存储(读取：缓存)在CDN上的某个位置，作为可在世界任何地方快速使用的静态(不变)资源。

静态网站 (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.

这与生成静态站点完全相同。 但是，我们不是使用普通的旧HTML和CSS，而是使用React，Vue和Angular等现代工具，这些工具借助HTML，JSX，CSS，JavaScript，编译器，捆绑器等生成静态输出。

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.
   从您喜欢的前端库中获取静态构建输出，例如React与Next.js或Gatsby配对。 这将包含所有静态资产。
2. Host it on a CDN (no expensive servers needed)
   将其托管在CDN上(无需昂贵的服务器)
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.

该领域的先驱是拥有Next.js的Vercel(以前称为Zeit)，NuxtJS(面向Vue爱好者)，Netlify，Gatsby，Jekyll和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.

通过使用诸如Next.js或Gatsby之类的框架，您可以在React中编写一个Web应用程序，以在构建时获取网站所需的所有数据。

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).

强调这一点很重要：您可以从多个来源(例如电子商务网站的产品，博客文章等)中获取任何数据，但这些数据是可以获取的 仅在构建时(即，在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!

另一个流行词是指技术和Web开发的运动。 但是，它实际上真的很酷！

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

jamstack中的jam代表JavaScript，API，标记。

Basically this movement encourages people to use static websitesthat 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.

基本上，这种运动鼓励人们使用完全不使用服务器的静态网站，从而使托管更便宜，并且应用程序更具弹性且没有停机时间。 在构建时获取数据以呈现页面是Jamstack站点的基本特征。

There are a few great technologies that make Jamstack feasible.

有一些很棒的技术使Jamstack变得可行。

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.

无头的CMS开始受到广泛欢迎。 基本上，这些内容管理系统可帮助您在构建时存储和获取数据。 Netlify CMS和Contentful是无头CMS的两个示例。

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.

例如，每当您通过无头CMS提交新博客帖子时，都会触发前端静态项目的新生成。 整齐！ 您仍然无需为任何服务器付费，并且您的应用程序显示的数据是准动态的。

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.

Netlify和Vercel等平台是Jamstack的先驱，您可以在其中托管静态网站的平台可以使无头CMS与实际静态网站之间的集成变得无缝。

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.

只需按一个按钮即可添加博客帖子和voila ，您的静态站点已重新生成，可以使用全新的内容进行访问。 通过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.

那么，什么时候应该使用SSR？什么时候应该使用SSG？ 让我们来看看一些利弊。

服务器骑行渲染 (Server-ride rendering)

Pros:

优点：

• All the data shown is always up to date.
  显示的所有数据始终是最新的。
• You can show user specific and dynamic data that can change frequently.
  您可以显示经常更改的特定于用户的动态数据。

Cons:

缺点：

• You need a server to run the rendering on — this can get expensive.
  您需要一台服务器来运行渲染-这可能会很昂贵。

• 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).

  您不能使用CDN来帮助您的应用程序更快地加载(您可以在SSR应用程序的前面放置一个缓存层，但是那样的话您可能会显示过时的数据)。

静态网站生成 (Static site generation)

Pros:

优点：

• You would get a very fast website (as it can be deployed to a CDN).
  您会得到一个非常快速的网站(因为它可以部署到CDN)。
• There is no need to wait for server-side logic.
  无需等待服务器端逻辑。
• Doesn’t matter if the server is down (as we don’t need it!)
  服务器是否关闭都没关系(因为我们不需要它！)

Cons:

缺点：

• Not ideal if the content is highly dynamic or user-specific.
  如果内容是高度动态的或特定于用户的，则不理想。
• 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.

了解SSR和SSG不是直接竞争对手至关重要。 当其中一种更为合适时，您将拥有某些用例。

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.

很好-Next.js和类似技术会自动静态地渲染需要构建时间数据(或根本不需要数据)的页面，而服务器端则渲染需要每个请求数据的页面。

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.

您可以选择仅执行一个简单的AJAX请求以重新获取可能过时的数据，但可以使用静态网站。 让您的创造力和背景决定您的决定。

收盘时 (In Closing)

Thanks for taking the time to read this article all the way to the bottom — you rock!

感谢您抽出宝贵的时间从头到尾阅读这篇文章-真是太不可思议了！

I hope that you learned some valuable information.

希望您能学到一些有价值的信息。

Stay creative!

保持创意！