評估購物漏斗中每個階段成效的策略。
購物漏斗的不同步驟很容易以不同方式產生效能問題，因此需要不同的評估和最佳化設定：
本指南將說明不同步驟的評估方式。因此，建議您查看研究室以及實際環境資料。
研究室資料是藉由在本機執行測試 (例如使用 Lighthouse 和其他工具) 而收集而來。這可讓您透過受管控的穩定環境，比較長期網站及競爭對手的網站效能，但可能無法反映使用者實際使用時的體驗。
欄位資料是透過實際使用者的數據分析收集而來，因此代表他們的體驗。但是，要比較長期或競爭對手並不容易。網路連線和智慧型手機硬體會隨時間演變，且不同的目標對象可能使用不同的裝置，因此比較實際的資料相當困難。另請參閱「評估實際成效」一文。
為了呈現完整資訊，您必須同時提供兩種資料來源。以下各節說明如何針對整個漏斗中不同相關效能標記的研究室和欄位資料。
探索廣告活動
針對探索進行最佳化，是指針對首次載入作業進行最佳化，這是新使用者會獲得的體驗，同時也適用於搜尋和社交檢索器。您可以透過 Lighthouse 輕鬆取得首次載入的研究室資料，至少可用 Chrome 使用者體驗報告取得現場資料 (至少適用於 Chrome)。您可以在 PageSpeed Insights 中瞭解兩者的便利組合。此外，您也應自行從欄位追蹤相關指標：在實際使用者裝置上評估這些指標提供簡單明瞭的總覽，
從使用者的角度來看，最重要的指標如下：
- 首次顯示內容所需時間 (FCP)：使用者註視空白畫面的時間。這會導致大多數使用者跳出，因為他們看不到進度。
- 首次有意義的繪製 (FMP)：使用者開始看到他們想要的主要內容時。這通常是主頁橫幅，但就到達網頁而言，它甚至也可以是「購買」按鈕等行動號召，因為使用者可能已產生明確意圖 (例如透過指定廣告活動)。
- 首次輸入延遲時間 (FID)：網站需要回應使用者首次輸入內容的時間。JavaScript 和其他素材資源載入問題過多可能會遭到封鎖，導致輕觸或點擊失敗、輸入錯誤以及網頁放棄。
你還能查看更多指標，但這些是很好的基準。此外，請務必擷取跳出率、轉換和使用者參與度，以便您以指定目標為依據進行設定。
參與和轉換
第一次載入到達網頁後，使用者會進入您的網站，有機會成功完成轉換。
在這個階段，提供快速回應的導覽和互動體驗至關重要。然而，評估欄位中導覽和互動事件的完整流程並不容易，因為每位使用者在各個頁面中都有不同的路徑。因此，建議您在研究室測試中編寫指令碼及評估流程，藉此評估達成轉換或轉換子目標所需的時間 (下稱「操作時間」)，以便比較一段時間或與競爭對手的效能。
方法有以下兩種：
WebPageTest
WebPageTest 提供極具彈性的指令碼指令碼解決方案。基本概念是：
- 指示 WebPageTest 使用
navigate指令瀏覽流程頁面。 - 視需要透過
clickAndWait指令點選按鈕的指令碼，並透過setValue填入文字欄位。如要測試單一頁面應用程式，請在第一個步驟後使用clickAndWait(而非navigate指令)，因為navigate會執行完整載入，而非輕量的虛擬頁面載入。 - 請務必透過
combineSteps結合分析中不同的流程步驟，為完整流程產生單一整體結果報表。
這類指令碼可能如下所示：
combineSteps
navigate https://www.store.google.com/landingpage
navigate https://www.store.google.com/productpage
clickAndWait innerText=Buy Now
navigate https://www.store.google.com/basket
navigate https://www.store.google.com/checkout
有了這樣的指令碼，您就能輕鬆評估及比較長期效能。您也可以透過 WebPageTest API 自動執行這項作業。
布偶操作員
另一個執行指令碼測試的絕佳選項，是使用無頭 Chrome，並透過 Node API Puppeteer 控制。一般而言，我們會透過 Puppeteer 啟動瀏覽器、透過 goto 函式前往到達網頁、插入 JavaScript 填入欄位，或點按按鈕，然後視需要完成後續的呼叫呼叫。
您可以直接測量流程持續時間的指標，但您也可以加總流程中個別載入的 FCP、FMP 或 TTI 值。使用 Puppeteer 測試網站效能提供說明如何透過 Puppeteer 取得成效指標的總覽。簡易的 Node 指令碼範例可能如下所示：
const puppeteer = require('puppeteer');
(async () => {
const browser = await puppeteer.launch();
const page = await browser.newPage();
const start = performance.now();
await page.goto('https://www.store.google.com/landingpage');
await page.goto('https://www.store.google.com/productpage');
// click the buy button, which triggers overlay basket
await page.click('#buy_btn');
// wait until basket overlay is shown
await page.waitFor('#close_btn');
await page.goto('https://www.store.google.com/basket');
await page.goto('https://www.store.google.com/checkout');
console.log('Flow took ' + parseInt((performance.now() - start)/1000) + ' seconds');
await browser.close();
})();
這個指令碼很容易自動化，甚至是建構程序或效能預算的一部分，並且定期監控。
再次互動
使用者會在不同的時間間隔回訪網站。視傳遞的時間而定，瀏覽器快取的網站資源可能較少，需要更多網路要求。因此很難預估檢驗測試中多次造訪的效能差異。不過，我們仍建議您密切留意這種情況，而 WebPageTest 也很適合用來吸引回流造訪，後者有提供直接重複造訪的專屬選項：
為了改善欄位的重複造訪效能，請使用您選用的數據分析套件，按使用者類型區隔成效指標。以下是 Google Analytics (分析) 報表的範例：
這類報表也會提供新使用者和回訪者的網頁載入時間。
重點回顧
本指南說明如何透過現場和研究室測試，評估初次負載、流程及重複負載。請務必據此調整漏斗的不同步驟，盡可能增加探索 (首次載入)、參與 (導覽和流程) 和再參與 (重複載入) 次數。