Ajouter Lighthouse à un système d'intégration continue, tel que GitHub Actions
Lighthouse CI est une suite d'outils permettant d'utiliser Lighthouse lors de l'intégration continue. Lighthouse CI peut être intégré aux workflows des développeurs de différentes manières. Ce guide couvre les sujets suivants :
- Utiliser la CLI Lighthouse CI
- Configurer votre fournisseur d'intégration continue pour exécuter Lighthouse CI.
- Configurer une action GitHub et une vérification d'état pour Lighthouse CI. Les résultats de Lighthouse s'afficheront alors automatiquement sur les demandes d'extraction GitHub.
- Créer un tableau de bord des performances et un datastore pour les rapports Lighthouse.
Présentation
Lighthouse CI est une suite d'outils sans frais qui facilitent l'utilisation de Lighthouse pour la surveillance des performances. Un seul rapport Lighthouse fournit un instantané des performances d'une page Web au moment de son exécution. Lighthouse CI montre l'évolution de ces résultats au fil du temps. Cela peut être utilisé pour identifier l'impact de modifications de code particulières ou pour s'assurer que les seuils de performances sont respectés lors des processus d'intégration continue. Bien que la surveillance des performances soit le cas d'utilisation le plus courant de Lighthouse CI, il peut être utilisé pour surveiller d'autres aspects du rapport Lighthouse, par exemple le SEO ou l'accessibilité.
La fonctionnalité de base de Lighthouse CI est fournie par l'interface de ligne de commande Lighthouse CI. (Remarque : Il s'agit d'un outil distinct de la CLI Lighthouse.) La CLI Lighthouse CI fournit un ensemble de commandes permettant d'utiliser Lighthouse CI. Par exemple, la commande autorun exécute plusieurs exécutions Lighthouse, identifie le rapport Lighthouse médian et l'importe pour le stocker. Ce comportement peut être fortement personnalisé en transmettant des options supplémentaires ou en personnalisant le fichier de configuration de Lighthouse CI, lighthouserc.js.
Bien que la fonctionnalité de base de Lighthouse CI soit principalement encapsulée dans la CLI Lighthouse CI, Lighthouse CI est généralement utilisé via l'une des approches suivantes :
- Exécuter Lighthouse CI dans le cadre de l'intégration continue
- Utiliser une action GitHub Lighthouse CI qui s'exécute et ajoute un commentaire à chaque demande d'extraction
- Suivre les performances au fil du temps via le tableau de bord fourni par le serveur Lighthouse.
Toutes ces approches sont basées sur la CLI Lighthouse CI.
Les alternatives à Lighthouse CI incluent des services de surveillance des performances tiers ou l'écriture de votre propre script pour collecter des données sur les performances pendant le processus d'intégration continue. Vous devriez envisager d'utiliser un service tiers si vous préférez laisser quelqu'un d'autre gérer votre serveur de surveillance des performances et vos appareils de test, ou si vous souhaitez disposer de fonctionnalités de notification (comme l'intégration d'e-mails ou de Slack) sans avoir à les créer vous-même.
Utiliser Lighthouse CI localement
Cette section explique comment installer et exécuter la CLI Lighthouse CI localement, et comment configurer lighthouserc.js. Exécuter la CLI Lighthouse CI localement est le moyen le plus simple de vous assurer que votre fichier lighthouserc.js est correctement configuré.
Installez la CLI Lighthouse CI.
npm install -g @lhci/cliLighthouse CI est configuré en plaçant un fichier
lighthouserc.jsà la racine du dépôt de votre projet. Ce fichier est obligatoire et contiendra les informations de configuration liées à Lighthouse CI. Bien que Lighthouse CI puisse être configuré pour être utilisé sans dépôt Git, les instructions de cet article supposent que le dépôt de votre projet est configuré pour utiliser Git.À la racine de votre dépôt, créez un fichier de configuration
lighthouserc.js.touch lighthouserc.jsAjoutez le code suivant à
lighthouserc.js. Ce code est une configuration Lighthouse CI vide. Vous ajouterez des éléments à cette configuration dans les étapes ultérieures.module.exports = { ci: { collect: { /* Add configuration here */ }, upload: { /* Add configuration here */ }, }, };Chaque fois que Lighthouse CI s'exécute, il démarre un serveur pour diffuser votre site. Ce serveur permet à Lighthouse de charger votre site même lorsqu'aucun autre serveur n'est en cours d'exécution. Une fois l'exécution de Lighthouse CI terminée, le serveur s'arrête automatiquement. Pour vous assurer que la diffusion fonctionne correctement, vous devez configurer les propriétés
staticDistDiroustartServerCommand.Si votre site est statique, ajoutez la propriété
staticDistDirà l'objetci.collectpour indiquer l'emplacement de vos fichiers statiques. Lighthouse CI utilisera son propre serveur pour diffuser ces fichiers lors du test de votre site. Si votre site n'est pas statique, ajoutez la propriétéstartServerCommandà l'objetci.collectpour indiquer la commande qui démarre votre serveur. Lighthouse CI démarre un nouveau processus de serveur pendant les tests, puis l'arrête.// Static site example collect: { staticDistDir: './public', }// Dynamic site example collect: { startServerCommand: 'npm run start', }Ajoutez la propriété
urlà l'objetci.collectpour indiquer les URL sur lesquelles Lighthouse CI doit exécuter Lighthouse. La valeur de la propriétéurldoit être fournie sous la forme d'un tableau d'URL. Ce tableau peut contenir une ou plusieurs URL. Par défaut, Lighthouse CI exécute Lighthouse trois fois sur chaque URL.collect: { // ... url: ['http://localhost:8080'] }Ajoutez la propriété
targetà l'objetci.uploadet définissez la valeur sur'temporary-public-storage'. Les rapports Lighthouse collectés par Lighthouse CI seront importés dans un espace de stockage public temporaire. Le rapport y restera pendant sept jours, puis sera automatiquement supprimé. Ce guide de configuration utilise l'option d'importation "stockage public temporaire", car elle est rapide à configurer. Pour en savoir plus sur les autres façons de stocker les rapports Lighthouse, consultez la documentation.upload: { target: 'temporary-public-storage', }L'emplacement de stockage du rapport ressemblera à ceci :
https://storage.googleapis.com/lighthouse-infrastructure.appspot.com/reports/1580152437799-46441.report.html(Cette URL ne fonctionnera pas, car le rapport a déjà été supprimé.)
Exécutez la CLI Lighthouse CI depuis le terminal à l'aide de la commande
autorun. Lighthouse sera exécuté trois fois et le rapport Lighthouse médian sera importé.lhci autorunSi vous avez correctement configuré Lighthouse CI, l'exécution de cette commande devrait produire un résultat semblable à celui-ci :
✅ .lighthouseci/ directory writable ✅ Configuration file found ✅ Chrome installation found ⚠️ GitHub token not set Healthcheck passed! Started a web server on port 65324... Running Lighthouse 3 time(s) on http://localhost:65324/index.html Run #1...done. Run #2...done. Run #3...done. Done running Lighthouse! Uploading median LHR of http://localhost:65324/index.html...success! Open the report at https://storage.googleapis.com/lighthouse-infrastructure.appspot.com/reports/1591720514021-82403.report.html No GitHub token set, skipping GitHub status check. Done running autorun.Vous pouvez ignorer le message
GitHub token not setdans la sortie de la console. Un jeton GitHub n'est nécessaire que si vous souhaitez utiliser Lighthouse CI avec une action GitHub. La configuration d'une action GitHub est expliquée plus loin dans cet article.En cliquant sur le lien commençant par
https://storage.googleapis.com...dans le résultat, vous accédez au rapport Lighthouse correspondant à l'exécution médiane de Lighthouse.Les valeurs par défaut utilisées par
autorunpeuvent être remplacées via la ligne de commande oulighthouserc.js. Par exemple, la configurationlighthouserc.jsci-dessous indique que cinq exécutions Lighthouse doivent être collectées à chaque exécution deautorun.Mettez à jour
lighthouserc.jspour utiliser la propriéténumberOfRuns:module.exports = { // ... collect: { numberOfRuns: 5 }, // ... }, };Exécutez à nouveau la commande
autorun:lhci autorunLe résultat du terminal doit indiquer que Lighthouse a été exécuté cinq fois au lieu des trois fois par défaut :
✅ .lighthouseci/ directory writable ✅ Configuration file found ✅ Chrome installation found ⚠️ GitHub token not set Healthcheck passed! Automatically determined ./dist as `staticDistDir`. Set it explicitly in lighthouserc.json if incorrect. Started a web server on port 64444... Running Lighthouse 5 time(s) on http://localhost:64444/index.html Run #1...done. Run #2...done. Run #3...done. Run #4...done. Run #5...done. Done running Lighthouse! Uploading median LHR of http://localhost:64444/index.html...success! Open the report at https://storage.googleapis.com/lighthouse-infrastructure.appspot.com/reports/1591716944028-6048.report.html No GitHub token set, skipping GitHub status check. Done running autorun.Pour en savoir plus sur les autres options de configuration, consultez la documentation de configuration de Lighthouse CI.
Configurer votre processus d'intégration continue pour exécuter Lighthouse CI
Lighthouse CI peut être utilisé avec votre outil d'intégration continue préféré. La section Configure Your CI Provider (Configurer votre fournisseur d'intégration continue) de la documentation de Lighthouse CI contient des exemples de code montrant comment intégrer Lighthouse CI dans les fichiers de configuration des outils d'intégration continue courants. Plus précisément, ces exemples de code montrent comment exécuter Lighthouse CI pour collecter des mesures de performances pendant le processus d'intégration continue.
L'utilisation de Lighthouse CI pour collecter des mesures de performances est un bon point de départ pour la surveillance des performances. Toutefois, les utilisateurs avancés peuvent aller plus loin et utiliser Lighthouse CI pour faire échouer les builds s'ils ne répondent pas à des critères prédéfinis, tels que la réussite de certains audits Lighthouse ou le respect de tous les budgets de performances. Ce comportement est configuré via la propriété assert du fichier lighthouserc.js.
Lighthouse CI accepte trois niveaux d'assertions :
off: ignorer les assertionswarn: imprime les échecs dans stderrerror: affiche les échecs dans stderr et quitte Lighthouse CI avec un code de sortie différent de zéro.
Vous trouverez ci-dessous un exemple de configuration lighthouserc.js incluant des assertions. Il définit des assertions pour les scores des catégories de performances et d'accessibilité de Lighthouse. Pour tester cette fonctionnalité, ajoutez les assertions ci-dessous à votre fichier lighthouserc.js, puis réexécutez Lighthouse CI.
module.exports = {
ci: {
collect: {
// ...
},
assert: {
assertions: {
'categories:performance': ['warn', {minScore: 1}],
'categories:accessibility': ['error', {minScore: 1}]
}
},
upload: {
// ...
},
},
};
Le résultat de la console se présente comme suit :
Pour en savoir plus sur les assertions Lighthouse CI, consultez la documentation.
Configurer une action GitHub pour exécuter Lighthouse CI
Une action GitHub peut être utilisée pour exécuter Lighthouse CI. Un rapport Lighthouse sera ainsi généré chaque fois qu'une modification de code sera transférée vers une branche d'un dépôt GitHub. Utilisez cette option conjointement avec une vérification de l'état pour afficher ces résultats sur chaque demande d'extraction.
À la racine de votre dépôt, créez un répertoire nommé
.github/workflows. Les workflows de votre projet seront placés dans ce répertoire. Un workflow est un processus qui s'exécute à un moment prédéterminé (par exemple, lorsque du code est transféré) et qui est composé d'une ou de plusieurs actions.mkdir .github mkdir .github/workflowsDans
.github/workflows, créez un fichier nommélighthouse-ci.yaml. Ce fichier contiendra la configuration d'un nouveau workflow.touch lighthouse-ci.yamlAjoutez le texte suivant à
lighthouse-ci.yaml.name: Build project and run Lighthouse CI on: [push] jobs: lhci: name: Lighthouse CI runs-on: ubuntu-latest steps: - uses: actions/checkout@v1 - name: Use Node.js 10.x uses: actions/setup-node@v1 with: node-version: 10.x - name: npm install run: | npm install - name: run Lighthouse CI run: | npm install -g @lhci/cli@0.3.x lhci autorun --upload.target=temporary-public-storage || echo "LHCI failed!"Cette configuration configure un workflow composé d'un seul job qui s'exécute chaque fois qu'un nouveau code est transféré vers le dépôt. Ce job comporte quatre étapes :
- Extrayez le dépôt sur lequel Lighthouse CI sera exécuté.
- Installer et configurer Node
- Installer les packages npm requis
- Exécutez Lighthouse CI et importez les résultats dans un espace de stockage public temporaire.
Validez ces modifications et déployez-les sur GitHub. Si vous avez correctement suivi les étapes ci-dessus, l'envoi du code vers GitHub déclenchera l'exécution du workflow que vous venez d'ajouter.
Pour vérifier que Lighthouse CI a été déclenché et afficher le rapport qu'il a généré, accédez à l'onglet Actions de votre projet. Le workflow Build project and Run Lighthouse CI (Compiler le projet et exécuter Lighthouse CI) doit s'afficher sous votre commit le plus récent.
Vous pouvez accéder au rapport Lighthouse correspondant à un commit particulier à partir de l'onglet Actions. Cliquez sur le commit, puis sur l'étape de workflow Lighthouse CI, puis développez les résultats de l'étape run Lighthouse CI.
Vous venez de configurer une action GitHub pour exécuter Lighthouse CI. Cette option est particulièrement utile lorsqu'elle est utilisée conjointement avec une vérification de l'état GitHub.
Configurer une vérification d'état GitHub
Une vérification d'état, si elle est configurée, est un message qui s'affiche sur chaque demande d'extraction et qui inclut généralement des informations telles que les résultats d'un test ou la réussite d'un build.
Les étapes ci-dessous expliquent comment configurer une vérification d'état pour Lighthouse CI.
Accédez à la page de l'application GitHub Lighthouse CI, puis cliquez sur Configure (Configurer).
(Facultatif) Si vous appartenez à plusieurs organisations sur GitHub, choisissez celle qui possède le dépôt pour lequel vous souhaitez utiliser Lighthouse CI.
Sélectionnez Tous les dépôts si vous souhaitez activer Lighthouse CI dans tous les dépôts, ou sélectionnez Uniquement certains dépôts si vous ne souhaitez l'utiliser que dans des dépôts spécifiques, puis sélectionnez les dépôts. Cliquez ensuite sur Installer et autoriser.
Copiez le jeton qui s'affiche. Vous l'utiliserez à l'étape suivante.
Pour ajouter le jeton, accédez à la page Settings (Paramètres) de votre dépôt GitHub, cliquez sur Secrets, puis sur Add a new secret (Ajouter un secret).
Définissez le champ Nom sur
LHCI_GITHUB_APP_TOKENet le champ Valeur sur le jeton que vous avez copié à l'étape précédente, puis cliquez sur le bouton Ajouter un secret.Accédez au fichier
lighthouse-ci.yamlet ajoutez le nouveau secret d'environnement à la commande "run Lighthouse CI".
- name: run Lighthouse CI
run: |
npm install -g @lhci/cli@0.3.x
lhci autorun --upload.target=temporary-public-storage || echo "LHCI failed!"
+ env:
+ LHCI_GITHUB_APP_TOKEN: $
- La vérification de l'état est prête à être utilisée. Pour le tester, créez une demande d'extraction ou effectuez un commit sur une demande d'extraction existante.
Configurer le serveur Lighthouse CI
Le serveur Lighthouse CI fournit un tableau de bord permettant d'explorer l'historique des rapports Lighthouse. Il peut également servir de datastore privé à long terme pour les rapports Lighthouse.
- Choisissez les commits à comparer.
- La différence entre les scores Lighthouse des deux commits.
- Cette section n'affiche que les métriques qui ont changé entre les deux commits.
- Les régressions sont surlignées en rose.
- Les améliorations sont surlignées en bleu.
Le serveur Lighthouse CI est idéal pour les utilisateurs qui sont à l'aise avec le déploiement et la gestion de leur propre infrastructure.
Pour en savoir plus sur la configuration du serveur Lighthouse CI, y compris sur l'utilisation de Heroku et de Docker pour le déploiement, consultez ces instructions.