本文简朴引见了web运用种种衬着计划，个中包括客户端衬着、服务器端衬着等种种衬着计划。文章翻译自：
https://developers.google.com…。由我地点的团队配合翻译完成，并宣布在前端手艺民众号：
方凳雅集上，转载于此。方凳雅集是阿里CBU前端手艺专业号，有兴致的小伙伴可以关注一发。

1. 起航

作为开发人员，我们常常面对影响运用程序全部架构的决议计划。我们必需做出的中间决议计划之一是在什么地方完成营业逻辑和衬着逻辑。这可以很难题，由于有很多差别的要领来构建网站。对这个范畴的明白来自于过去几年我们在一些大型网站的事变。从广义上说，我们勉励开发人员选用带有rehydration（下一小节有诠释）的服务器端衬着或静态化衬着。为了更好明白我们在做决议时所挑选的架构，须要对每种要领和术语有充足的明白，经由历程差别衬着体式格局的页面机能可以协助我们明白它们之间的差别。

2. 术语

衬着：

SSR：服务器端衬着。

CSR：客户端衬着。

Rehydration：在服务器端衬着的dom树和数据的基本上，浏览器端应用JavaScript再次衬着。

Prerendering：在构建时天生静态HTML和页面的初始状况。

机能：
TTFB：Time to First Byte —— 浏览器发出资本要求到接受到资本第一个字节的时刻。
FP：First Paint —— 页面翻开到可视内容第一个像素衬着出来的时刻。
FCP：First Contentful Paint —— 页面翻开到页面重要内容可见的时刻。
TTI：Time To Interactive —— 页面翻开到变得可以交互的时刻。

这里只是简朴的引见了这些机能术语，想要细致的相识它们，可以看一下我们之前写的两篇文章机能优化篇——以用户为中间的目标（一）和机能优化篇——以用户为中间的目标（二）。

3. 服务器端衬着

服务器端衬着：翻开页面时服务器将完整的HTML天生好了并返回。这防备了在浏览器端取数然后衬着所发生的斲丧，由于这些事变已在服务器端响运用户之前就已做好了。

服务器端衬着会带来疾速的FP和FCP，在服务器端处置惩罚营业逻辑和衬着逻辑，可以防备向浏览器发送大批JavaScript，这有助于完成疾速的TTI，这类要领适用于种种装备和收集环境，假如你开启了一些流浏览器优化，比方文档采纳流的体式格局剖析（streaming document parsing）。

关于服务器端衬着，用户不太可以会去等浏览器实行其他的耗CPU的JavaScript代码实行终了再去操纵，由于页面内容已显现出来了。在第三方js没法防备时（广告），虽然服务器端衬着可以削减FP和FCP衬着的JavaScript斲丧，然则可以会给接下来要实行的js带来肯定的“累赘”。服务器端衬着的重要瑕玷在于，衬着须要斲丧时刻，所以可以TTFB会比较大。

服务器衬着是不是可以满足运用程序，很大程度上取决于您正在构建的体验范例。关于服务器衬着与客户端衬着的哪一个更好的争辩从未停过。然则我们须要记着的时，我们可以有挑选让一些页面举行服务器端衬着，其他页面运用客户端衬着。一些网站运用这类夹杂衬着情势就取得了不错的效果，比方Netflix对他的登录页面采纳了服务器端衬着，同时为重交互的页面预取js，为那些重交互而且客户端衬着的页面加速页面加载的时机。

很多当代框架、库和架构使得统一个运用同时在服务器端和浏览器端都能衬着成为可以。这些手艺虽然可以用于服务器端衬着，但须要注重的是，在服务器和客户端上举行衬着的体系结构具有异常差别的机能特征和衡量。React用户可以用它的renderToString要领或许其他基于该要领的框架举行服务器端衬着，比方Next.js; Vue用户可以去看它的服务器端衬着指南或许Nuxt; Angular用户可以去看Universal。

4. 静态化衬着

静态化衬着：在构建（build）时将页面中不会变化的内容直接衬着成出来，然后打到HTML中去。在浏览器端须要实行的js有限的假定下，该要领可以供应疾速的FP、FCP和TTI。与服务器端衬着差别，它还能供应疾速的TTFB，由于服务器端不须要天生HTML。平常而言，静态化衬着须要为每一个URL天生一个零丁的HTML，当用户接见的时刻，直接将预先衬着好的HTML返回就好。别的衬着出的HTML也可以布置到CDN上，经由历程edge caching（边沿缓存）缓存做一些优化。关于不相识edge caching的同砚，可以去看一下我们之前写的React缓存小记，内里有关于它的引见。

静态化衬着也有差别的计划，比方像Gatsby如许的东西旨在让开发人员觉得他们的运用程序是动态衬着的，而不是在构建历程当中发生静态的HTML；像Jekyl和Metalsmith如许的东西拥抱的静态特征，供应了很多模板驱动的要领。

静态化衬着须要为每一个URL天生零丁的HTML，这是它的一个瑕玷。假如您没法提早展望这些URL的内容，或许或一个网站存在大批的URL，静态化衬着多是不合适的。关于静态化衬着，React用户可以对Gatsby、Next.js的static export或许Navi比较熟习。

这里我们须要重点明白一下静态化衬着和预衬着之间的差别：静态化衬着的页面在浏览器端变得可以交互之前只须要实行很少的js代码，以至不须要；而预衬着虽然可以完成疾速的FP、FCP，但运用必需在浏览器端实行js代码才变得可交互。

假如您不能肯定究竟是运用静态化衬着照样预衬着，那就测试一下呗，在运用加载的时刻，制止JavaScript的加载和实行。制止JavaScript后，关于静态化衬着，页面的大多数功用照样可以平常运转；而关于预衬着，页面可以只要一些基本的功用可以事变，比方衔接跳转。

另一个有用的测试体式格局是经由历程Chrome的开发者东西DevTools减慢收集速率，视察在页面变成交互之前下载了若干JavaScript。预衬着平常须要更多的JavaScript，而且复杂度每每也比运用渐进加强的静态化衬着要高。

5. 服务器端衬着VS静态化衬着

服务器端衬着不是一颗银弹，它的动态特征会带来庞大的盘算开支。服务器端衬着会加大TTFB或发送双倍的数据（比方将客户端的State数据打到HTML中去），在React中，renderToString会很慢，由于它是同步而且单线程的。为了让服务器端衬着可以”正确“运转，我们须要关注组件缓存、内存斲丧、memoization手艺运用和其他题目。平常状况你可以须要屡次衬着统一个运用——一次在服务器端，一次在客户端。服务器端衬着只能让须要展现的内容显现的的更快，并没有削减事变量。

服务器端衬着可以依据差别的URL天生差别的内容，相较于静态化衬着，它的速率可以会慢一些。实在我们可以做一些事变来减缓这个题目，服务器衬着 + HTML缓存可以大大削减衬着时刻。服务器端衬着的上风在于它可以猎取及时数据，而且所能处置惩罚的要求集比静态化衬着要大。由于静态化衬着只能处置惩罚那些提早可以展望内容的页面，关于须要个性化的页面（千人千面），静态化衬着就没法处置惩罚了。

在构建PWA时，服务器端衬着也有用武之地，服务器端对页面片断举行衬着，前端运用Service Worker举行缓存。

6. 客户端衬着

客户端衬着：是指在浏览器中直接运用JavaScript来衬着页面，一切的逻辑、数据的猎取、模板和路由都是在客户端而不是服务器上处置惩罚的。

在挪动端，客户端衬着很难取得并坚持一个较快的衬着速率。偶然我们只须要做很少的事变，就能让客户端衬着的机能与服务器端衬着的机能相差无几，比方尽量的坚持小的JS体积和少的RTT（https://en.wikipedia.org/wiki…）。以至症结的剧本和数据假如运用HTTP/2的服务器端推送，或许运用<link rel=preload>，我们还可以让剖析事变更早最先。别的，像PRPL如许的手艺也可以协助我们加速页面的初始化及其后续导航。

但事变并非这么简朴。客户端衬着的重要题目是，所需的JavaScript会跟着运用程序的增进而增进。跟着新的JavaScript库、兼容组件和第三方代码的增加，掌握剧本的范围会变得分外难题——尤其是这些代码和库都常常都须要在页面内容衬着之前被加载。所以关于那些剧本范围很大的运用，应当优先斟酌运用代码拆分的计划。迥殊的，关于懒加载的JavaScript，要确保只在有须要时才加载必要的代码。而关于只要很少或许没有什么交互的运用，服务器衬着是一个可扩大性更好的计划。

假如你想构建SPA（单页）运用，运用app shell缓存页面中交互的中间组件会给你很大的协助。假如连系PWA的Service Work手艺，还可以有用进步页面反复接见时的机能。

7. 经由历程rehydration将服务器衬着和客户端衬着相连系

平常称为同构衬着或许直接简朴地称为”SSR”，这类体式格局尝试在客户端衬着和服务端衬着之间寻觅均衡，愿望可以削减二者的弊病。

页面导航致使跳转或革新时，服务器会输出页面的HTML文档，并把该页面所须要的javascript和（用于衬着的）数据内联到文档一同输出。假如完成妥当，这类体式格局确切可以像服务端衬着那样完成较快的初次内容绘制（First Contentful Paint），以后客户端会经由历程一种叫rehydration的手艺继承（在客户端）衬着。这是个新鲜的手艺，但它会引起比较大的机能题目。

运用reydration手艺举行服务端衬着的重要题目在于它会对可交互时刻（Time To Interactive）有显著的负面影响，尽管它缩短了初次绘制时刻（First Paint）。服务端衬着的页面每每让人觉得已加载终了并可以最先交互了，但实际上只要比及客户端的js剧本实行并完成DOM事宜绑定才响运用户的交互（比方用户的输入行动）。在一些手机终端，这个历程会消耗几秒以至几分钟的时刻。

或许你本身也经历过如许的场景：一个页面看起来已加载完成了，然则在页面实行点击或许轻触的行动，效果却什么也没发生。这很快变得使人懊丧……“为何(页面)没有反应？为何我不能转动？”

Rehydration题目：反复

Rehydration的题目不止于此，平常比因js致使的交互耽误更蹩脚。为了让客户端js可以正确地衬着，而不必从新向服务器要求衬着所需的数据，现在服务端衬着平常会把UI所需的数据序列化并内联到HTML文档的script标签里。终究的HTML文档包括了更高层面的反复:

可以看到，关于页面导航要求，服务器会返回了响应的UI形貌（HTML），但它一样返回了衬着UI所需的数据。同时，客户端剧本一样包括了UI的形貌（译者注：前端衬着须要包括对UI的形貌，比方JSX），以便在客户端继承衬着。只要当bundle.js完成下载和实行后，UI才进入可交互状况。

从运用rehydration计划的一些实在网站汇集到的机能数据来看，该计划是极端不引荐的。究其原因，照样回到用户体验上：这类体式格局很轻易让用户停留在“神奇的峡谷”当中。（译者注：即界面可见但不可交互的状况）

尽管如此，外界对rehydration计划照样有些许期待的。简朴来讲，运用服务端衬着时，只对须要高度缓存的内容才会下降首字节时刻（TTFB），获得和预衬着（prerendering）相似的效果。

在将来，rehydtration计划可以会逐渐地、或许部份地被运用，并成为服务端衬着的症结。

8. 流式服务端衬着和渐进式Rehydration

服务端衬着在过去几年中有了长足的希望。

流式服务端衬着许可你以块的情势发送HTML，同时浏览器端吸收并一一衬着，这类计划可以完成疾速的FP和FCP。React供应了一个异步的、以流的体式格局传输的体式格局 renderToNodeStream，与同步的renderToString比拟，它可以更好处置惩罚服务器压力。

渐进式Rehydration也值得关注，React团队正在做一些风趣的探究（https://github.com/facebook/r…）。运用这类要领，服务器衬着跟着时刻的推移被“启动”去衬着运用的各个片断，而不是当前一次性衬着全部运用。这可以协助削减使页面交互所需的JavaScript，由于如许可以耽误页面中低优先级展现内容的衬着（比方非首屏的内容），同时可以防备这些低优先级的衬着壅塞主线程。而且，这类计划也能防备带Rehydration的服务端衬着的一个很大的圈套：服务端衬着天生的DOM树在浏览器端被烧毁然后被重修，这个题目大多数是由于同步的客户端衬着天生DOM树所须要的初始数据还没准备好。

部份Rehydration

部份rehydration被证实难以完成。这个计划是渐进式Rehydration的一个扩大，须要分析出互相自力的片断（组件/视图/树）中哪些具有少少交互或许完整没有交互的部份举行渐进式rehydrated。关于这些近乎静态的部份，响应JavaScript代码会被改形成惰性的援用，从而将它们对客户端的影响下降到近乎为0。部份hydration为缓存带来了肯定应战，客户端导航意味着我们不能假定运用程序的惰性部份即服务器衬着天生的HTML是可用的，除非页面完整加载完。

Trisomorphic衬着
假如Service Worker是你的一个选项，“trisomorphic”衬着也是一个风趣的点子。应用这项手艺，你可以应用流式服务端衬着天生初始的或不依赖JS的部份，然后在Service Worker install后应用它衬着天生html。这类计划能使缓存的组件和模板坚持及时而且还支撑SPA范例的运用，在统一会话中依据差别的导航衬着差别的视图。这类要领在服务器端、客户端和Service Worker中可以复用模板和路由代码。

9. SEO

在挑选在衬着计划，平常会斟酌SEO。平常我们会挑选服务器衬着来应对爬虫。爬虫可以能明白JavaScript，然则它们有很多局限性，我们须要重点关注一下他们是怎样衬着的。虽然客户端衬着可以事变，然则平常都没有做测试等事变，假如您的运用依赖于客户端衬着，动态衬着是您值得斟酌的一个选项，详细可以参考https://developers.google.com…。

假如有疑问，Mobile Friendly Test可以测试您挑选的要领是不是相符预期，它可以显现页面在爬虫中的显现体式格局、序列化的HTML内容（JavaScript实行以后）以及衬着历程当中涌现的任何毛病。

Mobile Friendly Test地点以下：
https://search.google.com/tes…

10. 总结

当决议用什么体式格局衬着的时刻，要知道我们行将碰到的瓶颈是什么。采纳客户端衬着照样服务端衬着将决议你90%的架构设想。一个圆满的解决计划平常服务端发送html跟最小的js来完成交互。以下是服务端-客户端衬着的一个总结图：