时间戳

首页 > 解决方案 > 我应该使用工作箱运行时缓存 staleWhileRevalidate 来缓存 gtm.js 吗？

google-tag-manager - 我应该使用工作箱运行时缓存 staleWhileRevalidate 来缓存 gtm.js 吗？

问题描述

我在我的 next.js 应用程序中使用 GTM，并且我正在使用 next-offline，它在内部使用 workbox-webpack-plugin 来提供离线支持，使用运行时缓存staleWhileRevalidate策略来缓存 gtm.js 是个好主意吗？

我的应用程序离线工作，它离线保存分析并通过导入此脚本在重新在线时发送它们：

// Initialize offline google analytics which will store failed analytics requests and try again later when connection is back
// it will also cache the analytics.js library
workbox.googleAnalytics.initialize({
  // using a custom dimension(cd1) to track online vs. offline interactions
  parameterOverrides: {
    cd1: "offline"
  },
  // Using a custom metric to track time requests spent in the queue
  hitFilter: params => {
    const queueTimeInSeconds = Math.round(params.get("qt") / 1000);
    params.set("cm1", queueTimeInSeconds);
  }
});

假设第二次访问的用户打开了我的主页，我使用运行时缓存和 networkFirst 策略来缓存 html，所以如果用户在完全离线时再次访问我的主页，他将获得一个完全正常工作的应用程序，尤其是我使用相同的应用程序networkFirst 运行时缓存策略来缓存 api 请求，但是在完全脱机时，获取 gtm.js 的请求将返回 404，并且分析将无法脱机工作，因为 gtm.js 不会初始化获取 analytics.js 的请求，这将是从工作箱缓存提供。我的想法是使用 staleWhileRevalidate 策略来缓存 gtm.js，这样即使用户在离线模式下打开应用程序并且如果他重新上线，这些分析也会被工作箱重新发送。

这是一个好主意吗 ？它会按预期工作还是我缺少什么？

标签： google-tag-managerservice-workerprogressive-web-appsworkboxworkbox-webpack-plugin

解决方案

我不熟悉gtm.js，但workbox-google-analytics 会自动创建适当的运行时缓存路由来为您处理对analytics.js和gtag.js脚本的脱机访问：

Workbox Google Analytics 正是这样做的。它还添加了 fetch 处理程序来缓存analytics.js和gtag.js脚本，因此它们也可以脱机运行。最后，当重试失败的请求时，Workbox Google Analytics 还会自动设置（或更新）qt请求负载中的 ，以确保 Google Analytics 中的时间戳反映原始用户交互的时间。

听起来像是gtm.js从不同的 URL 加载的，gtag.js并且它的集合 ping 可能具有不同的语法，因此在 Workbox GitHub 存储库中提交功能请求gtm.js以寻求支持听起来是您最好的选择。

推荐阅读