细数现阶段业内首屏优化方案，主要有：SSR、Prerender、CSR等方案，这些方案的思路几乎都在于将渲染过程放到传统SPA用户端渲染之前，而传统性能优化手段在SPA项目上面收获甚微，原因在于SPA本身的致命缺陷：
SPA方案
在SPA项目的首屏性能上，我们在长期关注和不断探索，期间我们尝试过很多方案，包括：
从减少代码体积角度的：webpack优化、打包优化、tree-shaking等
从减少HTTP请求角度的：接口合并、按需加载、延时加载等各种方法减少请求
从缓存角度出发：离线包、http&浏览器各种缓存使用、dns预解析、dll方案、接口缓存方案等
从数据获取时机角度出发：webWorker预取数据、路由进入过程读取数据等
从减少图片体积和数量出发：使用webp图片、请求域名并行优化、CSS Sprite等
这些方案都能一定程度上降低白屏时间和首屏时间，但收效有限，很难像SSR方案一样大幅降低数据，究其原因，SPA页面渲染过程如下：
从上图可以看到，白屏过程几乎是不可避免的，因为无论如何你去优化代码体积，Vue系列类库和你需要的其他核心类库文件加起来至少有几百K，在加上这些文件执行的时间（实测至少500ms），可能大多数情况，我们白屏时间至少1200ms-1500ms了。
当然，我们可以把骨架屏所需的css放到HTML里面，能尽早的显示出骨架屏（但很多低版本内核需下载&执行完全部script后才会渲染页面），但这并非真正的首屏，即使在性能统计上，也无法直观反馈出首屏的提升。
于是SSR方案成为我们的救命稻草：
SSR方案
我们再看下SSR如何解决这个问题：
SSR方案的优势在于，浏览器下载的HTML当中已经具备了首屏渲染所需的DOM结构和样式，白屏时间几乎等于HTML文件下载时间，而这个时间相比SPA已经很少了，性能数据有显著提升。
那为什么我们不直接用SSR方案呢？
主要原因有四点：
1、SSR项目改造成本高
Vue技术栈的SSR方案主流有两种：官方方案和Nuxt.js，这两种方案相同点都是：
必须把现有webpack各项配置替换成上述两种方案工程
工程所有页面都必须SSR方式的要求实现
必须在自定义的asyncData/preFetch生命周期内获取数据
必须将接口数据使用Vuex管理
或许你认为这个也不难啊，对于一个新项目，确实不难，但对一个老项目来讲，上述的改造成本和测试成本就无比高了，这也是少有老项目改造SSR的原因。
2、SSR性能依赖接口性能
从SSR原理上你可以知道，SSR服务端渲染过程依赖于获取到全部数据才能开始渲染，一旦接口出现延时或超时，那首屏性能也会受到影响。
3、SSR负载能力和扩容能力可能成为瓶颈
几乎是业界公认，node的负载能力相比java等要差一些，相比nginx静态资源服务更差，并且很多公司在node服务器快速扩容上面，目前还没有太多实践和机制保障，虽然可以通过备足服务器来抵抗流量高峰，但毕竟这对应的是成本。
4、SSR无降级方案
一旦node服务故障，页面可能直接就会白屏，很多时候不是重启服务能够解决的，毕竟SSR不是像SPA一样在浏览器看见什么错误去解决或者回滚就可以的，你必须真正解决了故障才能恢复服务，这期间不能很容易的降级为SPA方案。
上述原因当中，最主要阻碍我们用SSR的原因是改造成本。
Prerender方案
Prerender是基于prerender-spa-plugin这个webpack插件实现的，原理如下：
核心原理就是在webpack打包过程中，通过Puppeteer访问对应路由，抓取html并静态化，再部署cdn。
但业内这种方案使用的比较少，主要原因有：
静态化过程发生在构建环节，用户访问时看到的数据注定是过时的。
这种方案依赖于使用history方式的路由，这对老项目的改造测试成本也不低。
编译时间大幅增加，想想就知道啦。
通过上述分析，我们能看出“最优方案”应该是SSR，不考虑负载能力的话，阻碍我们的只有改造成本了，能否用较低的成本实现跟SSR一样的效果呢？
离线预渲染OPR
晴空一声惊雷，OPR产生了，我们把他命名为离线预渲染OPR(Offline Prerender)。
OPR的渲染过程：
不同于SSR在用户访问阶段的渲染，OPR是一个独立于用户访问流程的渲染服务，它通过Puppeteer定期渲染页面并上传cdn，用户访问到的页面将会是纯静态页面，可以说是结合了SSR和Prerender两种方案。
与SSR方案的区别：
渲染过程独立于用户访问，没有服务器压力，占用资源极小，一台服务器即可完成
页面几乎不需要任何改动
渲染出来的页面效果几乎和SSR一致
可降级为SPA方案
与Prerender方案的区别：
通过定时渲染，解决Prerender方案数据无法及时更新的问题
页面几乎不需要任何改动
对原本项目构架过程无任何影响
OPR方案实现过程
我们简单拆解来看：
1 定时访问页面
我们首先搭建一个node服务，通过schedule机制定期通过Puppeteer访问需要渲染的页面。
2 等待页面渲染
页面渲染是一个动态的过程，我们如何知道页面已经渲染完了呢，Puppeteer其实提供多种方案，但我们最终选用的方案是通过监听公司性能统计埋点发出时机，通过Puppeteer的page.waitForRequest方法可以很容易实现。
3 抓取HTML
你必须清楚一点：我们抓取的是浏览器渲染的HTML，并非你请求到index.html文件内容。
前者你可以理解为，通过浏览器开发者工具，选中html标签，右键拷贝outerHTML。
后者你可以通过浏览器查看下html源码，里面应该只有空白的dom和一些<script>标签。
前者内容可能是这样的：
后者内容是这样的
其实抓取HTML这个动作通过Puppeteer一句代码就可以实现：page.$eval('html', e => e.outerHTML)，但抓取到的HTML我们做了很多处理：
OPR渲染标识
为了让页面知道是被OPR渲染出来的，我们将会在HTML里面注入一个变量：__offline_prerender_data__，这个变量既起到标识作用，也可以用来存放一些特殊数据
抓取接口数据
熟悉SSR过程的同学可能知道，SSR会把服务端渲染阶段所需的数据写入到HTML中，用户端渲染时会进行一次数据校验，有了这些数据，用户端也可以尽快的完成二次渲染（下文会讲到）。
在OPR当中也可以提供这样的能力：
如果开发者在配置文件当中设置了useDataCache : true，则我们会监听页面渲染完成之前所有的接口请求，并将数据打入到HTML当中，同时帮你注入一段代码，能让HTML执行时把数据存入localStorage中，供一些接口缓存库来使用
大体代码如下：
4 解决适配问题
我们在服务端puppeteer里面模拟的设备环境跟用户实际设备肯定不一样，那我们就要解决样式适配问题：
a、在head里面注入rem刷新代码
b、将页面当中的px转换为rem
方案比较简单，这里就不贴代码了。
5 去除无用内容
我们将HTML当中无用的内容去掉了，包括：
6 对比
我们期望降低一些更新cdn的频率，因此我们把渲染好的HTML会和上次渲染的HTML进行对比，如果内容一致就不会重复渲染，其中主要有两种情况导致渲染不一致：
a：过程中页面有新上线
这时两次的HTML里<script>地址不一样了，必须会再次上线
b：页面当中数据发生了变化
需要上线情况：接口数据变化了
不需要上线情况：页面当中重要程度不高的数据变化，比如倒计时、购买人数等
为了减少上述不需要上线情况导致的上线，开发者可以在对应DOM上加上offline-prerender-tag-nodiff样式名，OPR在diff的过程就不会比对这块的DOM。
7 上传cdn
OPR会把渲染好的页面根据url地址上传到cdn，例如：
转转图书首页：https://m.zhuanzhuan.com/open/ZZBook/index.html#/Book/Home
会被上传到cdn：https://m.zhuanzhuan.com/open/ZZBook/index-Book-Home.html#/Book/Home
为什么不是index.html，这样有几个好处：
a：将OPR地址和SPA地址区分开
我们只需要将入口地址替换为
https://m.zhuanzhuan.com/open/ZZBook/index-Book-Home.html#/Book/Home
用户就可以访问到OPR渲染的页面了，如果用户访问到原本的index.html，那只是访问到原本的SPA页面，只不过渲染速度会慢一点而已。
b：降低风险
试想下，如果我们把文件写入成index.html，那如果用户首次访问的是/Book/Mine的路由，用户会很奇怪，我访问的是个人中心页面，为什么你要先给我展示首页呢。
同时，也防止了OPR服务发生了意外而导致所有页面都无法访问的风险。
二次渲染
上文讲过，用户访问SSR渲染的页面和OPR渲染的页面，都会发生两次渲染：
浏览器渲染HTML当中的DOM（我们叫首次渲染，注意此时页面是静态的，无法交互）
Vue还会重新渲染并维护一份虚拟DOM，并把虚拟DOM和HTML当中的DOM进行一次混合（因为两个DOM完全一致，你完全看不到发生变化，但是可以进行交互了，我们简称二次渲染）
必须要有二次渲染，为什么？
因为首次渲染仅仅是DOM层面的展示，我们必须把Vue整体逻辑赋予DOM里，否则就没有各种事件，用户将无法交互。
SSR和OPR两种方式首次渲染过程都是一样的，但二次渲染有很大的区别：
SSR：
会先从html当中拿到数据，然后进行$mount渲染挂载，这里面Vue代码给SSR定制了一个特殊流程：会尝试跟页面当中DOM进行混合，如果完全一致就直接复用DOM，把虚拟DOM混合到页面中：
OPR：
OPR项目的二次渲染没有想象的那么简单，他很难做到复用DOM，主要因为：
OPR页面很难做到DOM完全一致
因为SSR项目是拿到所有数据进行一次性渲染，无论是服务端生成HTML的时机还是用户端二次渲染的时机都是完全一样的，数据也是完全一样的，因此能渲染出完全一样的DOM，如果虚拟DOM和页面中DOM有一丝毫差异，Vue都会删除掉页面已有DOM再使用新的DOM。
SPA页面会有个逐渐使用和渲染的过程，例如：
在OPR或者SPA页面中渲染是多次完成的：
1、当ready=true时先完成第一次渲染，同时开始渲染goodsList组件
2、goodsList会触发第二次渲染
而第一次渲染时DOM和页面当中并不一致，那么旧的DOM就直接被抛弃掉了。
那如果上述页面我们把结构写的更简单一点可以吗，比如所有组件都平铺开，不用v-if控制，所有数据都使用缓存数据，并且同步读取数据不能包含异步流程，这样理论上能完全复用DOM，但现实中是不太可能的，业务当中逻辑远比想象的负责，我们当然也不希望业务进行大量改造，这就违背OPR的初衷了。
因此OPR方案选择的二次渲染解决方案是：延时挂载DOM
这个方案的核心在于，只要你在new Vue的过程中，不传el参数，那么Vue就会在没有挂载到页面的DOM当中完成渲染和虚拟DOM的构建工作，那我们只要在一个合适的时机把DOM挂到页面上就行了，这个合适的时机是什么呢？
页面DOM和虚拟DOM接近一致
我们先说下“挂载”是怎样的过程：简而言之就是把HTML当中DOM删掉，再把虚拟DOM的句柄window.vm.$el插入body中。
大家可能会担心有性能损耗吧，实际上这个DOM删除和插入的过程非常快，对于浏览器进程资源消耗非常少。
再回到挂载时机，如果页面差异过大的时候挂载会怎么样？那用户会感到页面闪动，因为有局部样子不一致，这个应该比较好理解，所以我们要在两个DOM接近一致的时候做挂载操作
延迟挂载时机
为了能知道何时两个DOM接近一致，我们借鉴了淘宝的性能统计方案中的首屏结束时机的计算方案：
我们通过MutationObserver来监听虚拟DOM的变化，每次变化时计算一次DOM分数，当DOM分数和页面已有DOM分数接近的时候，我们去挂载DOM
具体逻辑更复杂一点：
当两个DOM几乎一致的时候，再去挂载DOM，用户就几乎感觉不到页面闪动了。
同时参考上文，如果使用了接口缓存机制，就减少DOM趋近一致的时间了。
其他优化
为了更进一步提升首屏速度，我们在OPR方案上还做了一些优化：
1 CSS tree-shaking
我们抓取的HTML里面会有很多style标签，几乎可以认为，你曾在vue里面写了多少个style标签，head里面就至少有这么多标签，例如：
这些标签里面有大量重复的样式，如果打入HTML将增大文件体积，我们对此进行了tree-shaking，可以讲原本5000行+的css代码精简到1000+，具体如何实现，我们将会在以后的文章中讲解。
2 将script改为async加载模式
在此之前，你可能需要了解下普通script、defer、async有什么区别。
简而言之，
普通script： 按书写顺序下载、执行，阻碍DOM渲染，阻碍DOMContentLoaded时间
defer script：并行下载，按照书写顺序执行，不阻碍DOM渲染，阻碍DOMContentLoaded时间
async script：并行下载，谁先下载完谁先执行，不阻碍DOM渲染，不阻碍DOMContentLoaded时间
为什么我们要用async，在某项低版本iOS内核中，会等待页面DOMContentLoaded才开始渲染页面，如果用普通script或者defer模式，会延迟页面渲染时间。
3 降级策略
如果出现任何问题，为了保证用户可访问，我们会做出降级方案，也很简单：
抓取HTML本身的文本内容，同步到cdn，相当于把OPR模式退回到SPA了，这个策略在OPR方案中会有相应的检测方式和自动切换机制。
效果
OPR方案已经在我司多个业务接入，可以把原本首屏在1500ms-4000ms的SPA页面下降到300ms-800ms，可以说是效果显著了~
最后说明
OPR方案目前应用于我司各业务无需登录态的首页及重要列表渲染，下一阶段我们将解决对登录态有依赖的页面渲染，欢迎读者与我司交流探讨。
作者简介
张所勇
转转平台运营中心前端负责人，在前端领域有深入研究，包括：sketch一键切图、前端数据模型化，小程序基础能力建设等多个方面，10年工作经验中，做了2年工程师，5年CEO，3年技术管理，能写点文章，也是2018年度掘金优秀作者。
扫描二维码关注我们
