Service Worker 註冊

為服務工作人員註冊計時的最佳做法。

Jeff Posnick

服務 工作站 可以確實加快使用者再次造訪網頁應用程式的速度，不過， 確保 Service Worker 的初始安裝不會降級 決定使用者初次造訪的體驗

一般而言，延遲 Service Worker 註冊 等到初始頁面載入後，才能確保 使用者，特別是網路連線較慢的行動裝置。

常見登記樣板

如果您曾看過服務工作人員的資訊，那麼您可能已經聽說 類似以下的樣板：

if ('serviceWorker' in navigator) {
    navigator.serviceWorker.register('/service-worker.js');
}

有時可能會伴隨幾個 console.log() 陳述式，或 程式碼 偵測更新到先前的 Service Worker 註冊狀態更新， 通知使用者重新整理網頁但這裡只是一小部分 導入標準程式碼

那麼，「navigator.serviceWorker.register」是否有任何細微差異？是否有任何 最佳做法出乎意料 (因為本文不會結束) 這裡，這兩個答案都是「是！」

使用者初次造訪

假設使用者首次造訪網頁應用程式，目前沒有任何 Service Worker 而瀏覽器無法事先得知 最終安裝的工作站。

開發人員的首要之務是確保瀏覽器能快速載入 只取得最基本的一組資源，以顯示 頁面。任何拖慢擷取這些回應的速度，都是 提供快速的互動體驗

現在，請假設您在下載 JavaScript 或映像檔時 網頁需要轉譯後，瀏覽器決定啟動背景執行緒，或 (為求簡潔，我們假設這是執行緒)。假設 您使用的並非由高效率的桌上型電腦 許多人都會考慮使用自己的主要裝置。啟動 這個額外的執行緒會使瀏覽器的 CPU 作業時間和記憶體發生爭用情形 或是在轉譯互動式網頁時投入資源

閒置的背景執行緒不太可能產生顯著差異。但 如果該執行緒不是閒置狀態，而是決定也會啟動 要從網路下載資源呢？任何關於 CPU 或記憶體的疑慮 爭用情況應解決頻寬不足的問題 都適用於許多行動裝置頻寬很珍貴，所以可不必擔心 同時下載次要資源

這一切都是為了啟動新的 Service Worker 執行緒以供下載 背景和快取資源可能會讓您達成目標 使用者初次造訪網頁時 網站。

改善樣板

解決方法是選擇何時撥打電話，以控管 Service Worker 的啟動時間 navigator.serviceWorker.register()。有一個簡單的經驗法則：延遲 註冊期限為 load event 在 window 上觸發，如下所示：

if ('serviceWorker' in navigator) {
    window.addEventListener('load', function() {
    navigator.serviceWorker.register('/service-worker.js');
    });
}

但啟動 Service Worker 註冊的適當時機也取決於 網頁應用程式載入後可執行的操作例如，Google I/O 大會 2016 年網頁應用程式包含簡短動畫 才能切換至主畫面我們的團隊 動畫播放期間關閉 Service Worker 註冊，可能會導致卡頓 在低階行動裝置上運作我們不會為使用者提供不佳的體驗 誤點 Service Worker 會登錄到動畫結束後才註冊 可能有幾秒鐘的閒置時間

同樣地，若網頁應用程式採用的架構會在之後執行其他設定， 載入網頁後，請找出能夠告知的架構專屬事件 作業都已完成。

後續造訪

我們一直著眼於首次造訪的體驗， 延遲註冊服務工作人員是否重複造訪您的網站？ 雖然可能會帶給部分人驚喜，但不應有任何影響。

註冊 Service Worker 後，系統會執行 install 和 activate 生命週期 事件。 啟用 Service Worker 後，它就能為任何fetch 造訪您網頁應用程式的後續造訪Service Worker 會在 要求是代表該範圍內的所有頁面 給大家看如果現有 Service Worker 在 使用者造訪某個網頁時，便無法完成 fetch 次事件 導航要求

如果有運作中的 Service Worker，您可以呼叫 navigator.serviceWorker.register()，或實際上是完全不呼叫。 除非您變更 Service Worker 指令碼的網址，否則 navigator.serviceWorker.register()實際上是 no-op 。是 彼此無關

盡早註冊的好處

是否有任何情境：及早註冊 Service Worker 是否合理？第一個問題是服務工作處理程序 clients.claim()敬上 在首次造訪時控管網頁，而 Service Worker 和 積極執行執行階段 快取 在其 fetch 處理常式內部。在這種情況下 最快的速度是讓 Service Worker 有效運作，嘗試 在執行階段快取中填入稍後實用的資源。如果 您的應用程式就屬於這個類別 建議您採取行動 確認 Service Worker 的 install 處理常式未要求 可以因應主要頁面要求佔用頻寬的資源

測試新功能

模擬首次造訪情形的絕佳方式是在 Chrome 中開啟網頁應用程式 無痕模式 視窗 並查看 Chrome 的 開發人員工具。作為網站 建議您重新載入網頁應用程式的本機執行個體數十個 才會每天完成數十次但如果在 Service Worker 和填入完整快取的快取功能，不同情況 新使用者收到的功能，您可以輕易忽略潛在的問題。

以下這個例子說明註冊時 。訪客造訪範例時，會擷取以下兩張螢幕截圖 應用程式 無痕模式啟用網路節流設定，模擬緩慢的連線速度。

搶先註冊的網路流量。

上方的螢幕截圖反映了修改樣本時的網路流量 執行 Service Worker 註冊。您可以看到 預先快取要求 (搭配 齒輪 圖示 旁邊，源自 Service Worker 的 install 處理常式) 與顯示網頁所需之其他資源的要求交錯。

延遲註冊後的網路流量。

在上方的螢幕截圖中，Service Worker 的登錄作業會延遲到 已載入網頁。您會發現預先快取要求必須等到所有要求才會啟動 已從網路擷取資源，清除 頻寬。此外，因為某些我們正在預先快取的項目 瀏覽器的 HTTP 快取，也就是大小含有 (from disk cache) 的項目 資料欄—我們可以直接填入 Service Worker 的快取資料，而不需要前往 就可以重新設定。

要是您以實際、低階的裝置 用於實際行動網路您可以使用 Chrome 的遠端偵錯功能 技術能力 透過 USB 將 Android 手機連接到電腦，並確保 請確認您執行測試的實際體驗 使用者。

結論

總而言之，務必確保使用者能獲得最佳的初次造訪體驗 是首要目標延後 Service Worker 的註冊，直到 網頁可以在初次造訪時載入，以便確保這一點。你仍可取得 為您回流資料，選擇服務工作人員可獲得的所有好處。

輕鬆確保服務工作處理程序初始延遲的簡單方法 才會使用以下程式碼：

if ('serviceWorker' in navigator) {
    window.addEventListener('load', function() {
    navigator.serviceWorker.register('/service-worker.js');
    });
}