javascript渲染单页效率简述

蔚落 2022-09-22 15:56 85阅读 0赞

浏览器渲染过程，其实大家也大概都了解过：

![Image 1][]

浏览器通过网络请求加载页面资源，在页面呈现之前无论如何都要经历以下过程：

1.  HTML→DOM
2.  CSS→CSSOM
3.  DOM + CSSOM → Render Tree
4.  对Render Tree进行布局计算(Layout)
5.  对布局结果进行屏幕绘制(Paint)

如果在JS渲染页面模式下，需要在前端用JS加载样式并组装数据生成HTML插入页面，以上浏览器渲染过程必须等到页面加载完CSS，并且JS加载完数据拼装好HTML之后才能开始进行，一般的网络时序如下：

![Image 1][]

大概阐述一下这个流程：

1.  浏览器发起请求加载主文档
2.  服务端响应一个基本骨架的主文档
3.  浏览器加载主文档中外链的loader.js（根据路由控制资源加载的）
4.  服务端响应loader.js
5.  loader.js执行，根据页面url判断用户访问到哪个虚拟页面，然后再发起请求加载对应页面的js和css
6.  页面所需JS和CSS都加载完毕，JS执行，发起请求加载数据
7.  数据加载完毕，JS执行前端模板拼装，插入DOM节点，然后浏览器开始前述渲染过程
8.  最终页面呈现

概括一下，加载时序大概是这样的：

![Image 1][]

以上加载过程均为串行，需要至少多付出3次RTT。如果把这种架构应用在高延迟的网络环境下（比如移动2G），那就是找死啊（其实国内现在的网络环境很好了，这样搞问题或许不太明显）。

当然，上面的例子还是常规了一些，有些请求可以适当合并，进一步优化之后，大概可以搞成这个样子：

![Image 1][]

就是首次请求的主文档尽量多内嵌一些东西，除了HTML骨架之外，把loader.js内嵌，再加一个loading界面，让用户觉得没那么长时间白屏，另外如果前端路由切换是pusState控制的话，可以在服务端知道前端路由url，然后在主文档中直接内嵌数据，主文档体积大了不少，但是可以减少2次RTT，优化对比：

![Image 1][]

当然，如果你的单页面应用体量很小，完全不用按需加载，主文档内嵌一切可以再减少一次RTT，得到：

![Image 1][]

不过这么极端的做法其限制就是：你的应用千万不能太大！

前端渲染模式我厂的代表产品：UC奇趣百科 ，其优化点：

*  主文档loader.js内嵌、数据内嵌、loading界面内嵌
 *  页面资源按需加载，请求动态合并
 *  localstorage存储JS/CSS

在国内的网络环境下感觉还OK吧。。。

## 兼顾性能、兼顾SEO，还是单页面应用，是可以做到的！ ##

很明显，前端JS渲染由于违背了浏览器的优化策略，总是存在一个不可突破的瓶颈：

> JS和数据没加载完，JS拼装数据的逻辑没执行完，浏览器不能开始正常的渲染流程。

这个性能差异我感觉短时间内这种JS渲染的webapp是无法跟传统页面输出模式相比较的，因为浏览器的各种渲染优化策略基本上都是围绕着传统页面时序展开的。有没有办法突破这个性能瓶颈，并且兼顾SEO，但还保留单页面应用的体验呢？

答案是：有办法。