作为开发者，我们经常会面临一些影响我们整个网站结构的决定，其中web开发者一定要做的核心决定之一就是在应用程序中实现逻辑和渲染的位置。这可能比较难，因为有很多不同的方式来构建一个网站。

我们在这一领域的了解主要来源于在过去的几年在Chrome工作期间，一直与一些大的网站的交流得来的。从广义上来讲，我们鼓励开发人员去通过完全rehydration方法进行服务端渲染或者是静态渲染。

为了更好的理解我们所选择的技术架构，我们需要对每种方法有一种扎实的理解，并且在谈论时要使用一致的术语。这些方式的不同点有助于我们说明通过性能和渲染之间寻求一个平衡。

术语

渲染

SSR: Server-Side Rendering - 在服务器端渲染内容的方式。

CSR: Client-Side Rendering - 通常在浏览器中使用DOM来渲染应用程序的过程。

Rehydration: 在客户端“启动”Javascript视图，使得他们能够重用服务器端渲染的html的dom树和数据。

Prerendering: 在构建时运行客户端应用程序来使用其初始状态作为静态的html页面。

性能

TTFB: Time to First Byte - 点击一个链接到返回的第一个字节数据所用的时间。

FP: First Paint - 首次任何像素对用户可见的时间（也就是首先将像素绘制到屏幕的时刻）。

FCP: First Contentful Paint - 首次内容对用户可见的时间（也就是浏览器将第一个 DOM 渲染到屏幕的时间）。

TTI: Time To Interactive - 页面变为可交互的时间。

服务器端渲染

服务器端渲染会在服务器上生成整个的HTML页面，然后整体返回给浏览器。由于它在返回给浏览器之前就已经处理好了，所以会避免客户端在数据获取和模板化的额外开销。

服务器渲染很快就会产生First Paint（FP）和First Contentful Paint（FCP）。在服务器端运行页面逻辑和渲染，使之避免了因此而发送大量的Javascript给客户端。也会有助于我们实现一个快速的Time To Interactive（TTI）。这是可能的，因为在服务器端渲染的话，你仅仅需要发送文本和链接给浏览器。这种方式在大范围的设备和网络环境下都会很好的运行，与此同时也会提起你对浏览器优化的兴趣，比如说流文档解析。

通过服务器端渲染，用户不太可能等待CPU绑定的javascript处理完毕之后才能去使用您的站点。即使是第三方js不可避免。使用服务器端渲染也会减少你的js开销，会给您处理其他事情留有更多的“预算”。然而，这种方式有一个主要的缺点：在服务器端生成页面会减慢你的Time To First Byte（TTFB）。

服务器端渲染对于你的应用程序是否够用，很大一部分依赖于你个人的构建经验。在服务器端渲染和客户端渲染哪一个更好这个争论曾经持续了很长时间。但是要记住很重要的一点，你可以在一些页面中使用服务器端渲染，而不是全部都用。一些网站已经成功使用了混合渲染技术，Netflix在服务器端渲染，呈现其相对于静态的页面，同时为交互繁重的页面预取js，给这些较重的客户端页面提供一个更快的加载机会。

许多现代浏览器，类库和架构使得在客户端和服务器端渲染同一个应用程序成为可能。这些技术可以被用于服务器端渲染，然而，重要的是注意在客户端和服务器端渲染的架构都有他们不同的解决方案，具有非常不同的性能特征和权衡。React用户可以使用renderToString()或者是在其之上的解决方案来实现服务器端渲染，比如说Next.js。Vue用户可以查阅Vue的server rendering guide或者是Nuxt。Angular有Universal。最流行的解决方案会采用某些形式的hydration。在选择一个工具之前要注意使用的方法。

静态渲染

静态渲染在构建时发生，会提供一个很快的First Paint，First Contentful Paint， Time To Interactive - 假设客户端js是有限的。跟服务器端渲染区别之一是它会设法实现一个始终如一的快速的Time To First Byte，因为HTML页面不必动态生成。通常来说，静态渲染意味着会提前对每一个URL生成一个单独的HTML文件。由于预先生成了HTML的响应，所以静态渲染可以部署在多个CDN来用于边缘缓存。

静态渲染的解决方案多种多样，像Gatsby这样的工具，开发者会感觉他们的应用程序是动态渲染的，而不是作为构建时生成的。而像Jekly和Metalsmith则会拥抱他们的静态生态系统，提供更多模板驱动的方法。

静态渲染的缺点之一就是要为每一个可能的URL单独生成一个HTML文件，当你不能提前预知这些URL都有什么，或者网站有非常多的唯一页面的时候，这或许是一个挑战，又或者是不可能实现的。

React用户可能很熟悉Gatsby，Next.js，static export或者是Navi - 他们都使得作者使用组件变得很方便。然而，重要的是理解静态渲染和预渲染的不同点：静态渲染页面是可交互的，不需要执行太多的客户端的js，而预渲染则会提升单页应用的First Paint或者是First Contentful Paint，为了让页面变为真正的可交互其一定要在客户端启动。

如果你不确定给定的解决方案是静态渲染，还是预渲染，尝试下如下测试：禁用Javascript，加载已经创建好的页面。对于静态渲染页面，如果不启用Javascript，大部分功能依然存在。而对于预渲染页面，可能依然有一些基本的功能可以使用，比如说超链接，但是大部分页面将会是惰性的。

另一个有用的测试是使用Chrome DevTool降低你的网络带宽，观察页面变为可交互之前Javascript已经下载的数量。预渲染通常需要更多的Javascript来使页面变的可交互，并且Javascript要比静态渲染使用的渐进增强方法要更复杂。

服务器端渲染 vs 静态渲染

服务器端渲染并不是灵丹妙药 - 它的动态特性会带来明显的计算性能开销。许多服务器端渲染解决方案都不会提早刷新，可能会导致延迟TTFB或者是发送的数据量加倍。在React中，renderToString()可能是很慢的，因为它是同步并且是单线程的。要使得服务器渲染“正确”可能会涉及查找或者构建一个组件缓存的解决方案，管理内存消耗，等等。你通常会多次处理/重新构建相同的应用程序 - 一次在客户端，一次在服务器端。仅仅是因为服务器端渲染可以使某些东西更快显示，但并不是突然意味着会减少你的工作量。

服务器端渲染可以按需要为每个URL生成对应的HTML，但是它却慢于静态渲染的内容。如果你可以进行一些额外的工作，那么服务器端渲染 + HTML缓存可以极大的减少服务器渲染的时间。服务器端渲染的优点是有能力获取更多“实时”的数据并且返回比静态渲染更加完整的结果集，个性化的页面是服务器渲染的一个具体的事例，不过这种对于静态渲染来说，就不太适合了。

在构建PWA的时候，服务器端渲染也可以提出一些有有趣的决策。所以是全页server worker更好，还是用服务器渲染仅仅渲染单独的内容片段更好呢？

本文翻译自：

https://developers.google.com/web/updates/2019/02/rendering-on-the-web

本文转载自[http://www.lht.ren/article/13/](http://www.lht.ren/article/13/)