我偶然发现了Google Workbox文档中的这个代码段:

<script>
// Check that service workers are registered
if ('serviceWorker' in navigator) {
  // Use the window load event to keep the page load performant
  window.addEventListener('load', () => {
    navigator.serviceWorker.register('/sw.js');
  });
}
</script>

没有窗口load事件处理程序,页面加载如何变得不那么高效？

服务工作者是否应该尽早联系起来,因为PWA的主要用途之一就是缓存？

我在安装事件中使用服务工作者和预缓存资产。

我还有fetch侦听器，它在运行时动态拦截请求和缓存。我知道人们说将 indexeddb 用于动态内容，例如 json 数据和可能的图像。

问题：为什么即使它是请求/响应存储，也为该 json 数据使用缓存 API 不是一个好习惯？

我问这个的原因是因为我尝试了以下操作：我index.html and main.js在install事件中预先缓存，并且在main.js我的axios请求中返回一些 json 并将其放入index.html. 如果我使用动态缓存，这意味着当对该 json api 端点发出请求时，它首先进入我的服务工作者，它获取响应并将其放入cache. 然后我测试了一下，当在离线模式下刷新页面时，我仍然得到相同的结果（json 数据相应地放在 index.html 中）。

所以我猜即使缓存 API 存储请求/响应，它仍然可以完美地用于 json 端点 api url。

知道为什么在使用服务工作者时更喜欢 indexeddb 而不是缓存 API 吗？

我们想构建一个完全离线的 React Web 应用程序。我们通常使用 NextJS。

我们当前面临的问题是我们无法预缓存应用程序的所有路由，即使它们没有使用 SSR。

例如：

pages
 - index.js
 - projects
   - index.js
   - [id.js]

Service Worker 应该预先缓存所有页面 (HTML)，以便应用程序立即完全脱机：

• /
• /项目
• /项目/123
• /项目/？？？

我们尝试使用next-offline和next-pwa，但我们只能预缓存静态资产。

有没有人有类似的要求并找到了解决方案？

我正在使用 next.js 构建 PWA，但遇到了一些问题。

我正在尝试将设备运动集成到我的用户帐户和地理位置，然后是通知。

基于此存储库https://github.com/shadowwalker/next-pwa/和本教程https://medium.com/@sarafathulla/how-to-add-firebase-push-notifications-in -next-js-react-8eecc56b5cab。

除了这些 API 之外，还有https://whatwebcando.today/device-motion.html和https://whatwebcando.today/geolocation.html。

目前 PWA 是使用 next-pwa 的样板，

下一个.config.js

module.exports = withPWA({
  pwa: {
    disable: process.env.NODE_ENV === 'development',
    dest: 'public',
    runtimeCaching,  
  },
  poweredByHeader: false,
},
withBundleAnalyzer(),

)

我很困惑如何将简单的设备运动集成到 PWA 中，以及如何整体向前推进。

如果有人能指出我正确的方向，那就太好了！与通常的 Web 开发代码非常不同。

我使用Workbox预先缓存呈现应用程序shell所需的资产,包括基本版本index.html.Workbox假定index.html在缓存中可用,否则,页面导航失败,因为我在我的服务工作者中注册了这个:

workbox.routing.registerNavigationRoute('/index.html');

我也在self.skipWaiting()安装监听器中有指令:

self.addEventListener('install', e => {
  self.skipWaiting();
});

据我了解,现在有2个install听众:

• Workbox注册的用于预缓存资产的资产(包括index.html)
• 我在我的服务工作者中手动注册的一个

self.skipWaiting()Workbox的安装监听器失败时是否可以成功？这将导致一个问题状态,即资产未预先缓存但服务工作者已激活.这种情况是否可能,我应该保护它吗？

似乎工作箱不清理旧的缓存.例如,如果我指定这样的缓存版本:

var version = 'v2';
workbox.core.setCacheNameDetails({
  suffix: version
});

...一旦新服务工作程序激活,我原本希望workbox清理旧版本的缓存,但我的缓存存储看起来像这样:

自己手动清理缓存是否安全？例如,在我的服务人员中:

self.addEventListener('activate', function(event) {
  event.waitUntil(
    caches
      .keys()
      .then(keys => keys.filter(key => !key.endsWith(version)))
      .then(keys => Promise.all(keys.map(key => caches.delete(key))))
  );
});

(代表某人公开询问/回答.)

我正在使用Workbox生成一个服务工作者,为我的渐进式Web应用程序预留资源.

我不愿意预先安排〜20mb的缩小JavaScript吗？显然,这是巨大的.20mb似乎太过分了.我的计划是只预先处理基本内容,然后使用运行时缓存.

换句话说,什么是一些通用的启发式方法来确定应该和不应该包含在预先缓存有效负载中的内容？

默认情况下skipWaiting,在Workbox中设置为false.假设您仅使用Workbox创建的服务工作程序进行缓存,那么将此设置为true是否有任何缺点？如果不这样做,您的应用程序的下一个版本将发布更新的资源URL(来自webpack).这些URL将在服务工作者的预缓存清单skipWaiting中更新,但没有,更新的服务工作者将不会被激活以利用它们,直到用户关闭其浏览器并重新打开.

这些更新的资源将被正确加载(webpack将加载其中包含新哈希值的资源),但它们永远不会被缓存,直到用户再次关闭运行服务工作者的所有打开的浏览器并重新打开.在这种情况下,有没有理由不设置skipWaiting为真？

作为一个相关的问题,有什么确切不clientsClaim控制？仅通过切换skipWaiting就可以解决上述问题; 那么客户承诺做什么？

在开发模式下（本地）使用 Workbox Webpack 插件时，我收到以下服务工作者错误：

PrecacheController.mjs:62 未捕获的 add-to-cache-list-conflicting-entries：传递给“workbox-precaching.PrecacheController.addToCacheList()”的两个条目的 URL 未定义，但修订详细信息不同。Workbox 无法正确缓存和版本化资产。请删除其中一项。

我相信这是因为，当 webpack 重新构建时，它似乎向 precache 调用添加了两次静态资产。一次在service-worker.js文件中，另一个在precache-manifest.XXX.js文件中。查看这两个文件，我可以看到在两个地方都添加了块和入口脚本，包括service-worker.js.

这在生产中不是问题，因为每个构建都会从头开始擦除和重建。

这是我的 Workbox Webpack 插件配置：

new GenerateSW({
  swDest: '../service-worker.js',
  globDirectory: 'priv/static',
  globPatterns: ['**/*.{js,css,png,jpg,gif,woff2}'],
  runtimeCaching: [
    {
      urlPattern: /^https:\/\/js.intercomcdn.com\/[a-zA-Z0-9-/_.]*(js|woff)/,
      handler: 'NetworkFirst'
    }, {
      urlPattern: /^https:\/\/fonts\.googleapis\.com/,
      handler: 'NetworkFirst',
      options: {
        cacheName: 'google-fonts-stylesheets'
      }
    },
    {
      urlPattern: /^https:\/\/fonts\.gstatic\.com/,
      handler: 'CacheFirst',
      options: {
        cacheName: 'google-fonts-webfonts',
        cacheableResponse: {
          statuses: [0, 200]
        },
        expiration: {
          maxEntries: 5,
          maxAgeSeconds: 60 * 60 * 24 * 365, …

有没有办法本地化 Web 清单？即有多个翻译name，description等等...

我已经想到了几个潜在的解决方案，但它们每个都有很大的缺点......

潜在解决方案 1（首选但不确定它是否有效）

根据 url ( example.com/en/foo) 中的区域设置，加载相关清单。

例如：

• 对于example.com/en/foo, 加载example.com/en/manifest.json
• 对于example.com/jp/foo, 加载example.com/jp/manifest.json

缺点

• 我不相信这实际上会起作用，因为每个网站只能有一个清单（据我所知），而且我相当确定它需要在根目录中
• 即使这是可能的，鉴于我的应用程序是一个静态托管的 SPA，我并不完全确定我将如何实施它，即我无法在浏览器加载清单之前动态更新清单的链接。也许我可以加载相对于 URI 的清单，但不能 100% 确定这会起作用

潜在解决方案 2

托管多个版本的 PWA（子域或 TLD）...例如：

• en.example.com/example.com
• jp.example.com/example.jp
• 等等...

鉴于清单是由构建过程生成的，这实际上很容易通过向管道添加多个部署步骤来实现。然后我将使用每个部署的环境变量来确定要插入到清单中的文本。

缺点

• 无法切换应用程序的语言（这对客户端来说是一个非常关键的功能）
• 不管它实施起来有多“容易”，它似乎都不对