試用新的 Lighthouse API，評估整個使用者流程的效能和最佳做法。
Lighthouse 是絕佳工具，可用來測試初始載入網頁期間的效能和最佳做法。不過，以往很難使用 Lighthouse 分析網頁生命週期的其他層面，例如：
- 載入網頁 (快取已預熱)
- 已啟用 Service Worker 的網頁
- 將潛在使用者互動納入考量
這表示 Lighthouse 可能會遺漏重要資訊。Core Web Vitals 是根據所有網頁載入作業計算，而非僅限快取空白的網頁。此外，累計版面配置位移 (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 擷取網頁載入作業，請按照下列步驟操作：
- 使用 Puppeteer 開啟瀏覽器。
- 啟動 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.example.com/';
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。很棒的網站！
不過，「瀏覽和捲動」步驟顯示的結果卻截然不同。目前只有 Total Blocking Time 和 Cumulative Layout Shift 可在時間範圍內使用，但這個網頁上的延遲載入內容顯然會降低網站的 CLS。
過去，Lighthouse 無法辨識這種有問題的 CLS 行為，但實際使用者幾乎一定會遇到這種情況。透過指令碼互動進行效能測試，可大幅提升實驗室擬真度。
徵求意見回饋
Lighthouse 的新版使用者流程 API 可執行許多新功能，但要評估使用者遇到的情境，可能還是很複雜。
如有任何問題，請前往 Lighthouse 討論論壇提問，並在 Issue Tracker 中提交任何錯誤或建議。