离线预渲染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. 对原本项目构架过程无任何影响