我在PWA中使用工作箱和Google Analytics(分析)。我正在使用GA support from workbox,但其中一部分是为analytics.js
文件设置了缓存路由。
该代码位于此处:https://github.com/GoogleChrome/workbox/blob/v4.3.1/packages/workbox-google-analytics/initialize.mjs#L137。它使用NetworkFirst策略,该策略将allow caching opaque responses。
资源https://www.google-analytics.com/analytics.js似乎没有CORS标头,因此我们得到的响应不透明,正如[C0]所说:
一个意外的高配额使用量的常见原因是由于运行时缓存了不透明的响应...
这意味着我的应用仅会因为包含GA而会占用7mb的存储空间。我不知道缓存the workbox doco文件(一项功能)是否值得7mb的罚款,或者这是一个错误。
我已选择使用以下方式从工作箱中为我缓存该脚本:
analytics.js
...相反,希望浏览器磁盘缓存将为我服务// make sure this it before the initialize() call so it take precedence
workbox.routing.registerRoute(
/^https:\/\/www.google-analytics.com\/analytics.js/,
new workbox.strategies.NetworkOnly({}),
'GET',
)
workbox.googleAnalytics.initialize()
。
我打了正确的电话吗?我是否应该在工作箱存储库上为此创建GitHub问题?
有两个相关点:
首先,用于不透明响应的7MB配额实际上并未转换为正在使用的磁盘空间。缓存大量不透明的响应可能会导致您的来源超出浏览器强加的配额限制,但不会转化为磁盘上更多的字节。我个人不会花时间担心缓存单个不透明的响应。
其次,是加载Google Analytics(分析)JavaScript的HTML文档,它确定了在请求analytics.js
时是否使用CORS。
https://www.google-analytics.com/analytics.js
包括将拦截workbox-google-analytics
的fetch
事件并应用缓存策略的代码,但是在https://www.google-analytics.com/analytics.js
事件被拦截的点上,fetch
已经被设置为[C0 ]或event.request.mode
。
如果要使用CORS来请求'cors'
,则可以更新HTML以使其包含['no-cors'
属性],如下所示:
https://www.google-analytics.com/analytics.js
((如果crossorigin
将GA <script crossorigin async src="https://www.google-analytics.com/analytics.js">
标记通过JavaScript插入页面,那么您需要在动态创建的脚本元素上调用you're injecting。]