共计 2897 个字符，预计需要花费 8 分钟才能阅读完成。
咱们晓得，用户体验是 Web 产品最为重要的局部。尽可能减少首屏加载工夫，更为流畅地展现用户所需要的内容，会是用户是否留存的关键因素。
而随着古代 Web 业务可供用户的交互行为越来越多，前端我的项目的复杂度越来越高，每个页面的渲染工夫也必然越来越长，这就导致了用户的体验不佳，用户的操作变慢。
为此，前端工程师们在首屏申请的各个阶段中继续钻研，一直探索如何将首次页面渲染的工夫缩小到更小，力求提供更为优良的产品体验。
CSR（Client Side Render）
浏览器渲染是最简略，最合乎 Web 利用设计思路的渲染形式。
所谓浏览器渲染，就是将利用所需的页面展现、前端逻辑、接口申请全都在用户的浏览器中执行。它很好的实现了前后端的解耦，让前端开发更为独立，也让后盾实现更为简略。
同时，为了缓解用户的期待焦虑，咱们能够用 loading 态，或者骨架屏，进一步晋升异步申请接口时的用户体验。
不过，随着业务复杂程度进步，浏览器渲染的开销也会变大，咱们无法控制用户侧应用的机器性能，很多时候，用户应用的机器性能甚至不足以满足利用的需要，造成卡顿，甚至解体，这一点在挪动端上尤甚。
而浏览器渲染因为前端的动态性过高，也会带来 SEO 不佳的问题。
SSR（Server Side Render）
服务端渲染的呈现工夫实际上是要比浏览器渲染要更早的。在 Web 利用倒退的晚期，所有的 ASP、JSP 等模板引擎构建的前端页面实际上就是服务端渲染的后果。而此时的服务端渲染无奈进行前后端职责的解耦，因而逐渐被浏览器渲染淘汰。
但在解决首屏体验的问题上，服务端渲染有着独到的劣势。它能提前再服务端中实现页面模板的数据填充，从而一次性返回残缺的首屏内容，从而面对 SEO 的爬取时能获取到更多无效的要害信息。
此外，因为其能疾速直出首页的实在数据，体验往往比 loading 态更佳，在 TTI 的体现上更为杰出。
然而，服务端渲染也有其本身的局限性。因为从实质上来说，SSR 服务无奈齐全与前端页面解耦开来。因而市面上较齐备的 SSR 解决方案都只解决首屏的服务端渲染，并采纳同构的形式，减少一层 node 中间层的形式来解决前端与 SSR 服务的更新同步问题，并与后端开发我的项目解耦。
但这无疑减少了我的项目的复杂度，并且随着业务的复杂程度变高，服务端渲染往往须要调起多个接口去申请数据并填充页面，这样可能会导致在 TTFB 上有肯定劣势。
当然，最重要的是，服务端渲染对于服务器的负载要求是很高的。
上图是援用的字节的某我的项目的 SSR 服务的单机 QPS 承载体现。咱们能够看出，对于一个高访问量的网页利用来说，提供一个较为简单的 SSR 服务的老本是相当高的，须要破费大量的金钱来堆机器。
因而，从降本增效的角度思考，咱们须要评估 SSR 带来的 ROI 是否合乎预期。
NSR（Native Side Render）
在挪动互联网的浪潮下，挪动端机能飞速晋升，那么 Web 利用是否能搭上这一班车，将 Native 的性能利用起来，晋升页面渲染性能呢？答案是必定的，这就须要介绍到 NSR 了。
Native 渲染的实质其实还是 SSR，只不过提供服务的 Server 转变为了客户端。因为须要用到客户端机能，因而此种实现通常利用在挪动端 APP，或者 PWA 下。
当链接被点击时，先借助浏览器启用一个 JS 运行时，并加载 APP 中存储的 Html 模板，发送 xhr 申请预加载页面数据，从而在客户端本地拼接并渲染生成一个有数据的 Html 首屏，造成首次 NSR。同时能够将该首屏 Html 缓存在客户端，供下次页面关上时，实现 stale-while-revalidate 的缓存成果。
因为 NSR 将服务器的渲染工作放在了客户端的一个个独立设施中，既实现了页面的预加载，同时又不会减少额定的服务器压力。达到秒看的成果。
这种能力在领有客户端或者反对 PWA 的利用中利用宽泛，例如手 Q，腾讯文档 APP 中都领有通过 APP 中的离线包来实现首屏渲染减速的能力。
ESR（Edge Side Render）
那么，对于纯 Web 利用，而又因为兼容性等起因临时无奈反对 PWA 的页面，有没有一个适合的首屏渲染减速计划呢？
随着云与边缘计算的疾速倒退，前端页面也须要思考分布式的申请解决优化。
咱们晓得，CDN 节点相比实在服务节点更贴近用户，能更快将内容返回。因而咱们能够将动态的 Html 内容模板缓存在 CDN 上。当接到申请时，先疾速将动态模板页面返回给用户，同时在 CDN 服务器上对页面动静局部发动向后端发动申请，并将获取到的动静内容在以流式下发的形式持续返回给用户。
这里实际上利用到了 HTTP 的 SSE（Server Send Events）协定，通过服务器向客户端发送单向事件流，实现同一个 Html 文件的分块传输预渲染。
最佳实际是？
这也是咱们最近在腾讯文档中摸索实际并落地的，通过服务两头节点的流式下发能力，实现多级首屏渲染减速。
对于一个简单前端页面来说，首屏须要加载和运算的资源类型可能有很多，有须要客户端解析并执行的 JS 动效，也有须要服务端获取数据直出的数据分片展现页面。
通常来说，客户端只能期待服务端获取分片数据，并生成通过 SSR 渲染后的 HTML，能力开始进行 script 解析与 js 资源拉取的行为，最终渲染出残缺的页面数据以及动效。
而既然他们所须要的计算形式不同，那么为什么不能并行来做呢？
咱们能够在版本公布前，将未通过服务端直出的模板 HTML 进行解析，将须要发动资源申请的所有的外链脚本 url 提取进去，生成一个 HTML Header 构造，并将该 Header 内容假装为失常 HTML 缓存在 CDN 节点中。
联合之前咱们介绍的 HTTP SSE 协定，当用户申请时，咱们能够以最快的速度向用户返回 CDN 中的 HTML header，从而让用户的浏览器提前拉取并解析外链资源。于此同时，CDN 节点将用户的申请转发给实在的服务端，从而让服务端进行实在数据的获取拼接并返回给客户端。
因为客户端此时曾经提前拉取了外链资源，因而收到服务端分片的 SSR 后，客户端能够间接将实在数据渲染到页面中，而不须要再次期待外链资源的解析。
因为并行的关系，这样的 SSR 与 NSR 混合形式能大大降低简单页面首屏渲染的工夫，晋升用户体验。
以百度首页的申请为例，通过 Chorme Network 提供的瀑布图，通过咱们能够直观的看到一条申请的执行过程。
咱们能够看出，除了 DNS 寻址与 SSL 建连是咱们无法控制的以外，占用申请工夫的大头是 Waiting for server response，申请服务器 (CDN) 的工夫，以及 Content Download，外链资源的拉取工夫。
而应用本文的混合计划后，实践上能够使总申请工夫升高到 Max(A, B), (A 为 Waiting for server response，B 为 Content Download) 的程度。（当然，实际操作过程中，因为 CDN 节点进行了一次申请转发，因而领有 SSR 能力的页面申请返回工夫会更长一些）。
结语
前端的页面首屏工夫优化是永恒的话题，本文介绍了前端界对首屏工夫优化的过程，并提供了一种 SSR 与 NSR 混合的新思路，通过并行处理耗时工作的形式，进一步晋升首屏加载工夫，心愿可能给大家提供一点参考价值。
