作者 | Brilliant Open Web團(tuán)隊(duì)

編輯 |?Brilliant Open Web團(tuán)隊(duì)

近日谷歌發(fā)表了一篇關(guān)于谷歌搜索引入 service worker 的文章，文章詳細(xì)介紹了引入過程中一些有意思的問題和解決方案，能幫助讀者了解和使用 service worker，因此對(duì)原文進(jìn)行了翻譯，方便大家一起來學(xué)習(xí)和借鑒。原文鏈接：https://web.dev/google-search-sw

背景

您在使用 Google 的搜索任意話題時(shí)，都將立即獲得一個(gè)相關(guān)且有用的結(jié)果頁。您可能沒有注意到的是，在某些特定的應(yīng)用場(chǎng)景當(dāng)中，結(jié)果列表的呈現(xiàn)是由一項(xiàng)功能強(qiáng)大的技術(shù)實(shí)現(xiàn)的，那就是 service worker。將 service worker 應(yīng)用到谷歌搜索而不帶來負(fù)面的性能影響，需要數(shù)十個(gè)來自不同團(tuán)隊(duì)的工程師合力協(xié)作。接下來要講的就是這樣一個(gè)關(guān)于推動(dòng)什么技術(shù)落地、如何測(cè)量其影響以及為其做了什么權(quán)衡的故事。

探索 service worker 的主要原因

為一個(gè) web app 添加 service worker，就像給您的站點(diǎn)做一個(gè)結(jié)構(gòu)上的改變，需要有著一系列清晰的目標(biāo)。有幾個(gè)關(guān)鍵原因讓谷歌搜索團(tuán)隊(duì)去探索如何引入 service worker。

service worker 是一段位于 web app 和服務(wù)端之間的代碼，而運(yùn)行這段代碼需要一定的花銷，所以需要確保 service worker 所做的能夠帶來在緩存或功能上足夠大的收益，這樣才能抵消產(chǎn)生的花銷(Chrome Dev Summit 2018 的一個(gè)分享(https://www.youtube.com/watch?v=25aCD5XL1Jk)很好地深入探索了這個(gè)想法)。所以開啟 service worker 之旅的第一步，是充分了解想實(shí)現(xiàn)的目標(biāo)，然后收集一套完整的指標(biāo)以便衡量目標(biāo)的完成程度。

有限的搜索結(jié)果緩存

谷歌搜索團(tuán)隊(duì)發(fā)現(xiàn)，用戶有時(shí)會(huì)短時(shí)間內(nèi)多次去搜同一個(gè)詞。與其每次都向后端發(fā)出請(qǐng)求并獲得一樣的結(jié)果，不如通過緩存在本地響應(yīng)這些重復(fù)的請(qǐng)求。

同時(shí)也不能忽視結(jié)果的實(shí)時(shí)性。有時(shí)用戶重復(fù)搜索同一個(gè)詞是因?yàn)檫@是一個(gè)動(dòng)態(tài)變化的話題，這樣才能夠看到最新的結(jié)果。搜索團(tuán)隊(duì)通過 service worker 可以在細(xì)粒度上控制本地結(jié)果緩存的生命周期，協(xié)調(diào)速度和實(shí)時(shí)性，以達(dá)到他們認(rèn)為能最好地服務(wù)用戶的平衡狀態(tài)。

有意義的離線體驗(yàn)

另外，谷歌搜索團(tuán)隊(duì)想提供有意義的離線體驗(yàn)。當(dāng)用戶想了解一個(gè)話題時(shí)，他們會(huì)直接打開谷歌主頁并開始搜索，而不會(huì)擔(dān)心網(wǎng)絡(luò)連接是否有效。如果沒有 service worker，在離線的情況下訪問谷歌搜索頁面會(huì)跳轉(zhuǎn)到瀏覽器的標(biāo)準(zhǔn)網(wǎng)絡(luò)錯(cuò)誤頁面，用戶需要在網(wǎng)絡(luò)連接恢復(fù)之后再返回到這個(gè)頁面重新搜索。而如果有 service worker，就可以向用戶提供一個(gè)定制的離線 HTML 響應(yīng)頁面并允許他們立刻輸入搜索內(nèi)容。

在離線時(shí)搜索結(jié)果都是不可用的，但是 service worker 通過 background sync api(https://developers.google.com/web/updates/2015/12/background-sync)，能夠延遲搜索的執(zhí)行，等網(wǎng)絡(luò)恢復(fù)就立刻將關(guān)鍵詞發(fā)送到谷歌服務(wù)器進(jìn)行搜索。

更智能的 JavaScript 緩存和服務(wù)

另一個(gè)動(dòng)機(jī)是為了優(yōu)化 JavaScript 代碼的緩存和載入，這些 JavaScript 代碼是模塊化的，為搜索結(jié)果頁提供各種功能特性。在沒有 service worker 的情況下，打包 JavaScript 有許多好處，所以搜索團(tuán)隊(duì)不想簡(jiǎn)單地完全停止拼合。

搜索團(tuán)隊(duì)預(yù)計(jì)，通過使用 service worker 在運(yùn)行時(shí)對(duì)細(xì)粒度 JavaScript 代碼塊進(jìn)行版本控制和緩存，他們可以減少緩存混亂的數(shù)量并確保將來復(fù)用的 JavaScript 被有效緩存。service worker 中的邏輯可以分析一個(gè) JavaScript 的 HTTP 請(qǐng)求所需要包含哪些 JavaScript 模塊，然后在本地找出這些已被緩存的、被有效拆分的模塊拼合起來以完成這個(gè)請(qǐng)求。這節(jié)省了用戶的帶寬，提高了總體響應(yīng)能力。

success：平均下來，被 service worker 處理的重復(fù)請(qǐng)求減少了一半新的 JavaScript 的下載量，而這直接讓延遲的用戶交互減少 6%。

使用 service worker 緩存 JavaScript 還有一些性能上的好處，在 Chrome 中，被存儲(chǔ)和復(fù)用的 JavaScript 是被解析并用字節(jié)代碼表示的(https://v8.dev/blog/code-caching-for-devs#use-service-worker-caches)，因此在運(yùn)行時(shí)只需要完成更少的處理工作，就能執(zhí)行頁面中的 JavaScript。

問題和解決方案

以下是實(shí)現(xiàn)團(tuán)隊(duì)既定目標(biāo)需要克服的幾個(gè)障礙。雖然其中一些挑戰(zhàn)是特定于谷歌搜索的，但是更多的適用于可能正在考慮部署 service worker 的各種網(wǎng)站。

問題：service worker 開銷

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

當(dāng)團(tuán)隊(duì)在最早的實(shí)驗(yàn)中開始收集性能數(shù)據(jù)時(shí)，往往會(huì)出現(xiàn)問題。搜索結(jié)果頁面的 navigation 請(qǐng)求(https://developers.google.com/web/fundamentals/primers/service-workers/high-performance-loading#first_what_are_navigation_requests)響應(yīng)返回的 HTML 是動(dòng)態(tài)的，會(huì)根據(jù)運(yùn)行在谷歌搜索 web 服務(wù)器的邏輯而變化很大。目前 service worker 沒辦法復(fù)制這個(gè)邏輯并馬上返回緩存的 HTML，最多只能將 navigation 請(qǐng)求發(fā)送到后端 web 服務(wù)器。

如果沒有 service worker，這個(gè)網(wǎng)絡(luò)請(qǐng)求能夠立即發(fā)出。而當(dāng) service worker 被注冊(cè)后，它總是需要啟動(dòng)并獲得機(jī)會(huì)去運(yùn)行 fetch event handlers(https://developers.google.com/web/fundamentals/primers/service-workers/#cache_and_return_requests)，即使這些 fetch handlers 不會(huì)對(duì)請(qǐng)求作任何處理。所以啟動(dòng)和運(yùn)行 service worker 的時(shí)間是在每次導(dǎo)航的基礎(chǔ)上增加的純粹開銷：

這讓 service worker 在驗(yàn)證其他好處前就具有很大的延遲劣勢(shì)。另外，在用實(shí)機(jī)進(jìn)行測(cè)試時(shí)，團(tuán)隊(duì)發(fā)現(xiàn) ?service worker 的啟動(dòng)時(shí)間分布比較分散，一些低端移動(dòng)設(shè)備啟動(dòng) service worker 的時(shí)間幾乎與網(wǎng)絡(luò)請(qǐng)求結(jié)果頁 HTML 所需的時(shí)間相同。

解決方案：使用 navigation preload

讓谷歌搜索團(tuán)隊(duì)能夠繼續(xù)向前推進(jìn)的一個(gè)最重要的特性是 navigation preload(https://developers.google.com/web/updates/2017/02/navigation-preload)。對(duì)于任何需要網(wǎng)絡(luò)來響應(yīng) navigation 請(qǐng)求的 service worker 來說，navigation preload 對(duì)性能的影響非常關(guān)鍵。它會(huì)提示瀏覽器在 service worker 啟動(dòng)的同時(shí)立即發(fā)送 navigation 請(qǐng)求：

只要 service worker 在網(wǎng)絡(luò)響應(yīng)返回前完成啟動(dòng)，就意味著 service worker 不會(huì)引入任何延遲開銷。

搜索團(tuán)隊(duì)還需要避免在低端移動(dòng)設(shè)備使用 service worker，因?yàn)樵诘投艘苿?dòng)設(shè)備 service worker 的啟動(dòng)時(shí)間可能超過進(jìn)行 navigation 請(qǐng)求的時(shí)間。由于沒有硬性而方便的規(guī)則用于定義低端移動(dòng)設(shè)備，他們提出了檢查設(shè)備內(nèi)存(https://developers.google.com/web/updates/2017/12/device-memory)的啟發(fā)式方法，內(nèi)存少于 2 GB 的都會(huì)被認(rèn)為是低端設(shè)備，因?yàn)檫@些設(shè)備 service worker 的啟動(dòng)時(shí)間會(huì)是不可接受的。

另一個(gè)考慮因素是可用的存儲(chǔ)空間大小，因?yàn)榭赡苄枰獛渍鬃止?jié)來緩存將來會(huì)使用的完整資源集。navigator.storage 接口(https://developers.google.com/web/updates/2017/08/estimating-available-storage-space)允許谷歌搜索頁面提前確定，緩存數(shù)據(jù)的嘗試是否會(huì)因存儲(chǔ)空間分配失敗而面臨失敗的風(fēng)險(xiǎn)。

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

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

問題：service worker 作用域

當(dāng)搜索團(tuán)隊(duì)進(jìn)行了足夠多的延遲實(shí)驗(yàn)，并且相信 navigation preload 為他們提供了一個(gè)可行、無延遲的途徑來使用 service worker 時(shí)，一些實(shí)際問題就開始出現(xiàn)。其中一個(gè)問題與 service worker 的作用域規(guī)則(https://developers.google.com/web/ilt/pwa/introduction-to-service-worker#registration_and_scope)有關(guān)。service worker 的作用域基于 URL 前綴確定，決定了它可以控制哪些頁面。對(duì)于運(yùn)行單個(gè) web app 的域，這不是問題，因?yàn)橥ǔＶ恍枋褂米畲笞饔糜?/ 的 service worker，它可以控制域下的所有頁面。但是谷歌搜索的網(wǎng)址結(jié)構(gòu)要復(fù)雜一些。

如果指定 service worker 的作用域?yàn)樽畲蟮?/，它最終能夠控制任何在 www.google.com(或同等區(qū)域)下的頁面，而該域下有許多與谷歌搜索無關(guān)的 URL。一個(gè)更合理、更具限制性的作用域是 /search，這至少會(huì)消除與搜索結(jié)果完全無關(guān)的 URL。

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

解決方案：開發(fā)一個(gè)分發(fā)和路由框架

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

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

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

問題：個(gè)性化結(jié)果和指標(biāo)

用戶可以使用他們的谷歌賬號(hào)登陸谷歌搜索，也可以根據(jù)自己的特定帳戶數(shù)據(jù)自定義搜索結(jié)果體驗(yàn)。登錄用戶由特定的cookies(https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies)標(biāo)識(shí)，這是一個(gè)被廣泛支持的標(biāo)準(zhǔn)。

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

如果實(shí)際登錄的用戶和 service worker 認(rèn)為目前登錄的用戶不匹配，會(huì)導(dǎo)致錯(cuò)誤的個(gè)性化搜索結(jié)果、指標(biāo)和日志記錄。對(duì)于谷歌搜索團(tuán)隊(duì)來說，這些都是嚴(yán)重的問題。

解決方案：使用 postMessage 發(fā)送 cookies

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

service worker 根據(jù)預(yù)期值檢查目前 cookies 的值，如果不匹配，就按照一定步驟清除存儲(chǔ)中特定的用戶數(shù)據(jù)，并重新加載搜索結(jié)果頁而不會(huì)有不正確的個(gè)性化設(shè)置。

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

問題：實(shí)驗(yàn)與動(dòng)態(tài)性

前面提到，在默認(rèn)使用新代碼和功能前，谷歌搜索團(tuán)隊(duì)在很大程度上依賴于在生產(chǎn)環(huán)境中運(yùn)行實(shí)驗(yàn)和在現(xiàn)實(shí)中效果的測(cè)試。而對(duì)于嚴(yán)重依賴緩存數(shù)據(jù)的靜態(tài) service worker 來說，這會(huì)有一些挑戰(zhàn)，因?yàn)檫x擇用戶進(jìn)入與離開實(shí)驗(yàn)通常需要與后端服務(wù)器進(jìn)行通信。

解決方案：動(dòng)態(tài)生成 service worker 腳本

團(tuán)隊(duì)采用的解決方案是使用一個(gè)動(dòng)態(tài)生成的 service worker 腳本，由 web 服務(wù)器為每個(gè)用戶定制，而不是提前生成單個(gè)靜態(tài) service worker 腳本。會(huì)影響 service worker 行為或者網(wǎng)絡(luò)請(qǐng)求的實(shí)驗(yàn)信息通常直接包含在這個(gè)定制的 service worker 腳本中，并且通過組合傳統(tǒng)技術(shù)，如 cookies 和在注冊(cè)有 service worker 的 URL 使用更新的代碼，來改變用戶有效的體驗(yàn)集合。

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

問題：協(xié)同更新

現(xiàn)實(shí)中所有 service worker 部署面臨的最大挑戰(zhàn)之一是，在優(yōu)先使用緩存與確保用戶能快速獲得被部署到生產(chǎn)環(huán)境的關(guān)鍵更新和更改，兩者之間提供一個(gè)合理的折中方案。正確的平衡取決于許多因素：

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

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

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

在進(jìn)行 service worker 實(shí)驗(yàn)時(shí)，谷歌搜索團(tuán)隊(duì)確保實(shí)驗(yàn)運(yùn)行在一系列預(yù)定的后端更新中，以保證指標(biāo)和用戶體驗(yàn)更接近于現(xiàn)實(shí)。

注意：要記住推動(dòng)?service worker 落地不是一次性的部署，您需要有一個(gè)針對(duì)自身生產(chǎn)基礎(chǔ)設(shè)施的流程，以確保更新能夠隨著時(shí)間的推移平滑地進(jìn)行。

解決方案：平衡實(shí)時(shí)性和緩存利用

在測(cè)試了許多不同的配置項(xiàng)后，谷歌搜索團(tuán)隊(duì)發(fā)現(xiàn)以下設(shè)置在實(shí)時(shí)性和緩存利用之間提供了正確的平衡。

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

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

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

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

雖然谷歌搜索 web app 的某些交互確實(shí)使用單頁應(yīng)用風(fēng)格的導(dǎo)航(即通過 History API(https://developer.mozilla.org/en-US/docs/Web/API/History_API#Adding_and_modifying_history_entries))，但在大多數(shù)情況下，谷歌搜索是一個(gè)使用“真實(shí)”導(dǎo)航的傳統(tǒng) web app。這一點(diǎn)幫助團(tuán)隊(duì)確定了使用這兩個(gè)選項(xiàng)：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 生命周期。在谷歌搜索的界面上點(diǎn)擊通常會(huì)導(dǎo)航到新的 HTML 文檔，調(diào)用 skipWaiting() 可以確保更新的 service worker 有機(jī)會(huì)在安裝后立即處理這些新的 navigation 請(qǐng)求。類似地，調(diào)用 clients.claim() 意味著更新的 service worker 將有機(jī)會(huì)在激活后有機(jī)會(huì)控制哪些已打開的、不受控制的谷歌搜索頁面。

谷歌搜索團(tuán)隊(duì)所采用的方法不一定適用于所有人，這是他們對(duì)各種選項(xiàng)組合經(jīng)過認(rèn)真仔細(xì)的 A/B 測(cè)試并直到找出最適合的方案的結(jié)果。對(duì)于那些后端基礎(chǔ)設(shè)施允許快速部署更新的開發(fā)人員來說，可能更傾向于讓瀏覽器始終忽略 HTTP 緩存(https://developers.google.com/web/updates/2018/06/fresher-sw#whats_changing)，盡可能頻繁地檢查是否有更新的 service worker 腳本。如果您正在構(gòu)建一個(gè)用戶可能會(huì)長(zhǎng)時(shí)間保持打開狀態(tài)的單頁應(yīng)用，那么使用 skipwaiting() 可能不是正確選擇，因?yàn)槿绻试S新的 service worker 在有保持打開的客戶端的情況下激活，這樣可能會(huì)有緩存不一致(https://developers.google.com/web/fundamentals/primers/service-workers/lifecycle#skip_the_waiting_phase)的風(fēng)險(xiǎn)。

關(guān)鍵要點(diǎn)

默認(rèn)情況下，service worker 不是性能無關(guān)的

為您的 web app 添加 service worker 意味著插入一段額外的 JavaScript 代碼，這些代碼需要在您的 web app 響應(yīng)被接收前加載與執(zhí)行。如果這些響應(yīng)來自于本地緩存而不是網(wǎng)絡(luò)，那么由于從緩存優(yōu)先獲得的性能優(yōu)勢(shì)，運(yùn)行 service worker 的開銷通?？梢院雎圆挥?jì)。但是，如果您知道 service worker 在處理 navigation 請(qǐng)求時(shí)總是需要經(jīng)過網(wǎng)絡(luò)，那么使用 navigation preload 對(duì)于性能至關(guān)重要。

Service worker 是漸進(jìn)增強(qiáng)的

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

同樣，如果您也通過實(shí)驗(yàn)知道了低端設(shè)備會(huì)因?yàn)?service worker 的額外開銷而表現(xiàn)很差，您也可以避免在低端設(shè)備注冊(cè) service worker。

總之，您應(yīng)該繼續(xù)將 service worker 視為一個(gè)漸進(jìn)式的增強(qiáng)(https://en.wikipedia.org/wiki/Progressive_enhancement)，當(dāng)所有的先決條件都滿足時(shí)，它能被添加到 web app 中，提升體驗(yàn)和總體加載性能。

一切以數(shù)據(jù)指標(biāo)為準(zhǔn)

唯一能夠弄清楚 service worker 對(duì)用戶體驗(yàn)是否有正面或負(fù)面影響的方法是實(shí)驗(yàn)和測(cè)量結(jié)果。

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

非目標(biāo)

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

與其試圖將谷歌搜索 web 體驗(yàn)轉(zhuǎn)化為與已安裝應(yīng)用程序相同的效果，不如將重點(diǎn)放在最初的推廣上，逐步增強(qiáng)現(xiàn)有網(wǎng)站。

總結(jié)

以上就是原文的全部?jī)?nèi)容，文章對(duì)谷歌搜索引入 service worker 的原因、問題和解決方案進(jìn)行了詳細(xì)的介紹，向讀者展示了谷歌搜索團(tuán)隊(duì)是如何謹(jǐn)慎地引入新技術(shù)和巧妙地解決遇到的問題。雖然文章中的使用場(chǎng)景是谷歌搜索，但是對(duì)想學(xué)習(xí)和使用 service worker 的開發(fā)者還是非常具有借鑒意義的，希望讀者能夠從中取得收獲，使用 service worker 進(jìn)一步提高自己的 web app 的體驗(yàn)。

另外推薦一本開源書籍《PWA 應(yīng)用實(shí)戰(zhàn)》。該書由百度 Web 生態(tài)團(tuán)隊(duì)撰寫與分享，記錄了團(tuán)隊(duì)過去兩年積累的 PWA 方面的經(jīng)驗(yàn)，歡迎對(duì) Web 和 PWA 有濃厚興趣的讀者加入我們，一起來維護(hù)這本書。

Brilliant Open Web?

BOW(Brilliant Open Web)團(tuán)隊(duì)，是一個(gè)專門的Web技術(shù)建設(shè)小組，致力于推動(dòng) Open Web 技術(shù)的發(fā)展，讓W(xué)eb重新成為開發(fā)者的首選。

BOW 關(guān)注前端，關(guān)注Web；剖析技術(shù)、分享實(shí)踐；談?wù)剬W(xué)習(xí)，也聊聊管理。

關(guān)注 OpenWeb開發(fā)者，讓我們一起推動(dòng) OpenWeb技術(shù)的發(fā)展！

OpenWeb開發(fā)者

ID：BrilliantOpenWeb

技術(shù)連接世界，開放贏得未來

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。