借助 Navigation 预加载,您可以通过并行发出请求来缩短 Service Worker 启动时间。
浏览器支持
- <ph type="x-smartling-placeholder">
- <ph type="x-smartling-placeholder">
- <ph type="x-smartling-placeholder">
- <ph type="x-smartling-placeholder">
摘要
- 在某些情况下,Service Worker 启动时间可能会导致网络响应延迟。
- Navigation 预加载适用于三大主要浏览器引擎,它允许您在启动 Service Worker 的同时发出请求,从而解决了此问题。
- 您可以使用标头来区分预加载请求和常规导航,并提供不同的内容。
问题
当您导航到使用 Service Worker 处理提取事件的网站时,浏览器会向 Service Worker 请求响应。这涉及启动 Service Worker(如果它尚未运行)和分派提取事件。
启动时间取决于设备和条件。该时间通常为 50 毫秒左右。在移动设备上,大约为 250 毫秒。在极端情况下(设备运行缓慢、CPU 出现问题),可能会超过 500 毫秒。不过,由于 Service Worker 在浏览器确定的事件间隔时间保持唤醒状态,因此只有偶尔会出现这种延迟,例如当用户从新标签导航到您的网站或其他网站时。
如果您从缓存进行响应,那么启动时间就不成问题,因为跳过网络的好处大于启动延迟时间。但如果您是通过网络进行响应...
网络请求因 Service Worker 启动而延迟。
我们通过在 V8 中使用代码缓存、跳过没有提取事件的 Service Worker、推测启动 Service Worker 以及其他优化来继续缩短启动时间。不过,启动时间始终大于零。
Facebook 引起了我们的注意,并提出了一种并行执行导航请求的方法:
导航预加载到救援状态
Navigation 预加载是一项功能,可让您说“当用户发出 GET 导航请求时,在 Service Worker 启动时启动网络请求”。
启动延迟仍然存在,但不会阻止网络请求,因此用户可以更快地获得内容。
下面的视频展示了它的实际运用情况,其中使用 when 循环为 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
事件需要使用它,因此最好在 Service Worker 的 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
解析。
针对预加载的自定义响应
如果您的页面需要来自网络的数据,最快的方式是在 Service Worker 中请求这些数据,并创建一个包含缓存部分和网络部分一部分的流式响应。
假设我们想显示一篇文章:
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
是一个小函数,用于合并每个请求的流。这意味着,当网络内容流式传输时,我们可以显示缓存的标头。
这比“App Shell”更快模型,因为网络请求是与网页请求一起发出的,因此内容可以顺利流式传输,而不会遭遇重大入侵。
但是,对 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 对此功能的贡献,以及对本文的帮助。热烈感谢参与标准化工作的每一个人