作者 | 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 的各種網站。

問題：service worker 開銷

在谷歌搜索運行 service worker 的最大挑戰和阻礙，是確保它不會增加用戶的感知延遲。谷歌搜索非常重視性能，已經阻止使用一些會為給定的用戶群帶來幾十毫秒額外延遲的新功能。

當團隊在最早的實驗中開始收集性能數據時，往往會出現問題。搜索結果頁面的 navigation 請求(https://developers.google.com/web/fundamentals/primers/service-workers/high-performance-loading#first_what_are_navigation_requests)響應返回的 HTML 是動態的，會根據運行在谷歌搜索 web 服務器的邏輯而變化很大。目前 service worker 沒辦法復制這個邏輯并馬上返回緩存的 HTML，最多只能將 navigation 請求發送到后端 web 服務器。

如果沒有 service worker，這個網絡請求能夠立即發出。而當 service worker 被注冊后，它總是需要啟動并獲得機會去運行 fetch event handlers(https://developers.google.com/web/fundamentals/primers/service-workers/#cache_and_return_requests)，即使這些 fetch handlers 不會對請求作任何處理。所以啟動和運行 service worker 的時間是在每次導航的基礎上增加的純粹開銷：

這讓 service worker 在驗證其他好處前就具有很大的延遲劣勢。另外，在用實機進行測試時，團隊發現 ?service worker 的啟動時間分布比較分散，一些低端移動設備啟動 service worker 的時間幾乎與網絡請求結果頁 HTML 所需的時間相同。

解決方案：使用 navigation preload

讓谷歌搜索團隊能夠繼續向前推進的一個最重要的特性是 navigation preload(https://developers.google.com/web/updates/2017/02/navigation-preload)。對于任何需要網絡來響應 navigation 請求的 service worker 來說，navigation preload 對性能的影響非常關鍵。它會提示瀏覽器在 service worker 啟動的同時立即發送 navigation 請求：

只要 service worker 在網絡響應返回前完成啟動，就意味著 service worker 不會引入任何延遲開銷。

搜索團隊還需要避免在低端移動設備使用 service worker，因為在低端移動設備 service worker 的啟動時間可能超過進行 navigation 請求的時間。由于沒有硬性而方便的規則用于定義低端移動設備，他們提出了檢查設備內存(https://developers.google.com/web/updates/2017/12/device-memory)的啟發式方法，內存少于 2 GB 的都會被認為是低端設備，因為這些設備 service worker 的啟動時間會是不可接受的。

另一個考慮因素是可用的存儲空間大小，因為可能需要幾兆字節來緩存將來會使用的完整資源集。navigator.storage 接口(https://developers.google.com/web/updates/2017/08/estimating-available-storage-space)允許谷歌搜索頁面提前確定，緩存數據的嘗試是否會因存儲空間分配失敗而面臨失敗的風險。

這樣，搜索團隊就可以使用多個條件來決定是否使用 service worker：如果用戶使用支持 navigation preload 的瀏覽器訪問谷歌搜索頁，并且所用設備擁有至少 2 GB 內存和足夠的存儲空間，那么就會注冊 service worker(https://developers.google.com/web/updates/2017/08/estimating-available-storage-space)。否則就不會使用 service worker，但用戶仍然擁有和以前一樣的谷歌搜索體驗。

這種選擇性注冊的一個好處是能夠推出一個更小、更高效的 service worker。以現代的瀏覽器為目標來運行 service worker，消除了舊瀏覽器所需的 transpilation 和 polyfills 產生的開銷。這最終從 service worker 實現的總大小中減少了大約 8 KB 的未壓縮 JavaScript 代碼。

問題：service worker 作用域

當搜索團隊進行了足夠多的延遲實驗，并且相信 navigation preload 為他們提供了一個可行、無延遲的途徑來使用 service worker 時，一些實際問題就開始出現。其中一個問題與 service worker 的作用域規則(https://developers.google.com/web/ilt/pwa/introduction-to-service-worker#registration_and_scope)有關。service worker 的作用域基于 URL 前綴確定，決定了它可以控制哪些頁面。對于運行單個 web app 的域，這不是問題，因為通常只需使用最大作用域 / 的 service worker，它可以控制域下的所有頁面。但是谷歌搜索的網址結構要復雜一些。

如果指定 service worker 的作用域為最大的 /，它最終能夠控制任何在 www.google.com(或同等區域)下的頁面，而該域下有許多與谷歌搜索無關的 URL。一個更合理、更具限制性的作用域是 /search，這至少會消除與搜索結果完全無關的 URL。

不幸的是，/search URL 被不同類型的谷歌搜索共享，由 URL 查詢參數來決定顯示特定類型的搜索結果。其中一些類型使用了與傳統 web 搜索結果頁面完全不同的代碼庫，例如，圖像搜索和購物搜索都是在 /search URL 下使用不同的查詢參數來提供服務的，但是這些搜索類型目前還沒有準備提供自己的 service worker 體驗。

解決方案：開發一個分發和路由框架

雖然已經有一些提議(https://github.com/w3c/ServiceWorker/issues/1373)允許使用比 URL 前綴更強大的方式去決定 service worker 的作用域，但谷歌搜索團隊一直在嘗試部署一個對所控制頁面子集不起任何作用的 service worker。

為了解決這個問題，谷歌搜索團隊構建了一個定制的調度和路由框架，該框架可以被配置去檢查諸如客戶端頁面查詢參數之類的條件，并根據這些條件來確定要執行的特定代碼路徑。與硬編碼規則不同，該系統是靈活的，允許那些共享 URL 空間的團隊，如圖像搜索和購物搜索，在他們決定使用 service worker 時將自己 service worker 的邏輯放入其中。

雖然這個定制的解決方案是谷歌內部的，但是相同的原則可以應用于任何包含不同邏輯并在同一 URL 下 的 web app 的域。

問題：個性化結果和指標

用戶可以使用他們的谷歌賬號登陸谷歌搜索，也可以根據自己的特定帳戶數據自定義搜索結果體驗。登錄用戶由特定的cookies(https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies)標識，這是一個被廣泛支持的標準。

使用 cookies 的一個缺點是，在 service worker 中不能訪問 cookies，因此無法檢查它的值，并確保它不會因用戶注銷或切換賬戶而發生改變。(已經在努力讓 service worker 能夠訪問 cookies(https://developers.google.com/web/updates/2018/09/asynchronous-access-to-http-cookies#welcome_service_workers)，但是目前還是實驗性的(https://developers.google.com/web/updates/2018/09/asynchronous-access-to-http-cookies#origin-trial)，并沒有被廣泛支持)

如果實際登錄的用戶和 service worker 認為目前登錄的用戶不匹配，會導致錯誤的個性化搜索結果、指標和日志記錄。對于谷歌搜索團隊來說，這些都是嚴重的問題。

解決方案：使用 postMessage 發送 cookies

谷歌搜索團隊沒有等待實驗性 API 的發布以獲得在 service worker 對 cookies 的直接訪問，而是采用了一種權宜之計：每當被 service worker 控制的頁面被加載時，相關的 cooikes 會被讀取并通過 postMessage()(https://developer.mozilla.org/en-US/docs/Web/API/Worker/postMessage)發送到 service worker。

service worker 根據預期值檢查目前 cookies 的值，如果不匹配，就按照一定步驟清除存儲中特定的用戶數據，并重新加載搜索結果頁而不會有不正確的個性化設置。

雖然 service worker 將數據重置成基礎值所采取的具體步驟是由谷歌搜索的需求決定的，但對于需要獲得瀏覽器 cookies 個性化數據的其他開發者來說，這一通用做法可能會很有用。

問題：實驗與動態性

前面提到，在默認使用新代碼和功能前，谷歌搜索團隊在很大程度上依賴于在生產環境中運行實驗和在現實中效果的測試。而對于嚴重依賴緩存數據的靜態 service worker 來說，這會有一些挑戰，因為選擇用戶進入與離開實驗通常需要與后端服務器進行通信。

解決方案：動態生成 service worker 腳本

團隊采用的解決方案是使用一個動態生成的 service worker 腳本，由 web 服務器為每個用戶定制，而不是提前生成單個靜態 service worker 腳本。會影響 service worker 行為或者網絡請求的實驗信息通常直接包含在這個定制的 service worker 腳本中，并且通過組合傳統技術，如 cookies 和在注冊有 service worker 的 URL 使用更新的代碼，來改變用戶有效的體驗集合。

使用動態生成的 service worker 腳本還可以更容易地為那些需要避免的、 service worker 實現中存在的致命 bug 提供安全出口。另外動態 service worker 響應可以是一個 no-op 實現(https://stackoverflow.com/questions/33986976/how-can-i-remove-a-buggy-service-worker-or-implement-a-kill-switch/38980776#38980776)，這樣能夠有效地為部分或所有當前用戶禁用 service worker。

問題：協同更新

現實中所有 service worker 部署面臨的最大挑戰之一是，在優先使用緩存與確保用戶能快速獲得被部署到生產環境的關鍵更新和更改，兩者之間提供一個合理的折中方案。正確的平衡取決于許多因素：

• 您的 web app 是不是一個能持續使用的單頁應用(https://en.wikipedia.org/wiki/Single-page_application)，用戶一直保持打開而不導航到新頁面

• 后端 web 服務器的更新部署周期是是什么

• 普通用戶是否能夠容忍稍微過時的 web app 版本，或者實時性是不是最重要的

在進行 service worker 實驗時，谷歌搜索團隊確保實驗運行在一系列預定的后端更新中，以保證指標和用戶體驗更接近于現實。

注意：要記住推動?service worker 落地不是一次性的部署，您需要有一個針對自身生產基礎設施的流程，以確保更新能夠隨著時間的推移平滑地進行。

解決方案：平衡實時性和緩存利用

在測試了許多不同的配置項后，谷歌搜索團隊發現以下設置在實時性和緩存利用之間提供了正確的平衡。

service worker 腳本 URL 響應的 header 包含 Cache-Control: private, max-age=1500 (1500 秒，25 分鐘)，并在注冊 service worker 時將 updateViaCache 參數設置為 all(https://developers.google.com/web/updates/2018/06/fresher-sw#updateviacache)，以確保 header 生效。

正如您所想象的那樣，谷歌搜索 web 后端是一個大型的、分布在全球的服務器集，需要有盡可能接近 100% 的運行時間。因此以滾動的方式來部署會影響 servicer worker 腳本內容的更改。

如果用戶命中了一個已更新的后端，然后快速導航到另一個后端沒有更新的頁面，那么他們會在 service worker 的版本之間多次切換。因此，通知瀏覽器在上次檢查的25分鐘后，只需要檢查更新后的腳本，就不會有明顯的負面影響。選擇加入這個措施的好處是顯著減少了動態生成 service worker 腳本的端點接收的流量。

此外，service worker 腳本的 HTTP 響應設置了 ETag header，確保在經過25分鐘后進行更新檢查時，如果在此期間沒有部署任何 service worker 更新，則服務器可以使用 HTTP 304(https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/304) 有效地響應。

雖然谷歌搜索 web app 的某些交互確實使用單頁應用風格的導航(即通過 History API(https://developer.mozilla.org/en-US/docs/Web/API/History_API#Adding_and_modifying_history_entries))，但在大多數情況下，谷歌搜索是一個使用“真實”導航的傳統 web app。這一點幫助團隊確定了使用這兩個選項：clients.claim()(https://developers.google.com/web/fundamentals/primers/service-workers/lifecycle#clientsclaim) 和 skipWaiting()(https://developers.google.com/web/fundamentals/primers/service-workers/lifecycle#skip_the_waiting_phase)，能夠有效加速更新 service worker 生命周期。在谷歌搜索的界面上點擊通常會導航到新的 HTML 文檔，調用 skipWaiting() 可以確保更新的 service worker 有機會在安裝后立即處理這些新的 navigation 請求。類似地，調用 clients.claim() 意味著更新的 service worker 將有機會在激活后有機會控制哪些已打開的、不受控制的谷歌搜索頁面。

谷歌搜索團隊所采用的方法不一定適用于所有人，這是他們對各種選項組合經過認真仔細的 A/B 測試并直到找出最適合的方案的結果。對于那些后端基礎設施允許快速部署更新的開發人員來說，可能更傾向于讓瀏覽器始終忽略 HTTP 緩存(https://developers.google.com/web/updates/2018/06/fresher-sw#whats_changing)，盡可能頻繁地檢查是否有更新的 service worker 腳本。如果您正在構建一個用戶可能會長時間保持打開狀態的單頁應用，那么使用 skipwaiting() 可能不是正確選擇，因為如果您允許新的 service worker 在有保持打開的客戶端的情況下激活，這樣可能會有緩存不一致(https://developers.google.com/web/fundamentals/primers/service-workers/lifecycle#skip_the_waiting_phase)的風險。

關鍵要點

默認情況下，service worker 不是性能無關的

為您的 web app 添加 service worker 意味著插入一段額外的 JavaScript 代碼，這些代碼需要在您的 web app 響應被接收前加載與執行。如果這些響應來自于本地緩存而不是網絡，那么由于從緩存優先獲得的性能優勢，運行 service worker 的開銷通常可以忽略不計。但是，如果您知道 service worker 在處理 navigation 請求時總是需要經過網絡，那么使用 navigation preload 對于性能至關重要。

Service worker 是漸進增強的

現在對 service worker 支持的情況比去年好很多。所有現代瀏覽器目前至少都支持一些 service worker 特性(https://jakearchibald.github.io/isserviceworkerready/)，但不幸的是，一些先進的特性如 background sync 和 navigation preload，還沒有得到普遍推廣。因此仍然有必要對您需要的特定子集的特性做檢查，并只在有這些特性的時候才注冊 service worker。

同樣，如果您也通過實驗知道了低端設備會因為 service worker 的額外開銷而表現很差，您也可以避免在低端設備注冊 service worker。

總之，您應該繼續將 service worker 視為一個漸進式的增強(https://en.wikipedia.org/wiki/Progressive_enhancement)，當所有的先決條件都滿足時，它能被添加到 web app 中，提升體驗和總體加載性能。

一切以數據指標為準

唯一能夠弄清楚 service worker 對用戶體驗是否有正面或負面影響的方法是實驗和測量結果。

設置有意義的度量的具體細節取決于您正在使用的分析程序，以及您在部署設置中如何正常進行實驗。這個例子(https://developers.google.com/web/showcase/2016/service-worker-perf)根據 Google I/O web app 對 service worker 的使用經驗，詳細介紹了一種使用 Google Analytics 收集指標的方法。

非目標

雖然許多 web 開發社區通常將 service worker 和 PWA(https://developers.google.com/web/progressive-web-apps/) 聯系在一起，但是開發“谷歌搜索 PWA”并不是團隊的最初目標。谷歌搜索 web app 目前不通過 web app manifest(https://developers.google.com/web/fundamentals/web-app-manifest/) 提供 metadata，也不建議用戶將其添加到主屏幕(https://developers.google.com/web/fundamentals/app-install-banners/)。搜索團隊目前對用戶通過傳統的入口進入谷歌搜索這一方式感到滿意。

與其試圖將谷歌搜索 web 體驗轉化為與已安裝應用程序相同的效果，不如將重點放在最初的推廣上，逐步增強現有網站。

總結

以上就是原文的全部內容，文章對谷歌搜索引入 service worker 的原因、問題和解決方案進行了詳細的介紹，向讀者展示了谷歌搜索團隊是如何謹慎地引入新技術和巧妙地解決遇到的問題。雖然文章中的使用場景是谷歌搜索，但是對想學習和使用 service worker 的開發者還是非常具有借鑒意義的，希望讀者能夠從中取得收獲，使用 service worker 進一步提高自己的 web app 的體驗。

另外推薦一本開源書籍《PWA 應用實戰》。該書由百度 Web 生態團隊撰寫與分享，記錄了團隊過去兩年積累的 PWA 方面的經驗，歡迎對 Web 和 PWA 有濃厚興趣的讀者加入我們，一起來維護這本書。

Brilliant Open Web?

BOW(Brilliant Open Web)團隊，是一個專門的Web技術建設小組，致力于推動 Open Web 技術的發展，讓Web重新成為開發者的首選。

BOW 關注前端，關注Web；剖析技術、分享實踐；談談學習，也聊聊管理。

關注 OpenWeb開發者，讓我們一起推動 OpenWeb技術的發展！

OpenWeb開發者

ID：BrilliantOpenWeb

技術連接世界，開放贏得未來

總結

以上是生活随笔為你收集整理的谷歌浏览器未发送任何数据_将 service worker 引入谷歌搜索的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。