Essayez une nouvelle API Lighthouse pour mesurer les performances et 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. Cependant, il a toujours été difficile d'utiliser Lighthouse pour analyser d'autres aspects de la vie d'une page, tels que:
- La page se charge avec un cache chaud
- Pages avec un service worker activé
- Prise en compte des interactions utilisateur potentielles
Cela signifie que Lighthouse peut passer à côté d'informations essentielles. Le rapport Core Web Vitals se base sur tous les chargements de pages, et pas seulement sur ceux 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 pour les chargements de pages et de déclencher des interactions utilisateur synthétiques. Lighthouse peut être appelé de différentes manières pour capturer des insights clés au cours 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 les vérifications 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 s'assurer qu'un flux utilisateur fonctionnel peut désormais être inséré à tout moment dans Lighthouse pour mesurer les performances et les bonnes pratiques. Ce tutoriel présente les nouveaux modes Lighthouse permettant de mesurer différentes parties des parcours utilisateur: navigations, instantanés et périodes.
Configuration
Les API de parcours utilisateur sont encore en version preview, mais elles sont disponibles dans Lighthouse. Pour essayer les démonstrations ci-dessous, vous devez disposer de Node.14 ou d'une version ultérieure. Créez un répertoire vide et exécutez-le:
# 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
Nouvelle "navigation" de Lighthouse consiste à donner un nom au comportement standard de Lighthouse (jusqu'à présent), à savoir analyser le chargement à froid d'une page. Il s'agit du mode à utiliser pour surveiller les performances de chargement des pages, mais les flux utilisateur offrent également la possibilité de nouvelles informations.
Pour créer un script de chargement de page dans Lighthouse, procédez comme suit:
- Utilisez Pppeteer 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 flux 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 traditionnel pour cette navigation.
<ph type="x-smartling-placeholder">Comme c'est le cas avec Lighthouse, cette page est d'abord chargée de n'importe quel cache ou espace de stockage local vidé, mais les vrais utilisateurs qui consultent un site auront un mélange de visites avec des caches froids et tièdes. De plus, il peut y avoir une grande différence de performances entre un chargement à froid comme celui-ci et un utilisateur qui revient sur la page avec un cache toujours chaud.
Capturer une charge chaude
Vous pouvez également ajouter une deuxième navigation à ce script, cette fois pour désactiver l'effacement du cache et de l'espace de stockage effectué par Lighthouse 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 de flux obtenu se présente comme suit:
<ph type="x-smartling-placeholder">La combinaison des charges à froid et à chaud offre une image plus complète de ce que vivent les utilisateurs réels. Si votre site charge de nombreuses pages au cours d'une même visite, vous pouvez obtenir une image plus réaliste de la situation sur le terrain.
Instantanés
Les instantanés constituent un nouveau mode qui exécute les audits Lighthouse à un moment donné. Contrairement à une exécution Lighthouse standard, la page n'est pas actualisée. Cela vous permet de configurer une page et de la tester dans son état exact: avec un menu déroulant ouvert ou un formulaire partiellement rempli, par exemple.
Dans cet exemple, supposons que vous souhaitiez vérifier qu'une nouvelle interface utilisateur pour les paramètres avancés dans Squoosh réussit les vérifications automatiques 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.
<ph type="x-smartling-placeholder">.Ce processus peut être rédigé 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:
<ph type="x-smartling-placeholder">Périodes
L'une des principales différences entre les résultats de performances sur le terrain (comme dans l'expérience CrUX) et dans l'atelier (comme dans Lighthouse) est le manque d'entrées utilisateur. C'est là qu'une période (le dernier mode de flux utilisateur) peut vous aider.
Les audits Lighthouse sont effectués sur une période donnée, qui peut inclure ou non une navigation. C'est un excellent moyen de capturer ce qui se passe sur une page au cours des interactions. Par exemple, Lighthouse mesure par défaut le CLS pendant le chargement de la page, mais dans le champ, il est mesuré depuis la navigation initiale jusqu'à la fermeture de la page. Si les interactions utilisateur sont le déclencheur du CLS, cela était auparavant impossible pour Lighthouse.
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 fiches, un carré rouge est parfois ajouté lorsque l'emplacement entre dans la fenêtre d'affichage. Comme l'espace n'était pas réservé pour ces carrés rouges, les cartes situées en dessous sont décalées, ce qui entraîne des décalages de mise en page.
Le CLS d'une navigation Lighthouse standard est de 0. Cependant, une fois que vous aurez fait défiler la page, vous rencontrerez des problèmes de décalage de mise en page et la valeur CLS augmentera.
<ph type="x-smartling-placeholder">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 standard à une période qui contient à la fois une navigation et un défilement par la suite:
<ph type="x-smartling-placeholder">En étudiant chaque étape, l'étape de navigation uniquement affiche un CLS de 0. Excellent site !
Cependant, l'option "Naviguer et faire défiler" l’étape raconte une histoire différente. Actuellement, seuls le temps total de blocage et le décalage de mise en page cumulatif sont disponibles pour les périodes, mais le contenu au chargement différé de cette page limite clairement le CLS du site.
Auparavant, Lighthouse n'était pas en mesure d'identifier ce comportement problématique en termes de CLS, même s'il apparaissait très certainement dans l'expérience des utilisateurs réels. Les tests de performance par rapport aux interactions scriptées améliorent considérablement la fidélité des ateliers.
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.
Si vous avez des questions, n'hésitez pas à les poser dans les forums de discussion Lighthouse, et signalez tout bug ou suggestion dans l'outil de suivi des problèmes.