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

关注我们 文末有福利

作者简介

张所勇

转转平台运营中心前端负责人，在前端领域有深入研究，包括：sketch一键切图、前端数据模型化，小程序基础能力建设等多个方面，10年工作经验中，做了2年工程师，5年CEO，3年技术管理，能写点文章，也是2018年度掘金优秀作者。

细数现阶段业内首屏优化方案，主要有：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管理

  <