評估服務工作站的實際效能影響

Philip Walton

從效能的角度來看，服務工作處理程序最顯著的優點之一，就是能主動控制資產的快取。能夠快取所有必要資源的網頁應用程式，對於回訪者而言，載入速度應該會快上許多。不過，這些成果對實際使用者來說，實際上是什麼樣子？您如何評估這項指標？

Google I/O 大會網頁應用程式 (簡稱 IOWA) 是一種漸進式網頁應用程式，可運用服務工作人員提供的多數新功能，為使用者提供類似應用程式的豐富體驗。他們也使用 Google Analytics 擷取大量多元使用者的關鍵成效資料和使用模式。

本研究案例探討 IOWA 如何使用 Google Analytics 找出關鍵成效問題的答案，並回報服務工作程對實際影響。

從問題開始

在網站或應用程式中導入數據分析時，請務必先從收集的資料中找出您想回答的問題。

我們想要回答幾個問題，但基於本個案研究的目的，我們先著重於另外兩個較有趣的問題。

1. 服務工作者快取的效能是否比所有瀏覽器中現有的 HTTP 快取機制更佳？

我們預期回訪者網頁的載入速度會比新訪者網頁快，因為瀏覽器可將要求儲存在快取中，並在回訪時立即提供。

服務工作者提供其他快取功能，讓開發人員精確控管快取內容和方式。在 IOWA 中，我們改善了服務工作者實作方式，讓每項素材資源都會快取，讓回訪者可在完全離線的情況下使用應用程式。

但這項工作是否比瀏覽器預設功能更優異？如果是的話，效能提升了多少？1

2. 服務工作者會如何影響網站載入體驗？

換句話說，無論實際載入時間如何 (根據傳統網頁載入指標評估)，網站的載入速度是否「感覺」很快？

就體驗感受到的感受顯而易見，我們顯然不是簡單的工作，而且任何指標都能充分反映這樣的主觀情緒。儘管如此，有些指標比其他指標更好，因此選擇正確的指標是關鍵。

選擇合適的指標

根據預設，Google Analytics 會追蹤網站 1% 訪客的網頁載入時間 (透過 Navigation Timing API)，並透過「平均網頁載入時間」等指標提供這些資料。

平均網頁載入時間 指標可用來回答第一個問題，但無法回答第二個問題。特別是，load 事件不一定能對應使用者能實際與應用程式互動的時機。此外，兩個載入時間相同的應用程式可能會感覺負載不同。舉例來說，如果網站有啟動畫面或載入指標，使用者可能會覺得載入速度比只顯示空白畫面幾秒鐘的網站快上許多。

我們在 IOWA 中看到一個啟動畫面倒數計時動畫，這在我認為效果相當出色，可帶給使用者歡樂，同時應用程式的其餘部分則在背景載入。因此，追蹤啟動畫面顯示的時間長度，會是評估感知載入效能的最佳方式。我們選擇首次顯示時間這個指標來取得這個值。

決定要回答的問題，並找出有助於回答這些問題的指標後，就可以導入 Google Analytics 並開始評估了。

Analytics 導入方式

如果您曾使用 Google Analytics，應該對建議的 JavaScript 追蹤程式碼片段很熟悉。這是訂閱按鈕的圖示：

<script>
window.ga=window.ga||function(){(ga.q=ga.q||[]).push(arguments)};ga.l=+new Date;
ga('create', 'UA-XXXXX-Y', 'auto');
ga('send', 'pageview');
</script>
<script async src="https://www.google-analytics.com/analytics.js"></script>

上述程式碼的第一行會初始化全域 ga() 函式 (如果尚未存在)，而最後一行會以非同步方式下載 analytics.js 程式庫。

中間部分包含以下兩行：

ga('create', 'UA-XXXXX-Y', 'auto');
ga('send', 'pageview');

這兩個「指令」會追蹤訪客造訪網站，但「更多」造訪了哪些網頁。如果您想追蹤其他使用者互動，必須自行進行。

針對 IOWA，我們想追蹤另外兩項資訊：

• 從網頁開始載入到畫面顯示像素所經過的時間。
• 指出網頁是否由服務工作人員控管。有了這項資訊，我們就能區隔報表，比較有無服務工作元的結果。

縮短首次繪製所需時間

部分瀏覽器會記錄第一個像素繪製到畫面上的確切時間，並將這段時間提供給開發人員。與透過 Navigation Timing API 公開的 navigationStart 值相比，這個值可讓我們非常精確地計算出，從使用者最初要求存取網頁到首次看到內容所需的時間。

如先前所述，首次繪製時間是重要的評估指標，因為這是使用者體驗網站載入速度的第一個時間點。這是使用者對品牌的第一印象，良好的第一印象可以為後續的使用者體驗帶來正面影響2。

為了在瀏覽器中取得第一個顯示的繪圖值，我們建立了 getTimeToFirstPaintIfSupported 公用程式函式：

function getTimeToFirstPaintIfSupported() {
  // Ignores browsers that don't support the Performance Timing API.
  if (window.performance && window.performance.timing) {
    var navTiming = window.performance.timing;
    var navStart = navTiming.navigationStart;
    var fpTime;

    // If chrome, get first paint time from `chrome.loadTimes`.
    if (window.chrome && window.chrome.loadTimes) {
      fpTime = window.chrome.loadTimes().firstPaintTime * 1000;
    }
    // If IE/Edge, use the prefixed `msFirstPaint` property.
    // See http://msdn.microsoft.com/ff974719
    else if (navTiming.msFirstPaint) {
      fpTime = navTiming.msFirstPaint;
    }

    if (fpTime && navStart) {
      return fpTime - navStart;
    }
  }
}

注意： 重要事項：上述函式中參照的 firstpaint 值屬於供應商專用 API。這些功能並非標準功能，且隨時可能會變更 (或移除)。我們選擇在 IOWA 中導入這些功能，因為該網站的生命週期有限。對於大多數網站而言，最好在 firstpaint (或 firstpaint 替代方案) 標準化之前，使用其他使用者時間技術。

有了這個，我們現在可以編寫另一個函式，傳送非互動事件，並將首次繪製的時間設為其值：3

function sendTimeToFirstPaint() {
  var timeToFirstPaint = getTimeToFirstPaintIfSupported();

  if (timeToFirstPaint) {
    ga('send', 'event', {
      eventCategory: 'Performance',
      eventAction: 'firstpaint',
      // Rounds to the nearest millisecond since
      // event values in Google Analytics must be integers.
      eventValue: Math.round(timeToFirstPaint)
      // Sends this as a non-interaction event,
      // so it doesn't affect bounce rate.
      nonInteraction: true
    });
  }
}

編寫這兩個函式後，追蹤程式碼會如下所示：

// Creates the tracker object.
ga('create', 'UA-XXXXX-Y', 'auto');

// Sends a pageview for the initial pageload.
ga('send', 'pageview');

// Sends an event with the time to first paint data.
sendTimeToFirstPaint();

請注意，視上述程式碼執行的時間而定，畫素可能已繪製到螢幕上，也可能尚未繪製。為確保系統一開始繪製時就會執行這段程式碼，我們將對 sendTimeToFirstPaint() 的呼叫延後至 load 事件之後。事實上，我們決定將所有數據分析資料的傳送作業延後至網頁載入完成後，以確保這些要求不會與其他資源的載入作業競爭。

// Creates the tracker object.
ga('create', 'UA-XXXXX-Y', 'auto');

// Postpones sending any hits until after the page has fully loaded.
// This prevents analytics requests from delaying the loading of the page.
window.addEventListener('load', function() {
  // Sends a pageview for the initial pageload.
  ga('send', 'pageview');

  // Sends an event with the time to first paint data.
  sendTimeToFirstPaint();
});

上述程式碼會向 Google Analytics 回報 firstpaint 次，但這只是一半的內容。我們仍然需要追蹤 Service Worker 狀態，否則我們無法針對由服務工作人員控制的網頁和非控制頁面比較首次繪製時間。

判斷 Service worker 狀態

為了判斷服務工作者的目前狀態，我們建立了一個公用函式，會傳回下列三個值之一：

• 受控管：Service Worker 正在控管網頁。以 IOWA 為例，這也表示所有資產皆已快取，且網頁可離線運作。
• 支援：瀏覽器支援 Service Worker，但 Service Worker 尚未控管網頁。這是新訪客的預期狀態，
• 不支援：使用者的瀏覽器不支援服務工作者。

function getServiceWorkerStatus() {
  if ('serviceWorker' in navigator) {
    return navigator.serviceWorker.controller ? 'controlled' : 'supported';
  } else {
    return 'unsupported';
  }
}

這個函式取得了 Service Worker 狀態；下一步是將這個狀態和先前傳送至 Google Analytics 的資料建立關聯。

使用自訂維度追蹤自訂資料

根據預設，Google Analytics 提供許多方法，可讓您根據使用者、工作階段或互動的屬性，將總流量細分成多個群組。這些屬性稱為「維度」。網路開發人員常會關注的維度包括「瀏覽器」、「作業系統」或「裝置類別」。

服務工作者的狀態並非 Google Analytics 預設提供的維度，但您可以自行建立自訂維度，並視需要加以定義。

我們針對 IOWA 建立了一個名為服務工作人員狀態的自訂維度，並將其範圍設為命中 (即每次互動)4。您在 Google Analytics 中建立的每個自訂維度都會在該資源中獲得一個專屬索引，您可以在追蹤程式碼中按照索引參照該維度。舉例來說，如果我們剛建立的維度索引為 1，我們可以更新邏輯，如下所示，以便傳送 firstpaint 事件，納入服務工作程狀態：

ga('send', 'event', {
  eventCategory: 'Performance',
  eventAction: 'firstpaint',
  // Rounds to the nearest millisecond since
  // event values in Google Analytics must be integers.
  eventValue: Math.round(timeToFirstPaint)
  // Sends this as a non-interaction event,
  // so it doesn't affect bounce rate.
  nonInteraction: true,

  // Sets the current service worker status as the value of
  // `dimension1` for this event.
  dimension1: getServiceWorkerStatus()
});

這麼做是可行的，但只會將服務工作單元的狀態與這個特定事件建立關聯。由於「服務工作處理程序狀態」可能有助您瞭解任何互動，因此建議您將其與傳送至 Google Analytics 的所有資料一併加入。

為在所有回應 (例如所有網頁瀏覽、事件等) 中加入這項資訊，我們會在追蹤器 物件本身上設定自訂維度值，然後再將任何資料傳送至 Google Analytics。

ga('set', 'dimension1', getServiceWorkerStatus());

設定完成後，系統會在目前網頁載入的所有後續命中中傳送這個值。如果使用者稍後再次載入網頁，系統可能會從 getServiceWorkerStatus() 函式傳回新的值，並在追蹤器物件上設定該值。

關於程式碼的清晰度和可讀性，請注意：其他查看此程式碼的人可能不知道 dimension1 是指什麼，因此建議您建立變數，將有意義的維度名稱對應至 analytics.js 會使用的值。

// Creates a map between custom dimension names and their index.
// This is particularly useful if you define lots of custom dimensions.
var customDimensions = {
  SERVICE_WORKER_STATUS: 'dimension1'
};

// Creates the tracker object.
ga('create', 'UA-XXXXX-Y', 'auto');

// Sets the service worker status on the tracker,
// so its value is included in all future hits.
ga('set', customDimensions.SERVICE_WORKER_STATUS, getServiceWorkerStatus());

// Postpones sending any hits until after the page has fully loaded.
// This prevents analytics requests from delaying the loading of the page.
window.addEventListener('load', function() {
  // Sends a pageview for the initial pageload.
  ga('send', 'pageview');

  // Sends an event with the time to first paint data.
  sendTimeToFirstPaint();
});

如前所述，您可以透過每個命中傳送「Service Worker Status」維度，讓我們在製作任何指標報表時使用這項維度。

如您所見，IOWA 的所有網頁瀏覽次數中，有近 85% 來自支援 Service Worker 的瀏覽器。

結果：解答我們的問題

開始收集資料以回答問題後，我們就能根據這些資料製作報表，查看結果。(注意：這裡顯示的所有 Google Analytics 資料，都代表 2016 年 5 月 16 日至 22 日之間到達 IOWA 網站的實際流量)。

第一個問題是：「Service Worker 快取的效能是否高於所有瀏覽器現有的 HTTP 快取機制？」

為回答這個問題，我們建立了自訂報表，針對不同維度查看「平均網頁載入時間」指標。這項指標非常適合用來回答這個問題，因為只有在所有初始資源下載完成後，load 事件才會觸發。因此，這項指標直接反映所有網站重要資源的總載入時間。5

我們選擇的維度如下：

• 我們的自訂「Service Worker Status」維度。
• 使用者類型：指出使用者是首次造訪網站，還是回訪網站。(注意：新訪客不會快取任何資源，回訪者可能會進行存取)。
• 裝置類別：可比較行動版和電腦版的結果。

為避免非 Service Worker 相關因素影響載入時間結果，我們將查詢限制在僅包含支援 Service Worker 的瀏覽器。

如您所見，在由 Service Worker 控制的情況下，應用程式的造訪速度會比非受控制的造訪快得多，即使是回訪者而言，很可能是快取大部分網頁資源的回訪者也一樣。值得注意的是，平均而言，使用服務工作者的行動裝置訪客，比使用桌機的訪客更快載入網頁。

「…由 Service Worker 控管的應用程式造訪，載入速度比未控管的造訪快上許多…。」

如需更多詳細資訊，請參閱下列兩個表格：

平均網頁載入時間 (桌機)
Service Worker 狀態	使用者類型	平均網頁載入時間 (豪秒)	樣本數量
控管	回訪者	2568	30860
有權限	回訪者	3612	1289
有權限	新訪客	4664	21991

平均網頁載入時間 (行動裝置)
Service Worker 狀態	使用者類型	平均網頁載入時間 (豪秒)	樣本數量
控管	回訪者	3760	8162
有權限	回訪者	4843	676
有權限	新訪客	6158	5779

您可能會好奇，如果回訪訪客的瀏覽器支援 Service Worker，會如何一直處於未控制狀態。以下提供幾個可能的原因：

• 使用者在初次造訪時離開網頁，Service Worker 還沒機會完成初始化。
• 使用者透過開發人員工具解除安裝 Service Worker。

這兩種情況都比較少見。我們可以查看第四欄中的「Page Load Sample」值，瞭解資料中的情況。請注意，中間的資料列樣本數量遠低於其他兩列。

第二個問題是：服務工作人員對載入網站的體驗有何影響？

為回答這個問題，我們為指標「平均事件價值」建立了另一份自訂報表，並篩選結果，只納入 firstpaint 事件。我們使用了「裝置類別」維度和自訂的「Service Worker 狀態」維度。

與我預期的結果相反，行動裝置上的服務工作者對首次繪製時間的影響，比整體網頁載入時間還要小。

「...相較於在整體網頁載入上，服務工作人員初次繪製所需時間的影響不大。」

為了瞭解原因，我們必須進一步分析資料。平均值可用於一般概況和大略概述，但要真正瞭解這些數字如何在不同使用者之間細分，我們需要查看 firstpaint 次的時間分布。

在 Google Analytics 中取得指標的分配

如要取得 firstpaint 次數的分布情形，我們需要存取每個事件的個別結果。很抱歉，Google Analytics 無法輕鬆完成這項作業。

Google Analytics 可讓我們依照所需維度細分報表，但無法依指標細分報表。這並非表示無法實現，而是表示我們必須進一步自訂導入方式，才能取得理想結果。

由於報表結果只能依維度細分，因此我們必須將指標值 (在本例中為 firstpaint 時間) 設為事件的自訂維度。為此，我們建立了另一個名為「Metric Value」的自訂維度，並更新 firstpaint 追蹤邏輯，如下所示：

var customDimensions = {
  SERVICE_WORKER_STATUS: 'dimension1',
  <strong>METRIC_VALUE: 'dimension2'</strong>
};

// ...

function sendTimeToFirstPaint() {
  var timeToFirstPaint = getTimeToFirstPaintIfSupported();

  if (timeToFirstPaint) {
    var fields = {
      eventCategory: 'Performance',
      eventAction: 'firstpaint',
      // Rounds to the nearest millisecond since
      // event values in Google Analytics must be integers.
      eventValue: Math.round(timeToFirstPaint)
      // Sends this as a non-interaction event,
      // so it doesn't affect bounce rate.
      nonInteraction: true
    }

    <strong>// Sets the event value as a dimension to allow for breaking down the
    // results by individual metric values at reporting time.
    fields[customDimensions.METRIC_VALUE] = String(fields.eventValue);</strong>

    ga('send', 'event', fields);
  }
}

Google Analytics 網頁版介面目前無法提供任意指標值的視覺化資料分布，但我們可以利用 Google Analytics Core Reporting API 和 Google 圖表程式庫，查詢原始結果，然後自行建立直方圖。

舉例來說，下列 API 要求設定是用來透過非受管的 Service Worker 取得電腦上的 firstpaint 值分佈情形。

{
  dateRanges: [{startDate: '2016-05-16', endDate: '2016-05-22'}],
  metrics: [{expression: 'ga:totalEvents'}],
  dimensions: [{name: 'ga:dimension2'}],
  dimensionFilterClauses: [
    {
      operator: 'AND',
      filters: [
        {
          dimensionName: 'ga:eventAction',
          operator: 'EXACT',
          expressions: ['firstpaint']
        },
        {
          dimensionName: 'ga:dimension1',
          operator: 'EXACT',
          expressions: ['supported']
        },
        {
          dimensionName: 'ga:deviceCategory',
          operator: 'EXACT',
          expressions: ['desktop']
        }
      ],
    }
  ],
  orderBys: [
    {
      fieldName: 'ga:dimension2',
      orderType: 'DIMENSION_AS_INTEGER'
    }
  ]
}

這個 API 要求會傳回值陣列，如下所示 (注意：這只是前五個結果)。結果會由小到大排序，因此這些資料列代表最快的執行時間。

API 回應結果 (前五列)
ga:dimension2	ga:totalEvents
4	3
5	2
6	10
7	8
8	10

以下是這些結果的簡單說明：

• 有 3 個事件的 firstpaint 值為 4 毫秒
• 有 2 個事件的 firstpaint 值為 5 毫秒
• 有 10 個事件的 firstpaint 值為 6 毫秒
• 有 8 個事件的 firstpaint 值為 7 毫秒
• 有 10 個事件，firstpaint value 為 8 毫秒
• 其他

我們可以根據這些結果推算每個事件的 firstpaint 值，並建立分布直方圖。我們也對每個執行的查詢執行這項操作。

以下是電腦上使用未控管 (但支援) 的 Service Worker 時，發布情形如下：

上述分布的 firstpaint 中位時間為 912 毫秒。

這條曲線的形狀是負載時間分布的典型形狀。請比較下方的直方圖，該圖顯示服務工作者控制網頁時，首次繪製事件的分布情形。

請注意，當服務工作處理程序控制網頁時，許多訪客都遇到了近乎立即的首次繪製，中位數為 583 毫秒。

「…當 Service Worker 控制網頁時，許多訪客都會立即看到第一個畫面…

為了讓您更清楚瞭解這兩種分布情形的差異，下圖顯示兩者合併後的資料。顯示未受控服務工作者造訪次數的直方圖，會疊加在顯示受控造訪次數的直方圖上方，而這兩者會疊加在顯示兩者總和的直方圖上方。

我發現這些結果有個有趣之處，就是在初始尖峰過後，使用受控服務工作的分布仍呈現鐘形曲線。我原本預期初期激增，然後循序漸進，也沒想到曲線的第二個高峰。

在調查可能導致這個問題的原因時，我發現即使 Service Worker 可以控制網頁，但其執行緒可能處於停用狀態。瀏覽器會這麼做是為了節省資源 - 您不需要每個造訪過的網站都啟用服務工作者，讓服務工作者隨時都能運作。這就是分布圖尾端的情況。部分使用者在服務工作者執行緒啟動時，會發生延遲現象。

不過，從分布圖中可以看到，即使有這段初始延遲時間，使用服務工作者的瀏覽器仍比透過網路的瀏覽器更快地提供內容。

以下是行動版的顯示方式：

雖然我們仍大幅提升了近乎即時的首次顯示時間，但尾端的時間變得更長、更大。這可能是因為在行動裝置上啟動空閒服務 worker 執行緒的時間，比在電腦上啟動所需的時間還要長。這也說明瞭為何平均 firstpaint 時間的差異沒有我預期的明顯 (如上所述)。

「在行動裝置上，啟動閒置服務工作站執行緒的時間比在電腦上還要長。」

以下是行動版和電腦版的首繪時間中位數，並依服務工作者狀態分組：

畫面首次顯示所需時間中位數 (毫秒)
Service Worker 狀態	電腦	行動裝置
控管	583	1634
支援 (未控制)	912	1933

雖然建立這些發布示意圖的時間和心力比在 Google Analytics 中建立自訂報表多了一些，但這比單純查看平均值更能讓我們瞭解服務工作者對網站效能的影響。

Service Worker 的其他影響

除了效能影響之外，服務工作處理程序也會以 Google Analytics 可評估的其他方式影響使用者體驗。

離線存取

服務工作處理程序可讓使用者離線與您的網站互動，有些漸進式網頁應用程式可能十分重要，但還是要判斷離線應用程式有多重要，主要取決於離線使用情形。但我們要如何評估這項指標呢？

您必須連上網際網路，才能將資料傳送至 Google Analytics，但不需要在互動發生的確切時間傳送資料。Google Analytics 支援在事後傳送互動資料，方法是指定時間偏移 (透過 qt 參數)。

過去兩年，IOWA 一直使用服務工作者指令碼，在使用者離線時偵測 Google Analytics 的失敗命中，並稍後透過 qt 參數重播這些命中。

為了追蹤使用者在線上或離線，我們建立了名為「線上」的自訂維度，並將其設為 navigator.onLine 的值，然後監聽 online 和 offline 事件，並據此更新維度。

為了瞭解使用者在使用 IOWA 時處於離線狀態的頻率，我們建立了區隔，鎖定至少有一次離線互動的使用者。結果，幾乎 5% 的使用者

推播通知

服務工作者可讓使用者選擇接收推播通知。在 IOWA 中，使用者會在行事曆中的工作階段即將開始時收到通知。

無論是哪種形式的通知，都必須在為使用者提供價值與避免打擾使用者之間取得平衡。為了進一步瞭解發生哪種情況，請務必追蹤使用者是否選擇接收這些通知、是否在抵達時與通知互動，以及先前選擇接收通知的使用者是否變更偏好設定並選擇不接收。

在 IOWA 中，我們只會傳送與使用者個人化行程相關的通知，而這類行程只能由已登入的使用者建立。這項設定會限制可向已登入的使用者 (透過「已登入」自訂維度追蹤) 且瀏覽器支援推播通知 (透過另一個稱為「通知權限」的自訂維度追蹤) 的使用者。

以下報表是根據指標「使用者」和「通知權限」自訂維度，以區隔出在某個時間點登入且瀏覽器支援推播通知的使用者。

很高興看到登入的使用者中有半數以上選擇接收推播通知。

應用程式安裝橫幅

如果漸進式網頁應用程式符合條件，且使用者經常使用，系統可能會向使用者顯示應用程式安裝橫幅，提示他們將應用程式新增到主畫面。

在 IOWA 中，我們使用以下程式碼追蹤這些提示向使用者顯示的頻率 (以及使用者是否接受提示)：

window.addEventListener('beforeinstallprompt', function(event) {
  // Tracks that the user saw a prompt.
  ga('send', 'event', {
    eventCategory: 'installprompt',
    eventAction: 'fired'
  });

  event.userChoice.then(function(choiceResult) {
    // Tracks the users choice.
    ga('send', 'event', {
      eventCategory: 'installprompt',
      // `choiceResult.outcome` will be 'accepted' or 'dismissed'.
      eventAction: choiceResult.outcome,
      // `choiceResult.platform` will be 'web' or 'android' if the prompt was
      // accepted, or '' if the prompt was dismissed.
      eventLabel: choiceResult.platform
    });
  });
});

在看到應用程式安裝橫幅的使用者中，約 10% 選擇將應用程式新增至主畫面。

可能的追蹤改善方式 (下次可參考)

我們今年從 IOWA 收集到的數據分析資料非常寶貴。但事後總是能發現漏洞，並有助於在下次執行時改善。完成今年的分析後，我發現有兩個地方可以改進，希望有意採用類似策略的讀者不妨參考：

1. 追蹤更多與載入體驗相關的事件

我們追蹤了幾個與技術指標相對應的事件 (例如 HTMLImportsLoaded、WebComponentsReady 等)，但由於大部分的載入作業都是非同步執行，因此這些事件觸發的時機不一定與整體載入體驗中的特定時刻相對應。

我們未追蹤的主要載入相關事件 (但希望能追蹤) 是啟動畫面消失，使用者可看到網頁內容的時間點。

2. 將 Analytics 用戶端 ID 儲存在 IndexedDB 中

根據預設，analytics.js 會在瀏覽器的 Cookie 中儲存 Client-ID 欄位；但可惜的是，Service Worker 指令碼無法存取 Cookie。

我們嘗試執行通知追蹤功能時，可能會出現問題。我們希望每次向使用者傳送通知時，都能透過評估資料協定從服務工作者傳送事件，然後在使用者點選通知並返回應用程式時，追蹤該通知的再參與成效。

雖然我們可以透過 utm_source 廣告活動參數追蹤通知的成功率，但無法將特定再參與活動階段與特定使用者建立關聯。

我們可以透過 IndexedDB 在追蹤程式碼中儲存用戶端 ID，藉此解決這個限制，這樣服務工作者指令碼就能存取這個值。

3. 讓服務工作人員回報線上/離線狀態

檢查 navigator.onLine 可讓您瞭解瀏覽器是否能連線至路由器或區域網路，但不一定能讓您瞭解使用者是否有實際連線。此外，由於離線分析服務工作工作指令碼只是重播失敗的命中 (沒有修改或標示為失敗)，因此我們回報的離線用量可能不足。

日後，我們應同時追蹤 navigator.onLine 的狀態，以及系統是否因初始網路故障而由服務工作者重播命中。這麼做有助於我們更準確地掌握實際的離線使用情形。

設定程序即將完成

本案例研究顯示，使用服務工作者確實可改善 Google I/O 網頁應用程式在多種瀏覽器、網路和裝置上的載入效能。研究也顯示，當您查看各種瀏覽器、網路和裝置的載入資料分布情形時，就能更深入瞭解這項技術如何處理實際情境，並發現您可能未預期到的效能特徵。

以下是 IOWA 研究的重點：

• 平均來說，在 Service Worker 控制網頁的情況下，網頁的載入速度會比沒有 Service Worker 時快上許多，這一點在新訪客和回訪者身上都適用。
• 許多使用者造訪由 Service Worker 控管的網頁時，幾乎立即載入。
• Service Worker 處於閒置狀態時，需要一點時間啟動。但閒置的 Service Worker 的效能仍優於沒有 Service Worker。
• 閒置服務 worker 在行動裝置上的啟動時間比在電腦上的啟動時間長。

雖然在特定應用程式中觀察到的成效提升通常有助於向更廣大的開發人員社群回報，但請務必記住，這些結果是針對 IOWA 的網站類型 (活動網站) 和 IOWA 的目標對象類型 (大多為開發人員) 而定。

如果您在應用程式中導入服務工作者，請務必實作自己的評估策略，以便評估自己的成效，並防止未來發生回歸現象。如果願意，請分享結果，讓大家從中受益！

註釋

1. 與其比較服務工作處理程序快取的效能，與我們只使用 HTTP 快取的效能比較網站的效能並不公平。由於我們是為了服務工作者而最佳化 IOWA，因此並未花費太多時間進行 HTTP 快取最佳化。如果我們有，結果可能會有所不同。如要進一步瞭解如何針對 HTTP 快取最佳化網站，請參閱「有效地最佳化內容」。
2. 視網站載入樣式和內容的方式而定，瀏覽器可能會在內容或樣式可用之前進行繪製。在這種情況下，firstpaint 可能對應空白畫面。如果您使用 firstpaint，請務必確保該事件與網站資源載入過程中的有意義點相符。
3. 從技術層面來說，我們可以傳送時間記錄 (預設為非互動)，擷取這項資訊，而非事件。事實上，Google Analytics 中的時間戳記是專門用來追蹤這類載入指標；不過，時間戳記會在處理期間大量取樣，因此其值無法用於區隔。基於目前的限制，非互動事件仍更適合。
4. 如要進一步瞭解在 Google Analytics 中設定自訂維度的範圍，請參閱 Analytics 說明中心的「自訂維度」一節。此外，瞭解 Google Analytics 資料模型，其中包含使用者、工作階段和互動 (命中)。如要進一步瞭解，請觀看 Analytics Academy 的 Google Analytics 資料模型課程。
5. 這不會計算在載入事件後延後載入的資源。