瞒不住了,Prefetch 就是一个大谎言

Prefetch 是一个谎言

我们知道,现在的应用程序已经发展到可以拆分为多个 JavaScript包了,为了获得更好的用户体验,这些 bundle 包通常需要预获取,即 prefetch! 但是现在的prefetch 效果有多糟糕我想你也知道。

例如,为了让应用程序拆解成多个包,在你的代码的某些地方,你会进行动态导入,比如 import('./some-dependency.js')。但是作为开发人员,你或许也会在代码片段中插入额外的动态导入。下面这段代码中,假设你将代码放在惰性加载块后面的 Buy 按钮后面,看起来像这样:

代码语言:javascript
复制
export default () => {
  return (
    <div>
      <button onClick={async () => {
        // 惰性加载点击“购买”按钮背后的逻辑。
        (await import('./buy.js')).default();
      }}>Buy</button>
    </div>
  );
};

但是这样做,现在你就会有一个新的问题要解决!当用户单击 Buy 按钮时,浏览器会惰性加载 buy.js 包。根据 bundle 的大小和网络的速度,这可能会引入一个显著的、明显的延迟。那我们能做些什么来改善呢?

Prefetch

幸运的是,浏览器自带 Prefetch 支持!所以你会把这样的东西放到头部部分。这个时候,你可能认为你已经解决上面提到问题。

代码语言:html
复制
<head>
  <link rel="prefetch" href="buy.js"/>
  <!-- 或选择一个可替代的策略
    <link rel="preload" href="buy.js"/>
    <link rel="modulepreload" href="buy.js"/>
  -->
</head>

但是这段代码真的会如你所愿吗? 你也不太确定,因此接着,你在 Chrome 中测试它,发现一切都能正常工作。

但是很快,你就会得到反馈,在许多情况下,用户必须等待 Buy 按钮执行其操作。这种额外的等待正是损害用户体验的底线。那 prefetch 为什么不能如你所愿呢? 原因主要由几点:

  1. Modulepreload 不能在大多数浏览器中使用。
  2. Firefox 有 network.dns.disablePrefetchFromHTTPS 选项,默认设置为 true。默认情况下,Firefox 不会在 HTTPS 上 prefetch 任何内容。考虑到现在大多数东西都是 HTTPS,这有效地禁用了Firefox上的预取。
  3. 一些移动浏览器忽略 prefetch,因为移动浏览器认为这是在移动网络上,并试图节省带宽。

在闲置的时候加载

因此,大多数浏览器只在 network 空闲时才处理 prefetch。这是有意义的,但是为了让应用程序具有交互性,需要确保在出现次要事物(如高分辨率图像)之前出现交互性。如果等到页面上的所有东西都加载后才开始获取JavaScript,通常为时已晚。

你可以想象一个网站向你展示照片的时候。如果照片很大,需要下载一段时间。但你想在所有照片下载之前就开始与网站互动。但在所有图像都被解析之后再来获取 JavaScript 可能不是你想要的,因为这样会耗费你的耐心。

这个问题实际上说明了缺乏对浏览器中“何时”解析 Prefetch 的控制。

重复加载

prefetch 本应改善交互性,但在某些情况下,它可能会恶化交互性。

例如下面这段代码:

代码语言:html
复制
// 1. prefetch 开始
<link rel="prefetch" href="buy.js"/>

// 2. 用户交互需要执行code,但是 prefetch 没有生效,于是重新 prefetch
<button onClick={async () => {
// 惰性加载点击“购买”按钮背后的逻辑。
(await import('./buy.js')).default();
}}>Buy</button>

想象一下如果你的连接速度很慢的时候,开始 Prefetch 并开始下载JavaScript。在JavaScript完全下载之前,用户与应用程序进行交互。现在,import('./buy.js') 被执行,但是 buy.js 不在缓存中。正在运行的 buy.js 请求尚未完成。但是由于请求是不完整的,浏览器不知道缓存头是什么,所以它不知道重用请求是否安全。所以浏览器做了安全的事情,发出另一个 buy.js 资源请求。现在,对同一资源的两个请求正在运行。

更糟糕的是,原始资源被解析,buy.js 被插入到浏览器缓存中,但是资源的解析并没有解除用户交互的阻塞。相反,UI 必须等待第二个 buy.js 返回,然后才能解除阻塞。

因此,prefetch 在某些情况下,可能导致多次请求相同的资源。

来自 Console 的警告

最后,如果某些浏览器检测到给定的预取资源在 x 秒内未被使用,则会发出控制台警告。因为浏览器会认为,你没有使用到它,就不应该预取它。

该怎么做

我觉得真正的 prefetch 是一种提示,告诉浏览器你将需要一些东西,因此浏览器应该在下载时有一个良好的开端,但我们想要的是用 用户可能需要的交互代码预填充缓存。

理想情况下,我们希望控制缓存,以便:

  • 控制何时填充缓存。
  • 理解 chunk 的依赖关系图,这样我们也可以 prefetch 合成的 bundle。
  • 控制请求,以便在请求尚未在 bundle 中时可以解除请求。

简单而言,我们希望从一个被动的执行预取转变为一个主动控制预取。

事实证明,service worker 能做到。Service worker 可以拦截请求并控制缓存中的内容。使用 service worker,我们可以对流程进行正确的控制,还可以了解 chunk 依赖关系图,并可以加载相关代码。

但是创建这样一个service worker并不容易,所以大多数开发人员都不这么做。

结论

你或许经常看到是“专家”给出的常见的性能优化建议中包含了 prefetch,以确保惰性加载的块不会对用户交互造成延迟。但事实证明,现实从来没有这么简单,使用 prefetch 在实践中并不像你所希望的那样有效。

相反,我们建议使用 service worker 来完全控制 prefetch 过程。这个结果对我们来说非常有用,因为它允许我们消除由于延迟加载代码而导致的交互延迟。