离线预渲染OPR：0成本接入 媲美SSR效果

在SPA项目的首屏性能上，我们在长期关注和不断探索，期间我们尝试过很多方案，包括：

• 从减少代码体积角度的：webpack优化、打包优化、tree-shaking等

• 从减少HTTP请求角度的：接口合并、按需加载、延时加载等各种方法减少请求

• 从缓存角度出发：离线包、http&浏览器各种缓存使用、dns预解析、dll方案、接口缓存方案等

• 从数据获取时机角度出发：webWorker预取数据、路由进入过程读取数据等

• 从减少图片体积和数量出发：使用webp图片、请求域名并行优化、CSS Sprite等
  

这些方案都能一定程度上降低白屏时间和首屏时间，但收效有限，很难像SSR方案一样大幅降低数据，究其原因，SPA页面渲染过程如下：

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的原因是改造成本。

核心原理就是在webpack打包过程中，通过Puppeteer访问对应路由，抓取html并静态化，再部署cdn。

但业内这种方案使用的比较少，主要原因有：

• 静态化过程发生在构建环节，用户访问时看到的数据注定是过时的。

• 这种方案依赖于使用history方式的路由，这对老项目的改造测试成本也不低。

• 编译时间大幅增加，想想就知道啦。

不同于SSR在用户访问阶段的渲染，OPR是一个独立于用户访问流程的渲染服务，它通过Puppeteer定期渲染页面并上传cdn，用户访问到的页面将会是纯静态页面，可以说是结合了SSR和Prerender两种方案。

与SSR方案的区别：

1. 渲染过程独立于用户访问，没有服务器压力，占用资源极小，一台服务器即可完成

2. 页面几乎不需要任何改动

3. 渲染出来的页面效果几乎和SSR一致

4. 可降级为SPA方案

与Prerender方案的区别：

1. 通过定时渲染，解决Prerender方案数据无法及时更新的问题

2. 页面几乎不需要任何改动

3. 对原本项目构架过程无任何影响

其实抓取HTML这个动作通过Puppeteer一句代码就可以实现：page.$eval('html', e => e.outerHTML)，但抓取到的HTML我们做了很多处理：

OPR渲染标识

为了让页面知道是被OPR渲染出来的，我们将会在HTML里面注入一个变量：__offline_prerender_data__，这个变量既起到标识作用，也可以用来存放一些特殊数据

抓取接口数据

熟悉SSR过程的同学可能知道，SSR会把服务端渲染阶段所需的数据写入到HTML中，用户端渲染时会进行一次数据校验，有了这些数据，用户端也可以尽快的完成二次渲染（下文会讲到）。

在OPR当中也可以提供这样的能力：

如果开发者在配置文件当中设置了useDataCache : true，则我们会监听页面渲染完成之前所有的接口请求，并将数据打入到HTML当中，同时帮你注入一段代码，能让HTML执行时把数据存入localStorage中，供一些接口缓存库来使用

大体代码如下：

我们期望降低一些更新cdn的频率，因此我们把渲染好的HTML会和上次渲染的HTML进行对比，如果内容一致就不会重复渲染，其中主要有两种情况导致渲染不一致：

a：过程中页面有新上线

这时两次的HTML里<script>地址不一样了，必须会再次上线

b：页面当中数据发生了变化

• 需要上线情况：接口数据变化了

• 不需要上线情况：页面当中重要程度不高的数据变化，比如倒计时、购买人数等

为了减少上述不需要上线情况导致的上线，开发者可以在对应DOM上加上offline-prerender-tag-nodiff样式名，OPR在diff的过程就不会比对这块的DOM。

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渲染的页面，都会发生两次渲染：

1. 浏览器渲染HTML当中的DOM（我们叫首次渲染，注意此时页面是静态的，无法交互）

2. 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接近一致的时候做挂载操作

在此之前，你可能需要了解下普通script、defer、async有什么区别。

简而言之，

• 普通script：  按书写顺序下载、执行，阻碍DOM渲染，阻碍DOMContentLoaded时间

• defer script：并行下载，按照书写顺序执行，不阻碍DOM渲染，阻碍DOMContentLoaded时间

• async script：并行下载，谁先下载完谁先执行，不阻碍DOM渲染，不阻碍DOMContentLoaded时间

为什么我们要用async，在某项低版本iOS内核中，会等待页面DOMContentLoaded才开始渲染页面，如果用普通script或者defer模式，会延迟页面渲染时间。