web资源预加载-生产环境实践

此文记录资源预加载在我们项目的实践，技术难度不算高，重在介绍一套技术方案的诞生与实施，其中都进行了哪些思考，依据什么来做决策，如何进行效果评估，等等。为读者在制定技术方案时提供一定启示。

背景

资源预加载机制很好理解，即在用户访问页面之前，提前加载好相应的资源。这样用户在访问页面的时候，省去了加载资源的时间，达到“秒开”的效果。

资源预加载的方案很多，本文所述的是纯web下的资源预加载，区别于利用容器做资源预置。所以采用的技术都是纯web方案。

另外还有一个背景：项目是SPA架构，webpack+vue全家桶，我们做的是在加载完首页之后的事情，即跳转其他页面时的预加载。配合SPA应用的优势，可以实现媲美原生应用的零延迟跳转。

下面来介绍下技术细节。

预加载哪些资源

可以预加载的资源是很多的，页面异步chunk、vue组件、js模块，甚至是接口数据也可以预请求。所以就要看你的目的是什么了。

此处我们以零延迟跳转页面为目标，所以要预加载的就是页面异步chunk。所谓页面异步chunk，是指使用vue-router定义的页面路由所对应的异步加载的文件，其实也是个vue组件，为了跟其他vue组件区分，我们管它叫页面异步chunk吧。代码里一般这么写的：

const routes = [
    name: 'home',
    path: '/home',
    children: [
        {
            path: 'A',
            component: () => import('pageA.vue'),
        },
        {
            path: 'B',
            component: () => import('pageB.vue'),
        }
    ]
]

pageA.vue和pageB.vue打包出的异步chunk在对应的路由下才会加载，给页面跳转带来延迟感，我们要预加载的就是这部分资源啦。

资源加载时机

明确了要加载的资源，接下来要考虑的是，什么时候加载这些资源呢？如果我们预加载了pageB而用户却不跳转B怎么办呢？

资源加载时机，这是个技术活，需要抓住两个关键点：

1.预加载资源应该尽量不影响用户的正常操作

2.预加载的资源要尽量保证用户能使用到

第1点，很容易想到，我们可以在页面空闲的时候去预加载。而且还要尽早，如果你加载晚了，用户就用不上你预加载的资源了。总结一下，资源加载时机就是“尽早的在页面空闲的时候”。

第2点，这就不好办了，用户跳不跳B页面是用户行为，我们怎么能保证他一定能用到预加载的资源呢。所以这个只能采取策略，保持一个可接受的比例，在“浪费流量”与“用户体验”之间找到权衡点。

下面就这两点展开说一说。

页面空闲检测

如何检测页面是否空闲呢？很不幸目前没有这样的api可用，有一个requestIdleFrameCallback，支持在每帧绘制空闲期执行一个回调函数，但不能确保一定执行。

所以我们只能自己想办法判断了，思路其实也比较简单，浏览器的渲染进程有js引擎和UI引擎这两个线程，只要这两个线程是空闲的，我们就认为页面是空闲的，这应该是行得通的。

那么，如何检测这两个线程空闲呢？其实很简单，看代码就明白了：

// 检测js线程空闲
const d1 = new Date();
setTimeout(()=＞{
    const offset = new Date() - d1;
    if (offset < 25 ) {
      // JS线程空闲
    }
}), 20);

启动一个延时函数，查看真正执行时候的延时是多少，如果延时很大，那说明当前js引擎繁忙。如果小于某个阈值，那说明js引擎空闲。

这个阈值该如何确定呢？统计真实用户的情况肯定是最准确的，所以我们用一个空闲页面统计了用户的延时均值，最终确定为5ms。

同样的思路，UI引擎的空闲也可以检测出来：

// 检测UI线程空闲
const d1 = new Date();
requestAnimationFrame(()=＞{
    const offset = new Date() - d1;
    if ( offset < 30 ) {
      // UI线程空闲
    }
})

阈值的确定也是统计的真实用户均值，最终确定为30ms。

有了这两项检测，我们就拿到了页面的“空闲时刻”。那如何“尽早的”拿到呢？做法相对简单，我们在页面加载完后用setInterval启动轮询，每隔1秒检测一次，一但检测到空闲，就进行资源预加载。

资源清单策略

接下来看第2点，如何在“浪费流量”与“用户体验”之间找到权衡。

考虑一个问题，如果只有5%的用户会从首页跳转页面B，那B的资源有必要预加载吗？答案显然是不需要。也就是说需要预加载的资源是要人工确定的，那个我们依据什么来确定资源清单呢？

有两条途径：

1.页面访问漏斗图。根据漏斗图我们能够得到每一次页面跳转的流失率，对于流失率较大的页面，我们就可以不去预加载了。多大的值算”较大“，这也是需要权衡的，比如我们认为60%就算流失较大了。一个典型的漏斗图如下：

2.根据统计指标动态调整。我们的资源预加载方案效果怎样，成本收益比怎样，是需要明确指标来衡量的。给指标造成负向作用的页面，就不去预加载它了。

那么，统计指标该如何设计呢？我们继续来讲。

指标设计

指标是为了用数据化的方式来评估和指导我们的工作、决策。既然是生产环境实践，就得有一套严谨的指标来衡量这个方案的优劣。

上文提到我们统计了用户执行setTimeout和requestAnimationFrame的延时均值，用于指导我们设定空闲检测阈值，就是一例应用。

对于整套方案，我们还设计了以下指标：

页面跳转时间

即用户跳转页面的耗时均值。这是我们要关注的核心指标，整个方案的目标就是降低页面跳转时间。由于是SPA应用，这个时间是比较容易统计到的。

触发率

即触发了资源预加载的比例，计算公式：触发率 = 资源预加载次数 / 页面加载次数。用来衡量我们的加载策略（空闲检测）是不是合理，理想情况下这个值应该接近100%，也就是说绝大多数的用户都预加载到了资源。如果发现触发率不及预期，那我们应该去调整加载策略。

命中率

即用户使用了预加载资源的比例，计算公式：使用了预加载的资源次数 / 资源预加载次数。这是用来衡量预加载资源的有效性的，比如一个资源的命中率是80%，说明80%的用户都使用到了预加载的资源，效果是非常好的。但实际的命中率往往达不到这么高，所以我们评估的标准是：与漏斗图的比例越接近，说明效果越好。

页面停留时间

即用户在一个页面的平均停留时间。这个指标也是为了指导加载策略而采集的，比如首页的平均停留时间是3秒，那么我们检查页面空闲的轮询间隔可以设为600ms一次，共检测5次。

除此之外，我们还采集了用户的网速情况，用以分析这个方案对不同网速段的用户的影响情况。

有了以上指标，我们就能够科学的制定策略了，比如某个资源的命中率低于10%，那说明是个低频页面，干脆从清单中剔除掉，不预加载了。

如何加载资源

整个思路已经清晰了起来，接下来到了加载资源环节。话说预加载资源的方式有很多种，我们选哪种呢？

不妨一一来看。

1.手写script标签

项目是用webpack打包的，通过manifest文件可以拿到资源清单，在需要预加载的时候手动创建一个script标签，用户真正跳转的时候就可以使用缓存中的资源。

这个方法的优点是侵入性较小，只是多了一次额外的资源加载，对原有代码改动很小。

但缺点也很明显：不好统计指标。要统计加载完成可以在每个script标签的onload事件里，还可以接受。但是统计命中率就没办法了，没法判断用户使用的是缓存中的资源还是新加载的。

2.浏览器prefetch

即使用<link rel="prefetch" href="xx.js">，这是浏览器提供的预加载资源方式，它会在浏览器空闲的时候自动给加载资源。

这个方式能力有点弱，因为没有js API供调用，对我们是黑盒的，没法进行相关的指标统计。

3.webpack提供的import()

webpack提供的动态加载资源的方法，虽然本质上也是写script标签，但webpack给做了很好的封装，我们通过.then()就可以知道资源加载完毕。而且资源被保存在内存中，一方面便于统计各种指标，另一方面连缓存都不必走了，速度更快。

综上，我们最终选择了方法3，能够满足我们的各项需求。

效果评估

以上就是整个方案的技术内容了，但事情到这里还不能结束。跟踪评估方案的效果，并持续优化，这才是生产环境实践的正确姿势。

我们关心的核心指标，页面跳转时间，有了50%以上的降低。这是预期之内的，之前页面跳转比如耗时200ms，命中预加载的资源后，可能一下就到了10ms以内了。这对大盘的影响是很显著的。

触发率这个指标，应该至少得在90%以上才算合格。都没触发预加载，后续还怎么谈命中。当然这个指标是可以通过调整加载策略来优化的，后面会讲。

至于命中率，就不太好说了。首先是上文提过的，它与用户行为相关，是个不稳定因素。其次，如果资源预加载触发的太晚，用户已经自己去跳转了，也会影响这个指标。所以整体从15%~35%不等吧。这个值是什么水平呢？合格还是不合格？我们通过翻阅业界也做预加载方案的资料，看到他们得到的命中率也大概在20%，所以可以认为我们的效果也算不错了。

持续优化

大家也看到了，我们的指标是存在优化空间的，方向就是：提高触发率、命中率，降低页面跳转时间。

上面也有谈到，我们为了制定出最精确的加载策略，采集了很多辅助指标。一个有意思的优化是，我们之前是进入页面1秒后开始检测空闲的，后来改成了立即进行检测。没想到这个改动给触发率带来了显著提升，原因是有部分用户在1秒内就跳到其他页面了，根本来不及触发预加载。

类似的优化还有，我们调整空闲检测的时间间隔，发现对触发率也有影响。

另外，我们也根据统计到的命中率，剔除了一些低频页面，避免这些资源拉低命中率。

总而言之，各项指标的参考值就是一个权衡的过程，需要根据自己的业务情况来商定。

更多思考

作为一个性能优化的方案，我们只是在特定项目架构、特定场景下做了一部分探索。事实上这个课题能做的还远不止此。

就比如资源加载策略，难道只能在页面空闲的时候加载吗？在PC时代，有些方案是根据鼠标的轨迹来猜测用户的下一步动作，进而决定预加载哪些资源。在移动端，我们是否可以根据滑动动作来做预测，又或者，是否可以把用户行为统计（业务埋点）作为参照，这都是可以探索的方向。

有朋友可能会问，SPA应用把首页不需要的资源给按需加载，结果你还用预加载又给加回来了，这不是多此一举吗？干脆打包成一个文件不就行了？听起来好像很有道理，不过细细思考一下，打包成一个文件和SPA+预加载，这两种的优劣各拉出清单对比一下，就知道还是有区别的。这就需要思辨能力了。

所以本文的目的就在于，描述一个技术方案的设计与落地过程，给大家提供技术上或是方法论上的参考。