04-为什么在服务器上渲染

12.2　为什么在服务器上渲染

为什么要做SSR呢？基于使用的情况，可能会有一些非常有说服力的理由。例如，有一些坊间证据表明，服务器端渲染的应用在被搜索引擎索引和爬取时表现得更好。虽然像谷歌这样的大型搜索引擎似乎可以在服务器上执行或至少模拟JavaScript和DOM，但似乎那些不使用DOM呈现动态内容的站点表现得更好。很难确定SSR和非SSR应用对搜索引擎优化（SEO）的确切影响，因为谷歌和其他公司的网站排名算法都是严格保密的，但至少有来自业内人士和团队的坊间证据表明SSR可以产生积极的影响。因此，如果有一个非常依赖在搜索引擎结果中进行展示的高度公开的应用程序，那么除了其他所有SEO优化，还可以考虑使用SSR来提升爬虫程序的友好度。

本书中，我们一直在开发一款需要交互并允许用户动态创建内容的应用程序，但并不是每个应用都有这些要求。如果只想要React的静态方面，那么可以很轻松地使用React-DOM的静态渲染功能来创建静态页面生成器或模板库。

优化用户体验可能是需要在服务器上渲染的另一个原因。如果应用程序需要尽可能快地向用户显示内容，那么在服务器上渲染可能比等待客户端渲染更快。例如，当应用程序很大程度上依赖于向用户显示广告或其他静态付费内容，并且资源不是很大时，就是一个典型场景。如果希望在不带交互的情况下快速显示内容，那么可能会更关心“白屏时间”，即用户第一次能够在浏览器中看到内容所用的时间。

白屏时间是可以用来判断浏览器渲染应用程序的性能的众多指标之一。另一个指标是感知速度指数（通常仅为速度指数）^[1]，它是通过记录页面在一段时间内完成了多少渲染量来计算的。浏览器会在页面加载时录制视频并确定在给定的时间间隔内页面加载的百分比。这个指标总体上对于理解给定页面相对于用户的加载速度非常有用。SSR通过在加载过程的早期让网站有更多东西可以被浏览器渲染来潜在加快感知速度。

大部分应用程序会从更快的感知速度和更短的白屏时间中获益。但在其他情况下，开发者可能对尽快向用户显示内容这件事不太关心，他们更希望让用户尽快使用应用程序。如果应用程序是高度交互的富应用，如Basecamp或Asana，那么可交互时间（time to interactive，TTI）（直到用户能够与应用或页面进行交互所花费的时间）可能更为重要。对于这些应用程序，SSR可能没有意义，因为它们不是公开访问的，而且与快速向用户展示内容相比它们更依赖交互。

让我们通过几个应用程序来了解如何将TTI纳入进来。

• Basecamp（项目管理应用）：用户希望能搜索问题，更新待办事项，查看项目状态。这种情况下，会想要优化应用让其尽可能快地加载JavaScript文件而不是尽快向用户展现内容。
• Medium（博客/写作应用）：用户想要尽可能快地阅读和浏览文章。这些功能并不取决于应用的交互性，所以这种情况下我们会想要优化白屏时间。

考虑SSR时，可能还需要权衡服务器端渲染和客户端渲染的资源使用。如果正在渲染大量数据（可能是一个数千行的在线电子表格），在服务器上渲染可能需要向浏览器发送更大的初始荷载。依次地，这可能意味着更长的TTI，更长的TTI可能会妨碍用户的使用，并且可能使用更多的服务器资源。但假如在应用程序加载后获取相同信息量的JSON格式数据可能带来更小的荷载并获得更好的用户体验。

企业级应用与消费级应用中的服务器端渲染

你可能会觉得我们在本章对服务器端渲染的讨论只是永远不会用到的理论上的东西。但我相信你会发现服务器端渲染比想象中更为普遍，并且是很多团队会切实考虑的一个选项。从我自己的经历和我遇到的其他工程师的经历来看，这一点确实是正确性的。我曾经做过面向公众的消费级产品和封闭的企业级应用，并有机会看到在不同业务场景中考虑服务器端渲染。在这两种情况中，我们都希望为用户做到最好，并将服务器端渲染作为一种选择。

在企业级应用中，我们应对的用户希望尽可能快地与应用交互，而不只是快速渲染。我们还必须提供可能包含数百甚至数千行金融数据的页面（这可能会抵消服务器端渲染所获得的收益）。应用程序由几个较小的应用程序组成，我们基于给定时间在使用哪个应用来提供不同的JavaScript包。然而，让问题变得更复杂的是，数据完整性和安全性是我们最为关心的问题，所以服务器端渲染可能会引入一个从安全角度进行防护和评估的新领域。

这些因素使服务器端渲染“值得拥有”，这在它被重新计算时可以节省一些未来的时间。我们发现还可以做些其他事情来帮助用户，如提高服务器性能，优化应用资源服务，以及将客户端的数据获取延迟到只在需要时进行。有趣的是，人们对不同类型的应用有着不同的期望。类似Facebook、Twitter和Amazon这样的消费级应用都在争夺用户，这些用户有着非常多的选择，因此这类应用会在许多方面与其他应用直接竞争。根据我的经验，企业用户对他们在工作中使用的应用程序的期望往往略有不同。速度当然非常重要，但稳定性、可靠性、明确性和其他重要方面对企业级应用来说也同样重要。因此，对工程团队来说，在这些维度上进行优化而不是花费同样的时间优化一个影响较小的指标是合理的。当然，情况并非总是如此，但从我参与的一些项目来看确实是这样的。

我参与的一些其他项目的需求却大不相同。其中一个应用来自电子商务领域。因为白屏时间和SEO的考量对其极为重要，所以服务器端渲染就非常有意义了。我们努力减小资源包的大小并尽可能快地向用户显示内容。任何迟缓的表现都有可能阻止用户继续购物。这些应用程序也与营销工作紧密结合，因此确保SEO的稳定性能是重中之重。

还有一些其他的案例可以应用服务器端渲染，但我希望这两个简单的例子能帮助我们理解本章讨论的内容的实用性。

开发人员大可不必在SSR实现上孤注一掷。如果必须渲染一个几千行的电子表单，应该让客户端来进行这方面的渲染，而在服务器上渲染注册和登录页面可能更有意义，因为这些页面更小，更依赖于白屏时间而不是及时可交互性。开发人员还可以选择在服务器上渲染页面的某些部分，但允许客户端来处理所有未来的数据获取和渲染。如果有兴趣了解更多关于Web性能的知识，最好从谷歌的Web基础指南开始。