Essayez une nouvelle API Lighthouse pour mesurer les performances et suivre les bonnes pratiques tout au long d'un parcours utilisateur.
Lighthouse est un outil fantastique pour tester les performances et les bonnes pratiques lors du chargement initial de la page. Toutefois, il a toujours été difficile d'utiliser Lighthouse pour analyser d'autres aspects de la vie d'une page, par exemple :
- Chargement de la page avec un cache à chaud
- Pages avec un service worker activé
- Tenir compte des interactions utilisateur potentielles
Cela signifie que Lighthouse peut manquer des informations essentielles. Les Core Web Vitals sont basés sur toutes les pages chargées, et non uniquement sur celles dont le cache est vide. De plus, les métriques telles que Cumulative Layout Shift (CLS) sont mesurables pendant toute la durée d'ouverture d'une page.
Lighthouse dispose d'une nouvelle API de parcours utilisateur qui permet d'effectuer des tests en laboratoire à tout moment de la durée de vie d'une page. Puppeteer permet de créer des scripts de chargement de pages et de déclencher des interactions utilisateur synthétiques. Lighthouse peut être appelé de plusieurs manières pour capturer des insights clés lors de ces interactions. Cela signifie que les performances peuvent être mesurées pendant le chargement de la page et lors des interactions avec celle-ci. Vous pouvez effectuer des contrôles d'accessibilité dans la CI, pas seulement sur la vue initiale, mais aussi en profondeur dans votre processus de paiement, pour vous assurer que rien ne régresse.
Presque tous les scripts Puppeteer écrits pour garantir un parcours utilisateur fonctionnel peuvent désormais être insérés à tout moment dans Lighthouse afin de mesurer les performances et les bonnes pratiques. Ce tutoriel présente les nouveaux modes Lighthouse qui peuvent mesurer différentes parties des parcours utilisateur : navigations, instantanés et périodes.
Configuration
Les API de parcours utilisateur sont toujours en version Preview, mais elles sont disponibles dans Lighthouse dès aujourd'hui. Pour essayer les démonstrations ci-dessous, vous devez disposer de la version 14 ou ultérieure de Node. Créez un répertoire vide et exécutez la commande suivante :
# 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
Navigations
Le nouveau mode de "navigation" de Lighthouse donne un nom au comportement standard de Lighthouse (jusqu'à présent) : analysez le chargement à froid d'une page. Il s'agit du mode à utiliser pour surveiller les performances de chargement des pages, mais les parcours utilisateur offrent également de nouvelles insights.
Pour créer un script permettant à Lighthouse de capturer le chargement d'une page:
- Utilisez Puppeteer pour ouvrir le navigateur.
- Démarrez un flux utilisateur Lighthouse.
- Accédez à l'URL cible.
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();
Il s'agit du processus le plus simple. Lorsqu'il est ouvert, le rapport affiche une vue récapitulative ne comportant qu'une seule étape. Cliquez sur cette étape pour afficher un rapport Lighthouse classique pour cette navigation.
Comme c'est généralement le cas avec Lighthouse, cette page est chargée avec le cache ou le stockage local effacé en premier, mais les utilisateurs réels qui accèdent à un site auront un mélange de visites avec des caches froids et chauds. Il peut y avoir une grande différence de performances entre une charge à froid comme celle-ci et un utilisateur qui revient sur la page avec un cache encore chaud.
Capturer une charge chaude
Vous pouvez également ajouter une deuxième navigation à ce script, en désactivant cette fois la suppression du cache et de l'espace de stockage que Lighthouse effectue par défaut dans les navigations. L'exemple suivant charge un article sur web.dev pour voir les avantages de la mise en cache:
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();
Le rapport sur le flux obtenu se présente comme suit :
La combinaison de charges à froid et à chaud offre une image plus complète de ce que les utilisateurs réels vivent. Si votre site permet aux utilisateurs de charger de nombreuses pages au cours d'une même visite, vous pourrez peut-être obtenir une vision plus réaliste de leur expérience sur le terrain.
Instantanés
Les instantanés sont un nouveau mode qui exécute des audits Lighthouse à un moment donné. Contrairement à une analyse Lighthouse normale, la page n'est pas actualisée. Vous pouvez ainsi configurer une page et la tester dans son état exact : avec un menu déroulant ouvert ou un formulaire partiellement rempli, par exemple.
Pour cet exemple, supposons que vous souhaitiez vérifier qu'une nouvelle interface utilisateur pour les paramètres avancés de Squoosh passe les vérifications automatisées de Lighthouse. Ces paramètres ne sont visibles que si une image a été chargée et que le menu d'options est développé pour afficher les paramètres avancés.
Ce processus peut être scripté avec Puppeteer, et vous pouvez prendre un instantané Lighthouse à chaque étape :
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();
Le rapport qui en résulte montre que les résultats sont généralement satisfaisants, mais certains critères d'accessibilité peuvent nécessiter une vérification manuelle:
Périodes
L'une des principales différences entre les résultats de performances sur le terrain (comme ceux de CrUX) et en laboratoire (comme ceux de Lighthouse) est l'absence d'entrée utilisateur. C'est là que la période (dernier mode de parcours utilisateur) peut vous aider.
Une période d'audit exécute des audits Lighthouse sur une période donnée, qui peut ou non inclure une navigation. C'est un excellent moyen de capturer ce qui se passe sur une page pendant les interactions. Par exemple, par défaut, Lighthouse mesure le CLS pendant le chargement de la page, mais sur le terrain, il est mesuré à partir de la navigation initiale jusqu'à la fermeture de la page. Si les interactions utilisateur sont à l'origine du CLS, Lighthouse ne pouvait pas les détecter ni les corriger auparavant.
Pour illustrer cela, voici un site de test qui simule l'injection d'annonces dans un article pendant le défilement, sans qu'aucun espace ne leur soit réservé. Dans une longue série de cartes, un carré rouge est parfois ajouté lorsque son emplacement entre dans la fenêtre d'affichage. Étant donné qu'aucun espace n'a été réservé pour ces carrés rouges, les cartes situées en dessous sont décalées, ce qui entraîne un décalage de la mise en page.
Une navigation Lighthouse standard a un CLS de 0. Toutefois, une fois la page cranée, des décalages de mise en page problématiques se produisent et la valeur du CLS augmente.
Le script suivant permet de générer un rapport sur le flux utilisateur avec les deux actions, pour montrer la différence.
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();
Cela génère un rapport comparant une navigation régulière à une période qui contient à la fois une navigation et un défilement par la suite :
En étudiant chaque étape, l'étape de navigation uniquement affiche un CLS de 0. Excellent site !
Toutefois, l'étape "Parcourir et faire défiler" raconte une autre histoire. Actuellement, seuls le temps de blocage total et le CLS (Cumulative Layout Shift) sont disponibles dans les périodes, mais le contenu à chargement différé de cette page fait chuter le CLS du site.
Auparavant, Lighthouse ne pouvait pas identifier ce comportement problématique de CLS, bien qu'il se manifeste presque certainement dans l'expérience des utilisateurs réels. Les tests de performances sur les interactions avec script améliorent considérablement la fidélité des tests en laboratoire.
Recherche de commentaires...
Les nouvelles API de parcours utilisateur dans Lighthouse permettent de faire beaucoup de nouvelles choses, mais il peut encore être compliqué de mesurer le type de scénarios rencontrés par vos utilisateurs.
Pour toute question, veuillez consulter les forums de discussion Lighthouse, et signaler tout bug ou suggestion dans l'outil Issue Tracker.