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 des pages. Toutefois, il est généralement difficile d'utiliser Lighthouse pour analyser d'autres aspects de la vie d'une page, tels que les suivants:
- La page se charge avec un cache tiède
- Pages avec un service worker activé
- Prise en compte des interactions utilisateur potentielles
Lighthouse peut donc passer à côté d'informations vitales. Les métriques Core Web Vitals tiennent compte de tous les chargements de page, et pas seulement de ceux dont le cache est vide. De plus, des 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 pendant la durée de vie d'une page. Puppeteer permet de créer des scripts pour des chargements de page et de déclencher des interactions utilisateur synthétiques. Lighthouse peut être appelé de plusieurs 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 exécuter des contrôles d'accessibilité dans la CI, pas seulement sur la vue initiale, mais aussi en profondeur dans le 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 avec Lighthouse afin de mesurer les performances et les bonnes pratiques. Ce tutoriel présente les nouveaux modes Lighthouse qui permettent de mesurer différentes parties des parcours utilisateur: les navigations, les instantanés et les périodes.
Préparation
Les API de parcours utilisateur sont encore en version preview, mais elles sont actuellement 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-y 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 en fait 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 parcours utilisateur offrent également la possibilité d'obtenir de nouveaux insights.
Pour créer un script Lighthouse afin de capturer un chargement de page:
- Utilisez puppeteer pour ouvrir le navigateur.
- Démarrez un parcours 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 de la procédure la plus simple. Lorsqu'il est ouvert, le rapport affiche une vue récapitulative contenant une seule étape. Si vous cliquez sur cette étape, un rapport Lighthouse traditionnel s'affiche pour cette navigation.
Comme c'est généralement le cas avec Lighthouse, cette page est d'abord chargée avec le cache ou l'espace de stockage local effacés, mais les utilisateurs réels consultant un site seront à la fois des visites avec des caches froids et des caches chauds. 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 encore chaud.
Capturer une charge tiède
Vous pouvez également ajouter une deuxième navigation à ce script, en désactivant cette fois le cache et l'espace de stockage que Lighthouse effectue par défaut dans les navigations. L'exemple suivant charge un article sur web.dev lui-même 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 les flux obtenu se présente comme suit:
La combinaison des charges à froid et à chaud offre une image plus complète de ce que les utilisateurs réels vivent. Si les internautes chargent de nombreuses pages au cours d'une même visite sur votre site, vous pouvez peut-être vous faire une idée plus réaliste de ce qu'ils ressentent 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 normale de Lighthouse, la page n'est pas actualisée. Vous pouvez ainsi configurer une page et la tester dans son état exact, par exemple avec une liste déroulante ouverte ou un formulaire partiellement rempli.
Dans cet exemple, supposons que vous souhaitiez vérifier qu'une nouvelle interface utilisateur pour les paramètres avancés dans Squoosh passe les vérifications automatisées 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.
Puppeteer permet de rédiger des scripts pour ce processus. 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 obtenu montre que les résultats sont généralement satisfaisants. Toutefois, certains critères d'accessibilité peuvent nécessiter une vérification manuelle:
Périodes
L'une des plus grandes différences entre les résultats obtenus sur le terrain (avec CrUX, par exemple) et dans l'atelier (comme dans Lighthouse) est le manque d'informations saisies par l'utilisateur. C'est là qu'une période (le dernier mode de flux utilisateur) peut vous aider.
Une période de temps exécute des audits Lighthouse sur une certaine période, qui peut inclure ou non une navigation. C'est un excellent moyen de garder une trace de ce qui se passe sur une page lors de vos interactions. Par exemple, Lighthouse mesure par défaut le CLS lors du chargement de la page, mais dans le champ, le CLS est mesuré de la navigation initiale jusqu'à la fermeture de la page. Si les interactions des utilisateurs sont à l'origine du CLS, ce problème ne pouvait pas être détecté auparavant par Lighthouse.
Pour illustrer cela, voici un site de test qui simule l'injection d'annonces dans un article lors du défilement, sans qu'il y ait d'espace réservé pour celles-ci. Dans une longue série de cartes, un carré rouge occasionnel est ajouté lorsque son emplacement entre dans la fenêtre d'affichage. Comme l'espace n'était pas réservé à ces carrés rouges, les cartes en dessous sont décalées, ce qui entraîne des décalages de mise en page.
Une navigation Lighthouse standard aura un CLS de 0. Cependant, une fois que vous aurez fait défiler la page, des décalages de mise en page seront problématiques et la valeur CLS augmentera.
Le script suivant génère un rapport sur les parcours utilisateur incluant 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();
Vous générez ainsi un rapport comparant une navigation standard à une période incluant à la fois une navigation et un défilement ultérieurs:
En examinant chaque étape, l'étape de navigation uniquement affiche un CLS de 0. Excellent site !
Cependant, l'étape "Naviguer et faire défiler" raconte une autre histoire. Actuellement, seuls le "Total Blocking Time" et le "Cumulative Layout Shift" sont disponibles pour les périodes, mais le contenu à chargement différé de cette page indique clairement le CLS pour le site.
Auparavant, Lighthouse n'était pas en mesure d'identifier ce comportement problématique au niveau du CLS, mais il s'affichait très certainement dans l'expérience de vrais utilisateurs. Les tests de performance sur des interactions scriptées améliorent considérablement la fidélité aux ateliers.
Recherche de commentaires...
Les nouvelles API de flux utilisateur de Lighthouse offrent beaucoup de nouvelles fonctionnalités, mais il peut s'avérer compliqué de mesurer les types de scénarios rencontrés par vos utilisateurs.
Si vous avez des questions, n'hésitez pas à nous contacter dans les forums de discussion de Lighthouse, et à signaler les bugs ou les suggestions dans l'outil de suivi des problèmes.