试用新的 Lighthouse API，以衡量整个用户流中的性能和最佳做法。
Lighthouse 是一款出色的工具，用于在初始页面加载期间测试性能和最佳做法。不过，一直以来，我们很难使用 Lighthouse 来分析网页生命周期的其他方面，例如：
- 使用热缓存加载网页
- 具有已激活 Service Worker 的页面
- 考虑潜在的用户互动
这意味着 Lighthouse 可能会错过重要信息。核心网页指标的计算依据是所有网页加载，而不仅仅是缓存为空的网页加载。此外，在网页打开的整个时间内，Cumulative Layout Shift (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 中高级设置的某些新界面是否通过了 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。非常棒的网站！
不过，“导航和滚动”却讲述了另一番故事。目前，时间跨度中只有 Total Blocking Time 和 Cumulative Layout Shift，但此网页上的延迟加载内容显然会导致网站的 CLS。
以前，Lighthouse 无法识别这种有问题的 CLS 行为，尽管它几乎肯定会在真实用户的体验中出现。基于脚本交互进行性能测试可显著提高实验室保真度。
寻求反馈
Lighthouse 中新的用户流 API 可以执行许多新功能，但衡量用户遇到的场景可能仍然很复杂。