Catégories
Plugin et site web

Une introduction à la gestion programmatique de Lighthouse – Smashing Magazine

A propos de l'auteur

Katy se passionne pour rendre la technologie plus facile pour ceux qui la construisent et l'utilisent. Dans son rôle de développeur chez Sparkbox, elle travaille principalement en JavaScript pour implémenter…
Plus à propos
Katy

La possibilité d’exécuter la suite d’analyses Lighthouse de Google par programme offre de nombreux avantages, en particulier pour les applications Web plus volumineuses ou plus complexes. L'utilisation de Lighthouse par programme permet aux ingénieurs de mettre en place une surveillance de la qualité pour les sites qui nécessitent plus de personnalisation que les applications simples de Lighthouse (telles que Lighthouse CI) ne le permettent. Cet article contient une brève introduction à Lighthouse, décrit les avantages de son exécution par programme et décrit une configuration de base.

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 fonctionne le mieux pour votre site ou votre application.

L'un des moyens les plus simples d'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 statistiques de qualité de votre site.

Ce sur quoi je me concentre dans cet article, cependant, se situe à l'autre bout 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 uniques à nos sites et applications.

Par exemple, vous travaillez peut-être sur un site 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 rassembler 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. utilisateurs du site.

L'exécution de Lighthouse par programme 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 développées pour utiliser l'outil. Si vous décidez d'utiliser Lighthouse par programme, cependant, les informations et le didacticiel ci-dessous devraient vous aider à démarrer.

Personnalisation des options de phare

L’avantage d’exécuter Lighthouse par programmation n’est pas seulement la possibilité de configurer Lighthouse lui-même, mais plutôt toutes les choses que vous voudrez ou devez faire autour des tests Lighthouse. Lighthouse a 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: configurer vos exécutions de test et rapporter vos résultats de test.

Configuration de l'essai de fonctionnement du phare

La configuration d'un test Lighthouse est l'une de ces tâches qui peuvent être aussi simples ou 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 allez tester, les options Chrome et l'objet de configuration Lighthouse. Vous pouvez voir que ces trois paramètres sont des paramètres dans la fonction d'exécution de Lighthouse à partir de la documentation de Lighthouse:

function launchChromeAndRunLighthouse(url, opts, config = null) {
  return chromeLauncher.launch({chromeFlags: opts.chromeFlags}).then(chrome => {
    opts.port = chrome.port;
    return lighthouse(url, opts, config).then(results => {
      return 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'elles.

Toutes les options Chrome dont vous pourriez avoir besoin peuvent être spécifiées dans un objet qui est transmis au lanceur de chrome. Dans l'exemple de la documentation, le opts objet 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 le transmettre à 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 dans un émulateur de mobile ou 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 = {
  extends: 'lighthouse:default',
  settings: {
    onlyCategories: ('accessibility'),
    emulatedFormFactor:'desktop',
    output: ('html'),
  },
}

Cet exemple représente une configuration minimale. Vous pouvez faire beaucoup plus. La documentation de configuration de Lighthouse contient beaucoup plus d'informations. Ils ont également un ensemble d'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 l'élément le plus excitant à 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 le lighthouseOptions objet de configuration de la section précédente, vous pouvez voir une clé pour output 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 en HTML et en JSON, ce tableau ressemblerait à ('html', 'json').

Une fois Lighthouse exécuté, il renverra un objet de résultats qui contiendra deux clés: report et lhr. Nous parlerons du contenu du lhr entrez dans la section suivante, mais le report key contient un tableau avec les résultats formatés comme vous l'avez demandé. Donc, par exemple, si nous avons demandé ('html', 'json'), puis 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 Lighthouse 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 référentiel Lighthouse Github.

Vous pouvez utiliser ces résultats de différentes manières, notamment en créant des rapports personnalisés et en collectant des données à partir de plusieurs exécutions à des fins d'analyse.

Exemple: exécution d'un test d'accessibilité pour les appareils mobiles et les ordinateurs de bureau

Disons que j'ai un site qui charge des composants différents selon que l'utilisateur utilise un écran plus petit ou plus grand, ce qui signifie que le code 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é Lighthouse et qu'aucun code ne soit engagé dans notre main succursale qui ne répond pas à cette norme.

Remarque: Si vous souhaitez 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 exécuter la catégorie d'accessibilité deux fois, en fournissant des objets de configuration différents pour chacun – un paramètre le emulatedFormFactor à desktop et un le mettant à mobile. Un moyen simple de le faire est de créer un tableau avec les deux objets, illustré ci-dessous.

const lighthouseOptionsArray = (
  {
    extends: 'lighthouse:default',
    settings: {
      onlyCategories: ('accessibility'),
      emulatedFormFactor:'desktop',
      output: ('html', 'json'),
    },
  },
  {
    extends: 'lighthouse:default',
    settings: {
      onlyCategories: ('accessibility'),
      emulatedFormFactor:'mobile',
      output: ('html', 'json'),
    },
  },
)

Ensuite, je peux créer une fonction qui parcourra 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é un wait fonction qui renvoie une promesse lorsque le setTimeout l'intervalle est terminé.

function wait(val) {
  return new Promise(resolve => setTimeout(resolve, val));
}

function launchLighthouse(optionSet, opts, results) {
  return chromeLauncher
    .launch({ chromeFlags: opts.chromeFlags })
    .then(async chrome => {
      opts.port = chrome.port;
      try {
        results = await lighthouse(url, opts, optionSet);
      } catch (e) {
        console.error("lighthouse", e);
      }
      if (results) reportResults(results, runEnvironment, optionSet, chrome);
      await wait(500);
      chrome.kill();
    });
}

async function runLighthouseAnalysis() {
  let results;
  const opts = {
    chromeFlags: ("--no-sandbox", "--headless")
  };
  for (const optionSet of lighthouseOptionsArray) {
    console.log("****** Starting Lighthouse analysis ******");
    await launchLighthouse(optionSet, opts, results);
  }
}

Dans ce cas, j'envoie les résultats à un reportResults fonction. À 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é.

async function reportResults(results, runEnvironment, optionSet, chrome) {
  if (results.lhr.runtimeError) {
    return console.error(results.lhr.runtimeError.message);
  }
  await writeLocalFile(results, runEnvironment, optionSet);
  printResultsToTerminal(results.lhr, optionSet);
  return passOrFailA11y(results.lhr, optionSet, chrome);
}

Pour ce projet, je souhaite 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.

Donc, dans cet exemple, dans notre lighthouseOptions objet, notre tableau demande d'abord HTML, puis JSON. Alors le report array contiendra les résultats au format HTML en premier et les résultats au format JSON en second. le writeToLocalFile La fonction 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(results, runEnvironment, optionSet) {
  if (results.report) {
    const fileType = runEnvironment === 'ci' ? 'json' : 'html';
    const fileName = createFileName(optionSet, fileType);
    fs.mkdirSync('reports/accessibility/', { recursive: true }, error => {
      if (error) console.error('error creating directory', error);
    });
    const printResults = fileType === 'json' ? results.report(1) : results.report(0);
    return write(printResults, fileType, `reports/accessibility/${fileName}`).catch(error => console.error(error));
  }
  return null;
}

Je souhaite également imprimer les résultats sur le terminal à la fin du test. Cela fournit un moyen rapide et facile d'afficher les résultats sans avoir à ouvrir un fichier.

function printResultsToTerminal(results, optionSet) {
  const title = results.categories.accessibility.title;
  const score = results.categories.accessibility.score * 100;
  console.log('n********************************n');
  console.log(`Options: ${optionSet.settings.emulatedFormFactor}n`);
  console.log(`${title}: ${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 accessibilityScore = results.categories.accessibility.score * 100;
  if (accessibilityScore) {
    if (windowSize === 'desktop') {
      if (accessibilityScore < targetA11yScore) {
        console.error(`Target accessibility score: ${targetA11yScore}, current accessibility score ${accessibilityScore}`);
        chrome.kill();
        process.exitCode = 1;
      }
    }
    if (windowSize === 'mobile') {
      if (accessibilityScore 

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 lors de l'exécution de 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 le mesurer, vous ne pouvez pas l'améliorer."

Être en mesure non seulement de mesurer, mais également 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:

Éditorial fracassant(ra, yk, il)

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *