谷歌workbox webpack插件在服务人员前先从缓存中获取

Question

当我只使用从工作箱中预缓存插件时，服务工作者尝试从indexdb而不是缓存(browser-cache)中获取。

是的，service worker比从服务器获取更快。但是，如果它从内存中获取，则需要0秒。

我已经看到了workbox中的所有策略，但它没有尝试首先从内存中获取的策略。

这就是预缓存的一切。

new WorkboxPlugin.GenerateSW({
      skipWaiting: true,
      importWorkboxFrom: 'local',
})

service-worker.js

importScripts("/dist/workbox-v3.6.3/workbox-sw.js");
workbox.setConfig({modulePathPrefix: "/dist/workbox-v3.6.3"});

importScripts(
  "/dist/precache-manifest.4b8be844a396ff2fc7335cebbab35f10.js"
);

workbox.skipWaiting();

/**
 * The workboxSW.precacheAndRoute() method efficiently caches and responds to
 * requests for URLs in the manifest.

 */
self.__precacheManifest = [].concat(self.__precacheManifest || []);
workbox.precaching.suppressWarnings();
workbox.precaching.precacheAndRoute(self.__precacheManifest, {});

Answer 1

您无法控制浏览器缓存或服务器如何处理请求，因此不幸的是，您不能先尝试浏览器缓存，然后尝试缓存API，然后再尝试服务器。

但是，您可以尝试同时从缓存API和服务器(包括浏览器缓存)加载，并提供给出最快答案的服务。

这就是杰克·阿奇博尔德在他的离线Cookbook：https://jakearchibald.com/2014/offline-cookbook/#cache-network-race中命名的“缓存和网络竞赛”

Answer 2

只是为了澄清- Workbox跟踪indexedDB中文件的哈希，但它不使用indexedDB来提供文件。它使用Cache API来存储和检索文件。

在您的问题中，您混合了缓存、内存和服务工作者，以确定响应来自何处。因此，为了澄清这一点：

1. 如果您有为页面注册的服务工作者(即，服务工作者控制页面)，则所有网络请求将首先转到服务工作者。
2. 服务工作者可以通过任何方式提供响应，也可以转到网络(请参阅服务工作者响应部分)。
3. 一旦转到网络，浏览器就可以决定从何处获取响应(请参阅浏览器响应部分)。

服务工作者响应

服务工作者通常会做以下三件事之一来创建响应：

1. 使用缓存API的响应返回。
2. 从网络获取响应并返回(可能会使用任意数量的源(包括静态字符串、流、缓存
3. 响应和网络响应)将其添加到
4. 自定义响应。

请注意，在此列表中，我指的是Cache API。这是存储在用户计算机上的web应用程序缓存的响应。

浏览器响应

对于任何网络响应，浏览器都可以执行以下操作之一来获取响应：

HTTP缓存转到网络并从server

• Reference

1. 获取新的响应以返回响应

HTTP缓存独立于缓存API。它超出了开发人员的控制范围，不能被依赖。浏览器做它认为最好的事情。

Workbox + Service Worker

Workbox提供了一组实用程序，使“服务工作者响应”部分更易于使用和开发。这意味着它只处理我概述的三种响应类型。

我已经记下了工作箱预配给做什么以及它是如何工作的，包括预配给中使用indexedDB的用途：https://developers.google.com/web/tools/workbox/modules/workbox-precaching