4

上下文：我有一个生产应用程序（如果你想看这里），它当前正在使用静态资产修订包，除了它在生成内容哈希时也处理依赖项之外。gulp-rev-allgulp-rev它生成一组具有静态名称（例如goals.jsbecome goals.6a5aa614.js）并使用这些静态名称相互引用的新文件。然后我在生产环境中使用 Fastly CDN 提供这些文件，因此我的 NodeJS 服务器没有被积极用于静态资产。这一直很好。

现在我正在使站点与服务人员离线工作。由于我去年在同步逻辑上做了很多工作，所以网站的动态部分很容易检修。但是我对如何处理我的静态资产有点不知所措。

我想我会使用工作箱，这似乎工作正常。但是workbox precache使用查询来破坏缓存而不是更改文件名，两者都做似乎很愚蠢。但是，如果我停止使用版本化名称，那么如何在不支持 service worker 的浏览器上破坏缓存？

（我还有另一个相关的问题，考虑到 Fastly 的响应对 SW 来说是不透明的，因此继续使用 Fastly 是否有意义，因此不一定是预缓存的好选择？虽然没有 Fastly，但对于任何人来说，应用程序会变得慢很多没有使用服务工作者，这听起来与 PWA 方法对立。我应该添加一个 nginx 缓存还是什么？（我不知道这是什么，但我听说过几次））

在我看来，这必须有一个优雅的解决方案，但我的理解gulp非常有限，我很难知道什么是可能的，而且我对 ServiceWorkers 和缓存的理解非常有限，我很难知道正是我想要的。

因此，我无法在这个问题上获得任何牵引力：

如何调整我的 gulp 静态资产修订以与 ServiceWorkers 一起使用？

有用的一件事是链接到其他生产应用程序如何处理此问题的示例。

4

2 回答 2

4

Service Worker 在良好的常规缓存策略之上工作得最好。您应该继续修改您的静态文件名，然后将它们缓存在 service worker 中。避免通过查询字符串更改 URL 的库，您不需要该功能，因为您已经在修改 URL。

如果您的资产是从另一个来源提供的（我想这就是您在谈论 Fastly 时的意思），那么允许通过 CORS（通过Access-Control-Allow-Origin: *）请求它们，这意味着它们不会是不透明的。

于 2019-01-07T07:42:25.617 回答
2

您应该保留文件修订的资产。有关使用 gulp 和预缓存的完整示例，请查看此处。

您基本上想使用缓存优先，然后是网络模式。您可以匹配对 /goals.*.js/ => 的请求，然后根据您的应用程序，即使 [hash] 不匹配，您也可以决定使用缓存的goals.js，然后下载新目标.[hash].js 在后台。

或者，如果哈希不匹配，您可能希望先使用网络，回退到目标.js 的模糊匹配缓存。

至于 Nginx。通常建议对静态资产服务使用反向代理。Node.js 不适合这项任务。这是一个很好的工作示例。如果您使用此设置，您的静态资产流程将如下所示：

CDN => <= Nginx => Node.js 起源。

如果您使用 AWS。然后，使用 Cloudfront CDN 的典型设置将涉及将 Nginx 反向代理 node.js EC2 框设置为源。然后你会为“/”路由和你的“/assets”路由设置一个行为。

“/”行为可能具有较短的 TTL，而“/assets/”行为（Cloudfront 中的路由）将具有您的长期 (max-age=3153600) 缓存策略。

在这种情况下，几乎所有静态资产都将从 CDN (Cloudfront) 提供。只有当您使用一组新的文件修订资产部署新代码时，它才需要回到您的原始位置。

然后，您可以使用 service worker 使所有重复访问变得非常快速，甚至可能在初始重复访问时使用过时的资产（匹配名称、不同的哈希），方法是先访问缓​​存，然后再访问网络。因此，所有使用 service worker 的重复用户都将有尽可能快的初始页面加载。

那些没有它的人仍将获得文件修订、具有 CDN 边缘服务的长期浏览器缓存资产的所有好处。

于 2019-01-10T20:07:25.617 回答