谷歌浏览器未发送任何数据_将 service worker 引入谷歌搜索

最新推荐文章于 2023-07-23 21:53:27 发布

weixin_39646658

最新推荐文章于 2023-07-23 21:53:27 发布

阅读量3.5k

点赞数

文章标签：谷歌浏览器未发送任何数据

本文链接：https://blog.csdn.net/weixin_39646658/article/details/111340382

版权

本文详细介绍了谷歌搜索团队如何引入service worker以提供有限的搜索结果缓存、有意义的离线体验以及更智能的JavaScript缓存。通过使用navigation preload解决延迟问题，结合设备内存和存储条件选择性注册service worker，以及开发分发和路由框架应对复杂URL结构。同时，面对个性化结果和指标的挑战，团队通过postMessage传递cookies信息。最后，谷歌搜索团队通过动态生成service worker脚本进行实验和协同更新，平衡实时性和缓存利用，确保服务的稳定和高效。

摘要由CSDN通过智能技术生成

作者 | Brilliant Open Web团队

编辑 | Brilliant Open Web团队

近日谷歌发表了一篇关于谷歌搜索引入 service worker 的文章，文章详细介绍了引入过程中一些有意思的问题和解决方案，能帮助读者了解和使用 service worker，因此对原文进行了翻译，方便大家一起来学习和借鉴。原文链接：https://web.dev/google-search-sw

背景

您在使用 Google 的搜索任意话题时，都将立即获得一个相关且有用的结果页。您可能没有注意到的是，在某些特定的应用场景当中，结果列表的呈现是由一项功能强大的技术实现的，那就是 service worker。将 service worker 应用到谷歌搜索而不带来负面的性能影响，需要数十个来自不同团队的工程师合力协作。接下来要讲的就是这样一个关于推动什么技术落地、如何测量其影响以及为其做了什么权衡的故事。

探索 service worker 的主要原因

为一个 web app 添加 service worker，就像给您的站点做一个结构上的改变，需要有着一系列清晰的目标。有几个关键原因让谷歌搜索团队去探索如何引入 service worker。

service worker 是一段位于 web app 和服务端之间的代码，而运行这段代码需要一定的花销，所以需要确保 service worker 所做的能够带来在缓存或功能上足够大的收益，这样才能抵消产生的花销(Chrome Dev Summit 2018 的一个分享( https://www.youtube.com/watch?v=25aCD5XL1Jk )很好地深入探索了这个想法)。所以开启 service worker 之旅的第一步，是充分了解想实现的目标，然后收集一套完整的指标以便衡量目标的完成程度。

有限的搜索结果缓存

谷歌搜索团队发现，用户有时会短时间内多次去搜同一个词。与其每次都向后端发出请求并获得一样的结果，不如通过缓存在本地响应这些重复的请求。

同时也不能忽视结果的实时性。有时用户重复搜索同一个词是因为这是一个动态变化的话题，这样才能够看到最新的结果。搜索团队通过 service worker 可以在细粒度上控制本地结果缓存的生命周期，协调速度和实时性，以达到他们认为能最好地服务用户的平衡状态。

有意义的离线体验

另外，谷歌搜索团队想提供有意义的离线体验。当用户想了解一个话题时，他们会直接打开谷歌主页并开始搜索，而不会担心网络连接是否有效。如果没有 service worker，在离线的情况下访问谷歌搜索页面会跳转到浏览器的标准网络错误页面，用户需要在网络连接恢复之后再返回到这个页面重新搜索。而如果有 service worker，就可以向用户提供一个定制的离线 HTML 响应页面并允许他们立刻输入搜索内容。

在离线时搜索结果都是不可用的，但是 service worker 通过 background sync api(https://developers.google.com/web/updates/2015/12/background-sync)，能够延迟搜索的执行，等网络恢复就立刻将关键词发送到谷歌服务器进行搜索。

更智能的 JavaScript 缓存和服务

另一个动机是为了优化 JavaScript 代码的缓存和载入，这些 JavaScript 代码是模块化的，为搜索结果页提供各种功能特性。在没有 service worker 的情况下，打包 JavaScript 有许多好处，所以搜索团队不想简单地完全停止拼合。

搜索团队预计，通过使用 service worker 在运行时对细粒度 JavaScript 代码块进行版本控制和缓存，他们可以减少缓存混乱的数量并确保将来复用的 JavaScript 被有效缓存。service worker 中的逻辑可以分析一个 JavaScript 的 HTTP 请求所需要包含哪些 JavaScript 模块，然后在本地找出这些已被缓存的、被有效拆分的模块拼合起来以完成这个请求。这节省了用户的带宽，提高了总体响应能力。

success：平均下来，被 service worker 处理的重复请求减少了一半新的 JavaScript 的下载量，而这直接让延迟的用户交互减少 6%。

使用 service worker 缓存 JavaScript 还有一些性能上的好处，在 Chrome 中，被存储和复用的 JavaScript 是被解析并用字节代码表示的(https://v8.dev/blog/code-caching-for-devs#use-service-worker-caches)，因此在运行时只需要完成更少的处理工作，就能执行页面中的 JavaScript。

问题和解决方案

以下是实现团队既定目标需要克服的几个障碍。虽然其中一些挑战是特定于谷歌搜索的，但是更多的适用于可能正在考虑部署 service worker 的