长时间等待请求服务工作者

时间:2017-05-22 06:51:49

标签: service-worker progressive-web-apps web-performance sw-precache

我注意到等待服务工作者使用缓存中的项目进行响应的时间并不像您预期​​的那么快。我看到fetch和自定义书面服务工作者的等待时间相同。

Request to ServiceWorker

这段等待时间的可能原因是什么?如何减少呢?

自定义服务工作者上的self.addEventListener('fetch', function(event) { event.respondWith( caches.match(event.request).then(function(response) { if (response) { return response; } return fetch(event.request); }) ); }); 事件如下所示:

{{1}}

3 个答案:

答案 0 :(得分:3)

您是否在应用程序下的Chrome开发者工具中选中了“重新加载更新” - >服务工作者选项卡?

如果是这样,那么我认为这可能是问题,因为它将重新运行所有的Service Worker代码,在每次重新加载时使用(runner, eventid, date, time)时代码可能相当多。

答案 1 :(得分:0)

事件虽然我无法回答这个奇怪的等待时间的可能原因,但我确实知道如何减少它。

我们可以使用event.respondWith()拦截服务工作者中的fetch事件。不知何故,在我的情况下,当我的页面需要通过脚本标记加载供应商的javascript时,我的服务工作者默认拦截每个获取事件以执行缓存然后网络(用于资产)或仅用于网络(用于数据)像这样:

if (shouldLoadOfflinePage) {
    fetchEvent.respondWith(cacheManager.fromCache(new Request(offlinePage)));
} else if (shouldFromCache) {
    fetchEvent.respondWith(cacheManager.fromCache(fetchEvent.request));
} else {
    fetchEvent.respondWith(fetch(fetchEvent.request));
}

最后一个块拦截一个仅限网络的请求,这是非常必要的。这个不必要的块以某种方式导致阻塞负载(但我不知道是什么阻止它):

long request to serviceworker wait time: ~400ms

所以我决定不拦截不必要的fetch-interception(当然是删除最后一个块):

if (shouldLoadOfflinePage) {
    fetchEvent.respondWith(cacheManager.fromCache(new Request(offlinePage)));
} else if (shouldFromCache) {
    fetchEvent.respondWith(cacheManager.fromCache(fetchEvent.request));
}

然后我的页面只需要16ms来加载上述文件。

希望这会有所帮助

答案 2 :(得分:0)

清除indexedDB将有助于减少“请求服务工作者”所需的时间。您可以通过js删除它:

indexedDB.deleteDatabase(location.host);

或手动完成:

  

/用户/ [USERNAME] /库/应用程序   支撑/谷歌/铬/默认值/索引资料/