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 est généralement difficile d'utiliser Lighthouse pour analyser d'autres aspects de la vie d'une page, tels que :
- Chargements de page avec un cache chaud
- Pages avec un service worker activé
- Prendre en compte les interactions potentielles des utilisateurs
Cela signifie que Lighthouse peut passer à côté d'informations essentielles. Les Core Web Vitals sont basés sur tous les chargements de page, et pas seulement sur ceux dont le cache est vide. De plus, les métriques telles que le CLS (Cumulative Layout Shift) 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 page 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 lors du chargement de la page et lors des interactions avec la page. Les vérifications d'accessibilité peuvent être exécutées dans l'intégration continue, non seulement sur la vue initiale, mais aussi au cœur de votre processus de paiement, pour vous assurer qu'aucune régression ne se produit.
Presque tous les scripts Puppeteer écrits pour garantir un parcours utilisateur fonctionnel peuvent désormais intégrer Lighthouse à tout moment pour 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 : navigations, instantanés et périodes.
Configuration
Les API de parcours utilisateur sont encore en version preview, mais elles sont déjà disponibles dans Lighthouse. Pour essayer les démonstrations ci-dessous, vous devez disposer de Node version 14 ou 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 "navigation" de Lighthouse donne en fait un nom au comportement standard de Lighthouse (jusqu'à présent) : analyser le chargement à froid d'une page. C'est le mode à utiliser pour surveiller les performances de chargement des pages, mais les parcours utilisateur permettent également d'obtenir de nouveaux insights.
Pour créer un script Lighthouse capturant 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 du flux le plus simple. Lorsqu'il est ouvert, le rapport affiche une vue récapitulative avec une seule étape. Cliquez sur cette étape pour afficher un rapport Lighthouse traditionnel pour cette navigation.
Comme d'habitude avec Lighthouse, cette page est chargée après avoir vidé le cache ou l'espace de stockage local. Toutefois, les utilisateurs réels qui visitent un site effectuent un mélange de visites avec des caches froids et chauds, et 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 à chaud
Vous pouvez également ajouter une deuxième navigation à ce script, en désactivant cette fois l'effacement 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 dans quelle mesure il bénéficie 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 ressemble à ceci :
La combinaison des chargements à froid et à chaud offre une image plus complète de ce que les utilisateurs réels rencontrent. Si vous possédez un site sur lequel les utilisateurs chargent de nombreuses pages au cours d'une même visite, cela peut vous donner une idée plus réaliste de ce qu'ils vivent sur le terrain.
Instantanés
Les instantanés sont un nouveau mode qui exécute les audits Lighthouse à un moment précis. Contrairement à une exécution Lighthouse normale, 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 Lighthouse automatisées. 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 obtenu montre que les résultats sont généralement bons, mais certains critères d'accessibilité doivent être vérifiés manuellement :
Périodes
L'une des plus grandes 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à qu'un intervalle de temps (le dernier mode de parcours utilisateur) peut être utile.
Un intervalle 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 capturer ce qui se passe sur une page lors des interactions. Par exemple, par défaut, Lighthouse mesure le CLS pendant le chargement de page, mais sur le terrain, le CLS est mesuré 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 aider à les corriger.
Une navigation Lighthouse standard aura un CLS de 0. Toutefois, une fois que l'utilisateur aura fait défiler la page, celle-ci présentera des décalages de mise en page problématiques et la valeur du CLS augmentera.
Le script suivant génère un rapport sur le parcours 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.example.com/';
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 contenant à la fois une navigation et un défilement ultérieur :
En examinant chaque étape, l'étape de navigation seule affiche un CLS de 0. Super 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 dans les périodes, mais le contenu chargé en différé sur cette page fait clairement chuter le CLS du site.
Auparavant, Lighthouse n'était pas en mesure d'identifier ce comportement CLS problématique, même s'il apparaissait presque certainement dans l'expérience des utilisateurs réels. Les tests de performances sur les interactions scriptées améliorent considérablement la fidélité des tests en laboratoire.
En attente de commentaires
Les nouvelles API de parcours utilisateur de Lighthouse peuvent faire beaucoup de nouvelles choses, mais il peut toujours être compliqué de mesurer les types de scénarios que vos utilisateurs rencontrent.
Si vous avez des questions, n'hésitez pas à les poser sur les forums de discussion de Lighthouse. Vous pouvez également signaler des bugs ou faire des suggestions dans l'outil Issue Tracker.