試用新的 Lighthouse API，評估整個使用者流程的效能和最佳做法。
Lighthouse 是測試效能和最佳做法的絕佳工具，可在初始頁面載入期間執行。然而，傳統上很難使用 Lighthouse 分析網頁生命週期的其他方面，例如：
- 使用暖快取載入頁面
- 含已啟用 Service Worker 的網頁
- 考量潛在的使用者互動
換句話說，Lighthouse 可能會遺漏重要資訊。網站體驗核心指標是以「所有」網頁載入為依據，而不只是含有空白快取的網頁。此外，系統也會在整個網頁開啟期間評估累計版面配置位移 (CLS) 等指標。
Lighthouse 提供新的使用者流程 API，可讓您在網頁效期內隨時進行研究室測試。Puppeteer 會用於編寫頁面載入指令碼，並觸發合成使用者互動，Lighthouse 可在這些互動期間透過多種方式叫用，以擷取重要的深入分析資訊。也就是說，您可以在網頁載入期間「以及」與網頁互動時評估成效。無障礙功能檢查可在 CI 中執行，而不只是在初始檢視畫面上，也能深入結帳程序，確保不會發生迴歸問題。
幾乎所有為確保能正常運作的使用者流程撰寫的 Puppeteer 指令碼現在都可隨時插入 Lighthouse 功能，以便評估整個應用程式的效能和最佳做法。本教學課程將逐步介紹全新的 Lighthouse 模式，它可以評估使用者流程的不同部分：導覽、快照和時間範圍。
設定
使用者流程 API 仍為預先發布版，但目前可在 Lighthouse 中使用。如要試用下方的示範，您必須使用 Node 14 以上版本。建立一個空白目錄，並使用該目錄：
# Default to ES modules.
echo '{"type": "module"}' > package.json
# Init npm project without the wizard.
npm init -y
# Dependencies for these examples.
npm install lighthouse puppeteer open
導覽
新的 Lighthouse 「導覽」模式實際為 (直到現在) 標準 Lighthouse 行為命名：分析網頁的冷載入。透過這種模式監控網頁載入成效，但使用者流程也有助於發掘新的洞察資料。
如何編寫 Lighthouse 擷取網頁載入指令碼：
- 使用 Puppete 開啟瀏覽器。
- 啟動 Lighthouse 使用者流程。
- 前往目標網址。
import fs from 'fs';
import open from 'open';
import puppeteer from 'puppeteer';
import {startFlow} from 'lighthouse/lighthouse-core/fraggle-rock/api.js';
async function captureReport() {
const browser = await puppeteer.launch({headless: false});
const page = await browser.newPage();
const flow = await startFlow(page, {name: 'Single Navigation'});
await flow.navigate('https://web.dev/performance-scoring/');
await browser.close();
const report = await flow.generateReport();
fs.writeFileSync('flow.report.html', report);
open('flow.report.html', {wait: false});
}
captureReport();
這是最簡單的流程。開啟後，報表會顯示摘要檢視畫面，只包含一個步驟。按一下該步驟，即可顯示該導覽的傳統 Lighthouse 報告。
如同 Lighthouse 一般，系統會先載入這個網頁，並且先清除所有快取或本機儲存空間，但是實際造訪網站的使用者會混合使用冷載入和熱快取。因此，這類冷負載和使用者返回使用靜止快取的網頁之間，可能會有極大的成效差異。
擷取暖負載
您還可以為此指令碼新增第二個導覽，這次停用 Lighthouse 在導覽中預設會執行的快取和儲存空間作業。接下來的例子會載入 web.dev 上的文章，瞭解快取對快取有多大幫助：
async function captureReport() {
const browser = await puppeteer.launch({headless: false});
const page = await browser.newPage();
const testUrl = 'https://web.dev/performance-scoring/';
const flow = await startFlow(page, {name: 'Cold and warm navigations'});
await flow.navigate(testUrl, {
stepName: 'Cold navigation'
});
await flow.navigate(testUrl, {
stepName: 'Warm navigation',
configContext: {
settingsOverrides: {disableStorageReset: true},
},
});
await browser.close();
const report = await flow.generateReport();
fs.writeFileSync('flow.report.html', report);
open('flow.report.html', {wait: false});
}
captureReport();
產生的流程報表如下所示：
「冷載入」和「暖載入」的組合可讓您更全面地瞭解使用者遭遇的情況。如果您有一個網站會讓使用者在同一次造訪中載入多個網頁，您或許就能更實際地瞭解使用者在當下面臨的情形。
快照
快照功能是一種新模式，可以在單一時間點執行 Lighthouse 稽核。與正常 Lighthouse 執行不同的是，頁面不會重新載入，也開放網頁設定，並測試網頁的確切狀態，例如開啟下拉式選單或部分填入表單。
在此範例中，假設您要檢查 Squoosh 中是否有部分進階設定新 UI 已通過自動的 Lighthouse 檢查。只有在圖片已載入，且選項選單展開後顯示進階設定時，系統才會顯示這些設定。
透過 Puppeteer 編寫這個程序，而且您可以在每個步驟實際拍攝 Lighthouse 快照：
async function captureReport() {
const browser = await puppeteer.launch({headless: false});
const page = await browser.newPage();
const flow = await startFlow(page, {name: 'Squoosh snapshots'});
await page.goto('https://squoosh.app/', {waitUntil: 'networkidle0'});
// Wait for first demo-image button, then open it.
const demoImageSelector = 'ul[class*="demos"] button';
await page.waitForSelector(demoImageSelector);
await flow.snapshot({stepName: 'Page loaded'});
await page.click(demoImageSelector);
// Wait for advanced settings button in UI, then open them.
const advancedSettingsSelector = 'form label[class*="option-reveal"]';
await page.waitForSelector(advancedSettingsSelector);
await flow.snapshot({stepName: 'Demo loaded'});
await page.click(advancedSettingsSelector);
await flow.snapshot({stepName: 'Advanced settings opened'});
browser.close();
const report = await flow.generateReport();
fs.writeFileSync('flow.report.html', report);
open('flow.report.html', {wait: false});
}
captureReport();
產生的報告顯示結果通常不錯，但可能有一些無障礙功能需要手動查看：
時間範圍
使用者在實地 (例如 CrUX) 和研究室 (例如 Lighthouse) 的效能結果最大的差異之一，就是缺乏使用者輸入內容。這時，使用者流程模式 (最終使用者流程模式) 就能派上用場。
時間範圍會每隔一段時間執行 Lighthouse 稽核，但不一定會包含導航功能。這個方法非常適合用來記錄網頁的互動期間發生的情況。例如，Lighthouse 預設會在網頁載入期間測量 CLS，但在該欄位中，系統會從初始瀏覽作業測量 CLS，直到網頁關閉為止。如果使用者互動是觸發 CLS 的原因，Lighthouse 原本無法擷取到並協助修正。
這裡有個測試網站會模擬捲動時插入文章，而且預留廣告空間。在多張資訊卡中，當版位進入可視區域時，偶爾會加入紅色的正方形。由於這些紅色方塊沒有保留空間，因此其下方的資訊卡會移位，導致版面配置位移。
一般的 Lighthouse 導航項目 CLS 為 0。然而，捲動頁面後，網頁的版面配置位移會發生問題，導致 CLS 值上升。
以下指令碼會產生內含這兩項操作的使用者流程報表，以顯示差異。
async function captureReport() {
const browser = await puppeteer.launch({headless: false});
const page = await browser.newPage();
// Get a session handle to be able to send protocol commands to the page.
const session = await page.target().createCDPSession();
const testUrl = 'https://pie-charmed-treatment.glitch.me/';
const flow = await startFlow(page, {name: 'CLS during navigation and on scroll'});
// Regular Lighthouse navigation.
await flow.navigate(testUrl, {stepName: 'Navigate only'});
// Navigate and scroll timespan.
await flow.startTimespan({stepName: 'Navigate and scroll'});
await page.goto(testUrl, {waitUntil: 'networkidle0'});
// We need the ability to scroll like a user. There's not a direct puppeteer function for this, but we can use the DevTools Protocol and issue a Input.synthesizeScrollGesture event, which has convenient parameters like repetitions and delay to somewhat simulate a more natural scrolling gesture.
// https://chromedevtools.github.io/devtools-protocol/tot/Input/#method-synthesizeScrollGesture
await session.send('Input.synthesizeScrollGesture', {
x: 100,
y: 600,
yDistance: -2500,
speed: 1000,
repeatCount: 2,
repeatDelayMs: 250,
});
await flow.endTimespan();
await browser.close();
const report = await flow.generateReport();
fs.writeFileSync('flow.report.html', report);
open('flow.report.html', {wait: false});
}
captureReport();
這會產生一份報表，比較一般導覽和後續捲動兩者的時間範圍：
深入探索每個步驟，僅限導覽的步驟顯示 CLS 為 0。太棒了！
但「導覽及捲動」步驟呈現的是不同故事。目前，「總封鎖時間」和「累計版面配置位移」可提供時間範圍，但本頁上的延遲載入內容會清楚扭曲網站的 CLS。
Lighthouse 原本無法辨識這類有問題的 CLS 行為，但幾乎可以確實出現在實際使用者體驗中。針對有腳本的互動測試效能，可大幅提升實驗室的擬真度。
正在尋找意見回饋
Lighthouse 中的全新使用者流程 API 可以執行許多新工作，但要評估使用者遇到的各種情境仍可能並不容易。
如有任何問題，請前往 Lighthouse 討論論壇提問，並透過 Issue Tracker 回報任何錯誤或建議。