为什么服务器端HTML渲染比客户端快？

Question

我正在开发一个大型网站，我们正在将许多功能移至客户端 (使用 Require.js、Backbone 和 Handlebars 技术栈)。甚至有讨论将所有渲染都移到客户端。

但是阅读一些文章后，尤其是有关 Twitter 移动到非客户端渲染的文章，提到服务器端更快/更可靠，我开始有疑问。我不明白如何在双核 CPU 和 4-8 GB RAM 上用 JSON 和模板从 JS 中渲染出相当简单的 HTML 小部件比在服务器端应用程序中包含数十个文件更慢。是否有任何实际的基准数据呢？

此外，似乎通过服务器端模板引擎解析 HTML 模板无法比从 Handlebars 模板中渲染相同的 HTML 代码更快，特别是如果这是预编译的 JS 函数？

- mvbl fst

---

我猜测DOM操作比字符串操作慢。你能链接一些相关文章吗？ - Blender

请看这篇文章：http://code-inside.de/blog-in/2012/07/06/client-side-vs-server-side-html-rendering/，它讨论了客户端和服务器端 HTML 渲染的不同之处。 - mvbl fst

Answer 1

有很多原因：

1. JavaScript是解释性语言，比服务器端（通常使用编译语言）慢。
2. DOM操作速度较慢，如果您在JS中进行操作，则会导致性能不佳。有一些方法可以克服这个问题，例如在文本中准备渲染，然后再进行评估，这样可能会使您接近服务器端渲染。
3. 一些浏览器太慢了，特别是旧版IE。

- albattran

---

我不会太担心旧版的IE浏览器。我们不支持IE8以下的版本。而且我也不会担心那些使用速度较慢的机器和网络连接的少数用户。我很好奇在同一台机器上，同一款浏览器下，加载HTML和加载JSON并在客户端渲染之间的性能差距有多大。我猜我只需要设置一些测试就可以了。 - mvbl fst

根据您进行的DOM操作和JavaScript操作的数量而定。例如，如果您要插入一千个DOM元素，则您的脚本可能需要花费几秒钟才能呈现，而对同一千个DOM元素进行一次评估（服务器呈现或文本）只需要毫秒级别的时间。这些数字仅用于展示差异，实际数字取决于您的页面、机器性能和浏览器。 - albattran

Answer 2

• 编译语言的性能与解释JavaScript的性能相比
• 缓存，即提供已经被其他用户请求过的完全相同的页面，这消除了每个客户端的渲染需求。对于拥有大量流量的网站（如新闻网站）非常有用。微缓存甚至可以提供接近实时的更新，并从缓存中为重要的流量提供服务。无需等待客户端渲染。
• 减少对旧计算机或慢/受限制的浏览器用户的依赖
• 只需要关注渲染，不太依赖不同浏览器管理DOM的方式（可靠性）

但是，对于复杂的UI，客户端渲染交互将提供更快速的用户体验。

这真的取决于您想优化的性能以及有多少用户。

- Pete - MSFT

---

该网站非常庞大（不确定用户数量，但它托管在60多个服务器上）。大部分内容都是个性化的。这是一个大型协作和项目管理应用程序。 - mvbl fst

考虑到协作和项目管理，我会选择在客户端进行脚本渲染。互动性需要快速响应，因此您无论如何都需要使用js。 - Pete - MSFT

Answer 3

要在客户端运行代码，首先必须加载它。服务器端代码只有在服务器启动时才会加载，而客户端代码必须在每次页面加载时可能需要重新加载。无论如何，在加载页面时都必须解释代码，即使文件已经被缓存。您还可以在浏览器中缓存JS解析树，但我认为这些不会持久存在，因此它们的寿命不长。

这意味着无论JavaScript有多快（它非常快），用户等待时都必须执行工作。许多研究表明，页面加载时间极大地影响用户对网站质量和相关性的感知。

重点是，在典型的开发环境中，您最多有500ms的时间从干净的缓存中渲染页面。更慢的设备和网络将使该延迟仅仅被大多数用户接受。

因此，在页面加载期间，您可能有50-100ms的时间来进行JavaScript操作，总共，这意味着呈现复杂页面并不容易。

- Henrik Vendelbo