L’Outil Surpuissant pour Exploser ton Chiffre d'Affaires en 2025 !
Une introduction à la gestion programmatique de Lighthouse
Lighthouse est la suite d'outils d'analyse de la qualité des sites Web de Google. Il vous permet d'évaluer les performances, l'accessibilité, le référencement de votre site, etc. Il est également hautement configurable, ce qui le rend suffisamment flexible pour être utile pour tous les sites, du plus simple au plus complexe. Cette flexibilité inclut plusieurs façons différentes d’exécuter les tests, vous permettant de choisir la méthode qui convient le mieux à votre site ou à votre application.
L’une des méthodes les plus simples pour exécuter Lighthouse consiste à utiliser le panneau DevTools Lighthouse de Chrome . Si vous ouvrez votre site dans Chrome, puis ouvrez les DevTools de Chrome, vous devriez voir un onglet "Phare". À partir de là, si vous cliquez sur "Générer un rapport", vous devriez obtenir un rapport complet sur les indicateurs de qualité de votre site.
Ce sur quoi je me concentre dans cet article, cependant, se situe à l'autre extrémité du spectre. L'exécution de Lighthouse par programmation avec JavaScript nous permet de configurer des exécutions personnalisées, de sélectionner et de choisir les fonctionnalités que nous voulons tester, de collecter et d'analyser les résultats, et de spécifier des options de configuration propres à nos sites et applications.
Par exemple, vous travaillez peut-être sur un site qui est accessible via plusieurs URL – chacune avec ses propres données et style et peut-être même un balisage que vous souhaitez pouvoir analyser. Ou peut-être souhaitez-vous collecter les données de chaque test et les compiler ou les analyser de différentes manières. Avoir la possibilité de choisir comment vous souhaitez exécuter une analyse Lighthouse en fonction de ce qui fonctionne le mieux pour votre site ou votre application, il est plus facile de surveiller la qualité du site et d'identifier les problèmes avec votre site avant qu'ils ne s'accumulent ou ne causent trop de problèmes pour votre site.
Lancer Lighthouse par programmation n'est pas le meilleur choix pour chaque site et je vous encourage à explorer toutes les différentes méthodes que l'équipe de Lighthouse a élaborées pour utiliser l'outil. Cependant, si vous décidez d'utiliser Lighthouse par programme, les informations et le didacticiel ci-dessous devraient vous aider à démarrer.
Personnalisation des options de Lighthouse
L'avantage d'exécuter Lighthouse par programme n'est pas seulement la possibilité de configurer Lighthouse lui-même, mais plutôt tous les choses que vous pourriez vouloir ou devez faire autour des tests Lighthouse. Lighthouse possède une excellente documentation pour vous aider à démarrer. Pour tirer le meilleur parti de son exécution par programme, cependant, il y a deux principaux endroits où vous devrez creuser et en savoir plus sur le fonctionnement de Lighthouse: la configuration de vos exécutions de test et la communication des résultats de vos tests.
Lighthouse Test Run Configuration [19659013] La configuration d'un test Lighthouse est l'une de ces tâches qui peuvent être aussi simples ou aussi complexes que vous le souhaitez.
Lorsque vous exécutez Lighthouse par programmation, vous pouvez fournir des options personnalisées à trois endroits: l'URL que vous testerez, Options Chrome et objet de configuration Lighthouse. Vous pouvez voir ces trois paramètres dans la fonction d'exécution de Lighthouse à partir de la documentation de Lighthouse :
function launchChromeAndRunLighthouse (url, opts, config = null) {
retourne chromeLauncher.launch ({chromeFlags: opts.chromeFlags}). then (chrome => {
opts.port = chrome.port;
retourne le phare (url, opts, config) .then (résultats => {
retourne chrome.kill (). then (() => results.lhr)
});
});
} Vous pouvez utiliser le code dont vous avez besoin pour créer ces paramètres. Par exemple, disons que vous avez un site avec plusieurs pages ou URL que vous souhaitez tester. Vous souhaitez peut-être exécuter ce test dans un environnement CI dans le cadre de vos tâches CI, en vérifiant toutes les pages nécessaires à chaque exécution de la tâche. En utilisant cette configuration, vous pouvez utiliser JavaScript pour créer vos URL et créer une boucle qui exécutera Lighthouse pour chacune d'entre elles.
Toutes les options Chrome dont vous pourriez avoir besoin peuvent être spécifiées dans un objet qui est transmis à chrome-launcher . Dans l'exemple de la documentation, l'objet opts contient un tableau que nous appelons chromeFlags que vous pouvez passer à chrome-launcher et un port où vous pouvez enregistrer le port utilisé par chrome-launcher puis transmettez-le à Lighthouse.
Enfin, l'objet de configuration Lighthouse vous permet d'ajouter des options spécifiques à Lighthouse. Le package Lighthouse fournit un objet de configuration par défaut qui peut être utilisé tel quel ou étendu et modifié. Vous pouvez utiliser cet objet pour effectuer une multitude de choses, notamment pour spécifier les catégories de test Lighthouse que vous souhaitez tester.
Vous pouvez utiliser le emulatedFormFactor pour spécifier si vous souhaitez que le test s'exécute sur un mobile ou émulateur de bureau. Vous pouvez utiliser extraHeaders pour ajouter les cookies que vous pourriez avoir besoin d'utiliser dans le navigateur. Par exemple, un test exécutant uniquement la catégorie d'accessibilité sur un émulateur de bureau qui génère les résultats au format HTML peut avoir un objet de configuration qui ressemble à ceci:
const lighthouseOptions = {
étend: 'phare: par défaut',
réglages: {
uniquementCatégories: ['accessibility'],
emulatedFormFactor: 'bureau',
sortie: ['html'],
},
} Cet exemple représente une configuration minimale. Vous pouvez faire beaucoup plus. La documentation sur la configuration du phare contient beaucoup plus d'informations. Ils ont également un ensemble exemples d'objets de configuration pour certaines implémentations plus complexes.
Rapports de résultats personnalisés
Lorsque vous exécutez Lighthouse par programme, vous pouvez avoir les résultats renvoyés dans une ou plusieurs des trois options formatées et – et c'est la pièce la plus excitante à mon avis – vous pouvez avoir accès à l'objet brut Lighthouse Result (LHR).
HTML, JSON, CSV
Lighthouse formatera automatiquement les résultats de trois manières différentes: HTML, JSON ou CSV. Ce sont tous des résultats préconfigurés basés sur le modèle de rapport de base Lighthouse, ce que vous voyez si vous exécutez un test Lighthouse dans Chrome DevTools, par exemple. Dans l'objet de configuration lighthouseOptions de la section précédente, vous pouvez voir une clé pour la sortie qui contient un tableau avec une seule chaîne: html . Cela spécifie que je veux uniquement que les résultats soient renvoyés au format HTML. Si je voulais les résultats à la fois au format HTML et JSON, ce tableau ressemblerait à ['html', 'json'].
Une fois Lighthouse exécuté, il renverra un objet de résultats contenant deux clés: report et ] lhr . Nous parlerons du contenu de la clé lhr dans la section suivante, mais la clé report contient un tableau avec les résultats formatés comme vous l'avez demandé. Ainsi, par exemple, si nous avons demandé ['html', 'json']alors results.report [0] contiendra nos résultats au format HTML et results.report [1] contiendra nos résultats au format JSON.
] L'objet LHR
L'exécution de LHR par programme vous donne également accès à un objet de résultats beaucoup plus flexible: l'objet LHR. Cet objet contient les résultats bruts et certaines métadonnées de votre exécution Lighthouse. Une documentation plus complète est disponible sur le Lighthouse Github repository .
Vous pouvez utiliser ces résultats de plusieurs manières, notamment en créant des rapports personnalisés et en collectant des données à partir de plusieurs exécutions pour analyse.
Exemple: Exécution d'un test d'accessibilité pour mobile et ordinateur de bureau
Disons que j'ai un site qui charge différents composants selon que l'utilisateur utilise un écran plus petit ou plus grand, ce qui signifie que le HTML de chaque version du site sera légèrement différent. Je veux m'assurer que les deux versions du site obtiennent un score de 95 aux tests d'accessibilité de Lighthouse et qu'aucun code n'est engagé dans notre branche principale qui ne respecte pas cette norme.
Remarque : Si vous voulez voir un exemple fonctionnel du code ci-dessous analysant la page d'accueil de Sparkbox vous pouvez trouver le référentiel ici .
] Je peux configurer Lighthouse pour qu'il exécute deux fois la catégorie d'accessibilité, en fournissant des objets de configuration différents pour chacun d'eux – l'un définissant le emulatedFormFactor sur desktop et l'autre le mobile . Une manière simple de le faire est de créer un tableau avec les deux objets, comme illustré ci-dessous.
const lighthouseOptionsArray = [
{
étend: 'phare: par défaut',
réglages: {
uniquementCatégories: ['accessibility'],
emulatedFormFactor: 'bureau',
sortie: ['html', 'json'],
},
},
{
étend: 'phare: par défaut',
réglages: {
uniquementCatégories: ['accessibility'],
emulatedFormFactor: 'mobile',
sortie: ['html', 'json'],
},
},
] Ensuite, je peux créer une fonction qui bouclera dans ce tableau et exécutera un test Lighthouse pour chaque objet trouvé à l'intérieur du tableau.
Une chose à noter est qu'il est nécessaire d'introduire un délai entre chaque exécution, sinon Chromium peut devenir confus et les exécutions se termineront par une erreur. Pour ce faire, j'ai ajouté une fonction wait qui renvoie une promesse lorsque l'intervalle setTimeout est terminé.
function wait (val) {
retourne une nouvelle promesse (résoudre => setTimeout (résoudre, val));
}
function launchLighthouse (optionSet, opts, résultats) {
retour chromeLauncher
.launch ({chromeFlags: opts.chromeFlags})
.then (async chrome => {
opts.port = chrome.port;
essayez {
résultats = attendre le phare (url, opts, optionSet);
} catch (e) {
console.error ("phare", e);
}
if (résultats) reportResults (résultats, runEnvironment, optionSet, chrome);
attendre attendre (500);
chrome.kill ();
});
}
fonction asynchrone runLighthouseAnalysis () {
laissez les résultats;
opts const = {
chromeFlags: ["--no-sandbox", "--headless"]
};
for (const optionSet of lighthouseOptionsArray) {
console.log ("****** Lancement de l'analyse de phare ******");
attendre launchLighthouse (optionSet, opts, résultats);
}
} Dans ce cas, j'envoie les résultats à une fonction reportResults . À partir de là, j'enregistre les résultats dans des fichiers locaux, j'imprime les résultats sur la console et j'envoie les résultats à une fonction qui déterminera si les tests réussissent ou échouent à notre seuil d'accessibilité.
fonction asynchrone reportResults (results, runEnvironment, optionSet, chrome) {
if (results.lhr.runtimeError) {
return console.error (results.lhr.runtimeError.message);
}
attendre writeLocalFile (résultats, runEnvironment, optionSet);
printResultsToTerminal (results.lhr, optionSet);
return passOrFailA11y (results.lhr, optionSet, chrome);
} Pour ce projet, je veux pouvoir enregistrer les résultats JSON dans un répertoire spécifié pour nos tests CI et le fichier HTML dans un répertoire spécifié pour nos tests locaux. La façon dont Lighthouse renvoie ces différents types de résultats est dans un tableau dans l'ordre dans lequel ils ont été demandés.
Ainsi, dans cet exemple, dans notre objet lighthouseOptions notre tableau demande d'abord HTML, puis JSON. Ainsi, le tableau report contiendra d'abord les résultats au format HTML et les résultats au format JSON ensuite. La fonction writeToLocalFile enregistre ensuite la version correcte des résultats dans un fichier avec un nom personnalisé.
function createFileName (optionSet, fileType) {
const {emulatedFormFactor} = optionSet.settings;
const currentTime = new Date (). toISOString (). slice (0, 16);
const fileExtension = fileType === 'json'? 'json': 'html';
return `$ {currentTime} - $ {emulatedFormFactor}. $ {fileExtension}`;
}
function writeLocalFile (résultats, runEnvironment, optionSet) {
if (results.report) {
const fileType = runEnvironment === 'ci'? 'json': 'html';
const fileName = createFileName (optionSet, fileType);
fs.mkdirSync ('rapports / accessibilité /', {recursive: true}, erreur => {
if (erreur) console.error ('erreur de création du répertoire', erreur);
});
const printResults = fileType === 'json'? results.report [1]: results.report [0];
return write (printResults, fileType, `rapports / accessibilité / $ {fileName}`) .catch (error => console.error (error));
}
return null;
} Je souhaite également imprimer les résultats sur le terminal à la fin du test. Ceci fournit un moyen rapide et facile d'afficher les résultats sans avoir à ouvrir un fichier.
function printResultsToTerminal (results, optionSet) {
const title = résultats.categories.accessibility.title;
score const = résultats.categories.accessibility.score * 100;
console.log (' n ********************************** n');
console.log (`Options: $ {optionSet.settings.emulatedFormFactor} n`);
console.log (`$ {titre}: $ {score}`);
console.log (' n **********************************');
} Et enfin, je veux pouvoir échouer mes tests si les scores d'accessibilité ne correspondent pas à mon score seuil de 95.
function passOrFailA11y (results, optionSet, chrome) {
const targetA11yScore = 95;
const {windowSize} = optionSet;
const accessibilitéScore = résultats.categories.accessibility.score * 100;
if (accessibilitéScore) {
if (windowSize === 'bureau') {
if (accessibilitéScore <targetA11yScore) {
console.error (`Score d'accessibilité cible: $ {targetA11yScore}, score d'accessibilité actuel $ {availabilityScore}`);
chrome.kill ();
process.exitCode = 1;
}
}
if (windowSize === 'mobile') {
if (accessibilitéScore Je vous invite tous à jouer avec et à explorer toutes les différentes façons dont Lighthouse peut vous aider à surveiller la qualité de votre site.
Notes finales
Bien que j'ai volontairement gardé l'exemple ci-dessus relativement simple, j'espère qu'il vous a donné un bon aperçu de ce qui peut être accompli en exécutant Lighthouse par programme. Et j'espère que cela vous incitera à trouver de nouvelles façons d'utiliser cet outil flexible et puissant.
Comme l'a dit Peter Drucker:
«Si vous ne pouvez pas mesurez-le, vous ne pouvez pas l'améliorer. »
Être capable non seulement de mesurer, mais aussi de surveiller la qualité de notre site Web, en particulier pour les sites complexes, nous aidera grandement à créer un meilleur Web.
Lectures complémentaires sur SmashingMag:
(ra, yk, il) Source link