借助导航预加载功能,您可以通过并发发出请求来缩短 Service Worker 启动时间。
摘要
- 在某些情况下,服务工件启动时间可能会延迟网络响应。
- 导航预加载可在三大主要浏览器引擎中使用,它允许您在服务工作线程启动时并行发出请求,从而解决此问题。
- 您可以使用标头将预加载请求与常规导航区分开,并提供不同的内容。
问题
当您导航到使用 Service Worker 处理提取事件的网站时,浏览器会向 Service Worker 请求响应。这涉及启动 Service Worker(如果尚未运行)并调度 fetch 事件。
启动时间取决于设备和条件。通常约为 50 毫秒。在移动设备上,该时间更接近 250 毫秒。在极端情况下(设备运行缓慢、CPU 运行缓慢),此时间可能会超过 500 毫秒。不过,由于服务工件会在事件之间保持清醒状态(时长由浏览器决定),因此您只会偶尔遇到这种延迟,例如当用户从新标签页或其他网站导航到您的网站时。
如果您是从缓存中响应,则启动时间不是问题,因为跳过网络的好处大于启动延迟。但是,如果您使用网络进行响应…
网络请求因 Service Worker 启动而延迟。
我们将继续通过在 V8 中使用代码缓存、跳过没有提取事件的服务工作器、推测性启动服务工作器和其他优化来缩短启动时间。不过,启动时间始终大于零。
Facebook 向我们指出了此问题的影响,并请求我们提供一种并行执行导航请求的方法:
导航预加载功能大显身手
导航预加载是一项功能,利用这项功能,您可以实现如下成果:用户发出 GET 导航请求时,系统在 Service Worker 启动的同时启动网络请求。
虽然这不能避免启动延迟,但却可以消除网络请求受阻的现象,从而让用户能够更快获取内容。
下面的视频演示了该方法的运作方式,其中使用 while 循环有意为 Service Worker 延迟 500 毫秒的启动时间:
下面是演示本身。如需获享导航预加载功能的好处,您需要使用支持该功能的浏览器。
启用导航预加载
addEventListener('activate', event => {
event.waitUntil(async function() {
// Feature-detect
if (self.registration.navigationPreload) {
// Enable navigation preloads!
await self.registration.navigationPreload.enable();
}
}());
});
您可以随时调用 navigationPreload.enable()
,也可以使用 navigationPreload.disable()
将其停用。不过,由于您的 fetch
事件需要使用它,因此最好在服务工件的 activate
事件中启用和停用它。
使用预加载的响应
现在,浏览器将为导航执行预加载,但您仍然需要使用响应:
addEventListener('fetch', event => {
event.respondWith(async function() {
// Respond from the cache if we can
const cachedResponse = await caches.match(event.request);
if (cachedResponse) return cachedResponse;
// Else, use the preloaded response, if it's there
const response = await event.preloadResponse;
if (response) return response;
// Else try the network.
return fetch(event.request);
}());
});
event.preloadResponse
是一个 promise,如果满足以下条件,则会使用响应进行解析:
- 已启用导航预加载。
- 该请求是
GET
请求。 - 该请求是导航请求(浏览器在加载网页(包括 iframe)时生成)。
否则,event.preloadResponse
仍然存在,但会解析为 undefined
。
针对预加载的自定义响应
如果您的网页需要从网络获取数据,最快的方法是在服务工作器中请求数据,并创建一个包含缓存部分和网络部分的单个流式响应。
假设我们要显示一篇文章:
addEventListener('fetch', event => {
const url = new URL(event.request.url);
const includeURL = new URL(url);
includeURL.pathname += 'include';
if (isArticleURL(url)) {
event.respondWith(async function() {
// We're going to build a single request from multiple parts.
const parts = [
// The top of the page.
caches.match('/article-top.include'),
// The primary content
fetch(includeURL)
// A fallback if the network fails.
.catch(() => caches.match('/article-offline.include')),
// The bottom of the page
caches.match('/article-bottom.include')
];
// Merge them all together.
const {done, response} = await mergeResponses(parts);
// Wait until the stream is complete.
event.waitUntil(done);
// Return the merged response.
return response;
}());
}
});
在上面的代码中,mergeResponses
是一个小函数,用于合并每个请求的流。这意味着,我们可以在网络内容流入时显示缓存的标头。
这比“应用壳”模型更快,因为网络请求会随网页请求一起发出,并且内容无需进行重大调整即可流式传输。
不过,对 includeURL
的请求会因 Service Worker 的启动时间而延迟。我们也可以使用导航预加载来解决此问题,但在本例中,我们不想预加载整个网页,而是想预加载包含内容。
为此,系统会在每个预加载请求中发送一个标头:
Service-Worker-Navigation-Preload: true
服务器可以使用此标志为导航预加载请求发送与常规导航请求不同的内容。只需记得添加 Vary: Service-Worker-Navigation-Preload
标头,以便缓存知道您的响应不同。
现在,我们可以使用预加载请求:
// Try to use the preload
const networkContent = Promise.resolve(event.preloadResponse)
// Else do a normal fetch
.then(r => r || fetch(includeURL))
// A fallback if the network fails.
.catch(() => caches.match('/article-offline.include'));
const parts = [
caches.match('/article-top.include'),
networkContent,
caches.match('/article-bottom')
];
更改标题
默认情况下,Service-Worker-Navigation-Preload
标头的值为 true
,但您可以将其设置为任何值:
navigator.serviceWorker.ready.then(registration => {
return registration.navigationPreload.setHeaderValue(newValue);
}).then(() => {
console.log('Done!');
});
例如,您可以将其设置为您在本地缓存的最后一篇帖子的 ID,以便服务器仅返回较新的数据。
获取状态
您可以使用 getState
查询导航栏预加载的状态:
navigator.serviceWorker.ready.then(registration => {
return registration.navigationPreload.getState();
}).then(state => {
console.log(state.enabled); // boolean
console.log(state.headerValue); // string
});
非常感谢 Matt Falkenhagen 和 Tsuyoshi Horo 参与此功能的开发,并协助撰写本文。非常感谢参与标准化工作的所有人