Teste eine neue Lighthouse API, um die Leistung und Best Practices während des gesamten Nutzerflusses zu messen.
Lighthouse ist ein fantastisches Tool, um die Leistung und Best Practices beim ersten Seitenaufbau zu testen. Früher war es jedoch schwierig, mit Lighthouse weitere Aspekte der Lebensdauer einer Seite zu analysieren, zum Beispiel:
- Seite wird mit warmem Cache geladen
- Seiten mit einem aktivierten Service Worker
- Berücksichtigung potenzieller Nutzerinteraktionen
Das bedeutet, dass Lighthouse wichtige Informationen nicht erfassen kann. Die Core Web Vitals basieren auf allen Seitenladevorgängen und nicht nur auf Seitenladevorgängen mit leerem Cache. Darüber hinaus sind Messwerte wie Cumulative Layout Shift (CLS) für die gesamte Zeit messbar, während die eine Seite geöffnet ist.
Lighthouse hat eine neue User Flow API, mit der zu jedem Zeitpunkt innerhalb der Lebensdauer einer Seite Labortests durchgeführt werden können. Puppeteer wird verwendet, um Skripte für den Seitenaufbau zu erstellen und synthetische Nutzerinteraktionen auszulösen. Lighthouse kann auf verschiedene Arten aufgerufen werden, um wichtige Erkenntnisse während dieser Interaktionen zu erfassen. Das bedeutet, dass die Leistung beim Seitenaufbau und während Interaktionen mit der Seite gemessen werden kann. Barrierefreiheitsprüfungen können in CI nicht nur in der ersten Ansicht, sondern auch tief in Ihrem Bezahlvorgang durchgeführt werden. So lässt sich sicherstellen, dass nichts zurückgeht.
Nahezu jedes Puppeteer-Skript, das für einen funktionierenden User Flow geschrieben wird, kann jetzt jederzeit mit Lighthouse eingebunden werden, um die Leistung und Best Practices durchgehend zu messen. In diesem Tutorial lernen Sie die neuen Lighthouse-Modi kennen, mit denen verschiedene Teile des Nutzerflusses gemessen werden können: Navigationen, Momentaufnahmen und Zeitspannen.
Einrichtung
Die Nutzerfluss-APIs befinden sich noch in der Vorabversion, sind aber bereits in Lighthouse verfügbar. Sie benötigen Node 14 oder höher, um die folgenden Demos auszuprobieren. Erstellen Sie ein leeres Verzeichnis und führen Sie darin folgenden Befehl aus:
# 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
Navigation
Der neue Lighthouse-Navigationsmodus gibt dem bisher (bisher) Standard-Lighthouse-Verhalten einen Namen: das Analysieren des kalten Ladevorgangs einer Seite. Mit diesem Modus können Sie die Leistung beim Seitenaufbau überwachen. Die Aufrufabfolge von Webseiten eröffnet jedoch auch neue Erkenntnisse.
So erstellen Sie ein Script, das den Seitenaufbau in Lighthouse erfasst:
- Öffne den Browser mit Puppenspieler.
- Erstellen Sie einen Lighthouse-Nutzerfluss.
- Rufen Sie die Ziel-URL auf.
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();
Dies ist der einfachste Ablauf. Nach dem Öffnen wird eine Zusammenfassungsansicht mit nur einem Schritt angezeigt. Wenn Sie auf diesen Schritt klicken, wird ein traditioneller Lighthouse-Bericht für diese Navigation angezeigt.
Wie in Lighthouse üblich, wird diese Seite mit leerem Cache oder lokalem Speicher geladen, aber echte Nutzer, die eine Website besuchen, haben eine Mischung aus Besuchen mit kalten und warmen Caches, und zwischen einem Kaltladevorgang wie diesem und einem Nutzer, der mit einem noch warmen Cache zur Seite zurückkehrt, kann ein großer Leistungsunterschied bestehen.
Warme Last erfassen
Sie können diesem Skript auch eine zweite Navigation hinzufügen, um diesmal das Leeren des Caches und das Leeren des Speichers zu deaktivieren, das in Lighthouse standardmäßig in den Navigationen geschieht. Im nächsten Beispiel wird ein Artikel auf web.dev geladen, um zu sehen, wie stark das Speichern im Cache profitiert:
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();
Der resultierende Flussbericht sieht in etwa so aus:
Die Kombination aus kalten und warmen Ladevorgängen bietet ein umfassenderes Bild von den Erfahrungen echter Nutzer. Wenn Sie eine Website haben, auf der Nutzer während eines Besuchs viele Seiten laden, erhalten Sie auf diese Weise möglicherweise einen realistischeren Einblick in ihre Erfahrungen.
Snapshots
Snapshots sind ein neuer Modus, in dem Lighthouse-Audits zu einem einzigen Zeitpunkt ausgeführt werden. Anders als bei einer normalen Ausführung von Lighthouse wird die Seite nicht neu geladen. Dadurch wird die Möglichkeit eröffnet, eine Seite einzurichten und im genauen Zustand zu testen, beispielsweise mit einem geöffneten Drop-down-Menü oder einem teilweise ausgefüllten Formular.
Angenommen, Sie möchten überprüfen, ob eine neue Benutzeroberfläche für Erweiterte Einstellungen in Squoosh die automatisierten Lighthouse-Prüfungen besteht. Diese Einstellungen sind nur sichtbar, wenn ein Bild geladen wurde und das Optionsmenü erweitert wurde, um die erweiterten Einstellungen anzuzeigen.
Dieser Vorgang kann mit Puppeteer ausgeführt werden und Sie können bei jedem Schritt einen Lighthouse-Snapshot erstellen:
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();
Der resultierende Bericht zeigt, dass die Ergebnisse im Allgemeinen gut sind, aber es gibt möglicherweise einige Kriterien zur Barrierefreiheit, die manuell geprüft werden müssen:
Zeitspannen
Einer der größten Unterschiede zwischen den Leistungsergebnissen in diesem Bereich (z. B. von CrUX) und im Lab (z. B. Lighthouse) ist der Mangel an Nutzereingaben. Hier kann eine Zeitspanne – der letzte User Flow-Modus – helfen.
Für einen Zeitraum werden Lighthouse-Prüfungen über einen bestimmten Zeitraum durchgeführt, die eine Navigation enthalten können oder nicht. So lässt sich gut erfassen, was bei Interaktionen auf einer Seite passiert. In Lighthouse wird beispielsweise standardmäßig beim Seitenaufbau der CLS-Wert gemessen. In diesem Fall wird der CLS-Wert jedoch von der ersten Navigation bis zum Schließen der Seite gemessen. Wenn Nutzerinteraktionen der Auslöser von CLS sind, war das in Lighthouse bisher nicht möglich.
Hier ist eine Testwebsite, die simuliert, wie Werbung beim Scrollen in einen Artikel eingeschleust wird, ohne dass Platz dafür reserviert wird. Bei einer langen Reihe von Karten wird gelegentlich ein rotes Quadrat hinzugefügt, wenn die Anzeigenfläche in den Darstellungsbereich gelangt. Da für diese roten Quadrate kein Platz reserviert war, werden die Karten darunter verschoben, was zu Layoutverschiebungen führt.
Eine normale Lighthouse-Navigation hat einen CLS von 0. Allerdings kommt es beim Scrollen auf der Seite zu problematischen Layoutverschiebungen und der CLS-Wert wird ansteigen.
Das folgende Skript erstellt einen Bericht zum Nutzerfluss mit beiden Aktionen, um den Unterschied aufzuzeigen.
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();
Dadurch wird ein Bericht erstellt, in dem eine normale Navigation mit einer Zeitspanne verglichen wird, die sowohl eine Navigation als auch das nachfolgende Scrollen enthält:
Bei jedem Schritt wird für die Navigation als CLS 0 angezeigt. Tolle Website!
Der Schritt „Navigation und Scrollen“ erzählt jedoch eine andere Geschichte. Derzeit sind nur „Total Blocking Time“ und „Cumulative Layout Shift“ für Zeiträume verfügbar. Durch den Lazy-Loading-Inhalt auf dieser Seite wird jedoch die CLS für die Website deutlich reduziert.
Bisher war Lighthouse nicht in der Lage, dieses problematische CLS-Verhalten zu identifizieren, obwohl es mit hoher Wahrscheinlichkeit von echten Nutzern erkannt werden würde. Durch Leistungstests an skriptbasierten Interaktionen wird die Genauigkeit im Labor deutlich verbessert.
Feedback wird gesucht
Mit den neuen Nutzerfluss-APIs in Lighthouse können Sie viel Neues tun. Dennoch kann es schwierig sein, die verschiedenen Szenarien zu messen, die für Nutzer auftreten.
Bei Fragen können Sie die Lighthouse-Diskussionsforen nutzen. Fehler oder Vorschläge können Sie im Issue Tracker melden.