devpoint.cn

每次访问网站时，浏览器都需要呈现该网站，以便以吸引人的方式呈现并提供所需的交互级别。然而，根据 Web 项目的编程方法，动态脚本和静态代码的处理方式可能大相径庭。目前有三种主要方法：服务器端渲染（SSR）、客户端渲染（CSR）和静态站点生成（SSG）。

服务器端渲染（SSR）

SSR（Server Side Rendering）即服务器端渲染，字面意思就是渲染在服务器端。是一种用于开发具有动态元素和 Web 应用程序的网站的技术。它基于脚本的使用，当通过浏览器请求相应的内容时（在浏览器请求页面URL的时候），服务端将需要的HTML文本组装好，并返回给浏览器，这个HTML文本被浏览器解析之后，不需要经过 JavaScript 脚本的执行，即可直接构建出希望的 DOM 树并展示到页面中。这个服务端组装HTML的过程，叫做服务端渲染。

这些脚本由 Web 服务器使用适当的脚本语言执行。通过初始请求，所有 HTML、CSS 和 JavaScript 都已完全加载，无需等待任何 JavaScript 或 CSS 文件加载。这意味着访问网站的用户将能够比在等待 JavaScript 文件加载时只是看着空白屏幕更快地看到所有内容。

如果做得好，SSR 可以极大地提高性能，因为它能够在将内容发送到客户端之前呈现内容。它还通过比在页面加载后发送页面内容更早地发送页面内容来减少页面加载时间并改进 SEO。

服务器端渲染（SSR）的优点

与客户端的单页应用 (SPA) 相比，SSR 的优势主要在于：

• 更快的首屏加载：这一点在慢网速或者运行缓慢的设备上尤为重要。服务端渲染的 HTML 无需等到所有的 JavaScript 都下载并执行完成之后才显示，所以用户将会更快地看到完整渲染的页面。除此之外，数据获取过程在首次访问时在服务端完成，相比于从客户端获取，可能有更快的数据库连接。这通常可以带来更高的核心 Web 指标评分、更好的用户体验，而对于那些首屏加载速度与转化率直接相关的应用来说，这点可能至关重要。
• 统一的心智模型：可以使用相同的语言以及相同的声明式、面向组件的心智模型来开发整个应用，而不需要在后端模板系统和前端框架之间来回切换。
• SEO更友好：搜索引擎爬虫可以直接看到完全渲染的页面。

截至目前，Google 和 Bing 可以很好地对同步 JavaScript 应用进行索引。这里的“同步”是关键词。如果应用以一个 loading 动画开始，然后通过 Ajax 获取内容，爬虫并不会等到内容加载完成再抓取。也就是说，如果 SEO 对页面至关重要，而内容又是异步获取的，那么 SSR 可能是必需的。

使用 SSR 时还有一些权衡之处需要考量：

• 开发中的限制：浏览器端特定的代码只能在某些生命周期钩子中使用；一些外部库可能需要特殊处理才能在服务端渲染的应用中运行。
• 更多的与构建配置和部署相关的要求：服务端渲染的应用需要一个能让 Node.js 服务器运行的环境，不像完全静态的 SPA 那样可以部署在任意的静态文件服务器上。
• 更高的服务端负载：在 Node.js 中渲染一个完整的应用要比仅仅托管静态文件更加占用 CPU 资源，因此如果你预期有高流量，请为相应的服务器负载做好准备，并采用合理的缓存策略。

在应用使用 SSR 之前，首先应该问自己是否真的需要它。这主要取决于首屏加载速度对应用的重要程度。例如，如果正在开发一个内部的管理面板，初始加载时的那额外几百毫秒并不重要，这种情况下使用 SSR 就没有太多必要了。然而，在内容展示速度极其重要的场景下，SSR 可以尽可能地帮你实现最优的初始加载性能。

服务器端渲染缺点

服务器端脚本要求服务器为每个请求提供预加载的 HTML 页面。特别在客户端不断向 Web 服务器发送更多请求以向用户提供新的、修改过的信息时服务器容量的负载就会很重。因此，SSR 不适合请求量大或需要大量用户交互的网站，在此类项目中，Web 服务器的响应时间会抵消优化页面加载速度的优势。

服务器端渲染框架和语言

服务器端呈现框架是帮助在服务器上呈现网页的过程的工具。客户端渲染由浏览器或 JavaScript 库完成，而服务器端渲染由服务器完成。有许多框架可用于这些任务，比较流行的框架包括：

• Vue.js ：是一个用于构建用户界面的开源 JavaScript 框架，可以与其他框架结合使用，为开发 Web 应用程序提供完整的堆栈解决方案。
• React.js：一个 JavaScript 库，可让创建可重用的 UI 组件并使用 Flux 或 Redux 轻松组合它们，以使用函数式编程概念构建具有高可扩展性的大型应用程序。
• Ember.js：用于在 JavaScript 中构建 Web 应用程序的完整框架，它使用约定优于配置并为常见问题（例如路由和模板）提供默认解决方案。
• Angular：有服务器端渲染工具，称为 Angular Universal。

服务器端渲染的典型编程语言包括：

• Java
• Ruby
• ASP.NET
• Perl
• PHP
• Python
• Node.js or JavaScript

客户端渲染（CSR）

客户端渲染（CSR）技术主要由 Web 开发人员用来实现具有动态内容的项目。在这种情况下，编写的脚本不是由服务器执行和处理的，而是由访问浏览器执行和处理的。为此，脚本要么嵌入到 HTML 或 XHTML 文档中，要么写入链接到文档的单独文件中。

当用户访问带有客户端脚本的网页时，Web 服务器将 HTML 文档和脚本发送到浏览器，浏览器自行执行并显示最终结果。客户端脚本还可以包含有关 Web 浏览器应如何对用户的某些操作做出反应的具体说明。通常，客户端不需要重新建立与 Web 服务器的通讯来执行此操作。

最重要的客户端脚本语言是JavaScript。

理论上，任何的脚本语言都可以用于客户端渲染。然而，为了让项目以后能够被所有不同的用户组加载，所有相关的浏览器也必须支持它们——目前只有 JavaScript 拥有这种状态。

客户端渲染（CSR）的优点

客户端渲染（CSR）被证明是一种有利可图的方法，特别是对于具有大量用户交互的 Web 项目。如果网站最初加载速度较慢，则后续页面的渲染速度会更快。用户体验明显优于服务器端渲染，因为用户每次访问新页面时不必立即完全加载所有脚本和内容。

由于脚本是在用户的浏览器中执行的，因此与服务器端脚本不同，可以被查看源代码，通常涉及加密等安全性的功能就不太适合客户端来实现，。

客户端渲染（CSR）的缺点

对客户端脚本的关注伴随着两个关键问题。首先，搜索引擎很难对页面进行抓取和索引。谷歌的爬虫能够做到这一点，即使 SEO 条件不是最佳的 - 特别是因为许多其他搜索引擎通常根本无法索引客户端呈现的页面。

另一方面，客户端脚本需要浏览器支持 JavaScript。基本上就是这种情况 - 但由于弹出窗口和跟踪工具也基于 CSR，并且客户端脚本也会影响加载时间，因此有各种浏览器扩展程序会阻止脚本。

静态站点生成（SSG）

过去几年的趋势表明，网站在设计方面越来越类似于应用程序。高度的响应性和交互性与范围广泛的内容一样重要。用户期望快速的加载时间和无缝的用户体验，例如，页面不必总是从头开始加载。同时，网站运营商不应忘记SEO的重要性，也应尽一切可能在搜索引擎获得良好的排名。

在静态站点生成器的帮助下，创建使用模板的 HTML 页面，因此它们可以在客户端启动请求时随时显示。与服务器端呈现不同，SSG 呈现提前发生（在客户端请求之前），这使页面加载时间尽可能短。

流行的静态站点生成器包括以下内容：

• Jekyll
• Hugo
• Next
• Gatsby
• Gridsome
• Nuxt
• Hexo
• Eleventy
• Jigsaw
• Vuepress

静态站点生成（SSG）优势

静态站点生成（SSG）生成在包含大量不定期更改内容的项目中特别有用。典型的例子包括个人网站或博客，它们通常携带很少的动态内容，并且由于静态站点生成器的预呈现（即页面预加载）而从快速加载中受益匪浅。此外，SSG 项目安全性相对比较高，因为提供的攻击选项很少，因为潜在风险仅限于加载客户端页面时的单击。

静态站点生成（SSG）缺点

当 Web 项目需要定期更改时（无论是技术性质还是内容），这种方法被证明是极其不切实际的。对于每次更改，Web 项目的静态页面都必须再次预加载。项目越大，这个构建过程花费的时间就越多，使得静态站点生成不适合具有大量静态页面的网站。

总结

服务器端渲染（SSR）可确保出色的页面加载速度，尽管这需要大量 Web 服务器的容量。客户端渲染（CSR）恰恰相反，实际上通过首先在浏览器中呈现大部分页面来减轻服务器的负担（前提是用户没有阻止 JavaScript）。静态站点生成（SSG）可以节省服务器和客户端，并且由于采用了预呈现方法，可以确保内容的快速交付，前提是它不是交互式的并且不断变化，并且适合采用缓存和CDN。