Lighthouse audits running headless !
Lighthouse est un auditeur créé par Google pour, comme on dit, Voir les performances de votre site Web. Ensuite, obtenez des conseils pour améliorer votre expérience utilisateur
Il a toujours été un outil facile à utiliser, mais avec de nombreuses mises en garde. Vous pouvez l'exécuter directement depuis votre navigateur Chrome pour vous donner les résultats. C'est formidable d'avoir une idée de certains des sites Web que vous visitez, mais cela ne vous permettra pas d'avoir un test standardisé ou, par conséquent, des résultats. En effet, si vous l'exécutez sur votre ordinateur, les résultats varient en fonction de l'endroit où vous vous trouvez, de votre vitesse Internet et de la quantité de trafic Internet qui se produit localement pendant que vous testez.
Esprit dev
En tant que développeur, je veux toujours suivre les performances d'un projet à chaque changement. En plus de toutes les variables mentionnées ci-dessus, l'exécuter manuellement à partir d'un navigateur Chrome prend beaucoup de temps.
Enfin, selon la version de Lighthouse, la façon dont les résultats sont calculés peut être assez différente. Et votre version de Lighthouse dépend de votre version de Chrome.
Quand j'ai, (pseudo) récemment, vu la sortie de la version 6 de Lighthouse, je me suis demandé comment je pouvais le faire fonctionner sans rien faire à la main. Il s'avère (ouais il m'a fallu beaucoup de temps pour comprendre cela) que c'est un référentiel [GitHub publique] (https://github.com/GoogleChrome/lighthouse) !! Cela mérite un gros titre =>
Lighthouse 6 vient (tout juste) de sortir !
Idéal pour que vous puissiez simplement le télécharger et l'exécuter directement sur votre ordinateur sans avoir à cliquer partout sur Chrome! En effet, vous pouvez, mais en tant que serveur, je voulais aussi que cela n'ait pas besoin de toucher Chrome.
C'est pourquoi j'ai commencé à essayer de faire fonctionner Lighthouse à l'intérieur d'un conteneur Docker sans me soucier d'avoir un Google Chrome local à contrôler.
Avoir un conteneur Docker
Pour ce faire, j'ai créé un conteneur Docker qui installera Lighthouse et Headless Chromium
FROM node:13-alpine
# Installs the latest Chromium package.
RUN echo "http://dl-cdn.alpinelinux.org/alpine/edge/main" > /etc/apk/repositories \
&& echo "http://dl-cdn.alpinelinux.org/alpine/edge/community" >> /etc/apk/repositories \
&& echo "http://dl-cdn.alpinelinux.org/alpine/edge/testing" >> /etc/apk/repositories \
&& echo "http://dl-cdn.alpinelinux.org/alpine/v3.11/main" >> /etc/apk/repositories \
&& apk upgrade -U -a \
&& apk add --no-cache \
libstdc++ \
chromium \
harfbuzz \
nss \
freetype \
ttf-freefont \
wqy-zenhei \
bash \
&& rm -rf /var/cache/* \
&& mkdir /var/cache/apk
RUN mkdir -p /usr/src/app
WORKDIR /usr/src/app
RUN wget https://raw.githubusercontent.com/jfrazelle/dotfiles/master/etc/docker/seccomp/chrome.json -P /usr/src
RUN export CHROME_PATH=/usr/lib/chromium/
RUN yarn global add lighthouse
COPY audit.sh /usr/local/bin/audit
RUN chmod +x /usr/local/bin/auditCréation d'un script personnalisé pour vous assurer que chaque exécution fait ce qui doit être fait
C'était un long sous-titre, comme vous pouvez le voir dans le Dockerfile à la fin
COPY audit.sh /usr/local/bin/audit
RUN chmod +x /usr/local/bin/auditCela garantit qu'un script bash personnalisé est disponible pour s'exécuter lorsque vous démarrez le conteneur.
Le script est le suivant:
#!/bin/bash
usage() { echo "Usage: $0 [-u <string>] [-p <string>] [-o <string>] [-n <string>]" 1>&2; exit 1; }
defaultOptions='--chrome-flags="--headless --no-sandbox" --no-enable-error-reporting'
while getopts ":u:p:o:n:" o; do
case "${o}" in
u)
url=${OPTARG}
;;
p)
IFS=',' read -r -a paths <<< "${OPTARG}"
;;
o)
defaultOptions=${OPTARG}
;;
n)
name=${OPTARG}
;;
*)
usage
exit 1
;;
esac
done
shift $((OPTIND-1))
if [ -n "$url" ]; then
outputPath=""
if [ -n "$name" ];then
outputPath=" --output-path ./${name}.report.html"
fi
eval lighthouse "$url" "$defaultOptions" "$outputPath"
if [ -n "$url" ]; then
for path in "${paths[@]}"; do
if [ -n "$name" ];then
filename=$(echo "$name""$path" | tr / _)
outputPath=" --output-path ./${filename}.report.html"
fi
eval lighthouse "$url""$path" "$defaultOptions" "$outputPath"
done
fi
fiSi vous souhaitez analyser rapidement un site simpledocker run --rm -v ~/reports:/usr/src/app codebuds/lighthouse audit -u https://site.mine
Cela exécutera l'audit, puis copiera le fichier depuis le conteneur vers votre ordinateur vers votre répertoire / home / {votre nom} / reports.
Ce fut un excellent début car cela prend environ 20 secondes sur mon ordinateur au lieu des 2 minutes lorsque je l'exécute directement à partir de mon navigateur Chrome.
Mais je voulais aussi simplifier le test des chemins au sein du site en fournissant les chemins par défaut et les sous-chemins suivants. J'ai donc ajouté une option -p qui vous permettra d'ajouter un ou plusieurs sous-chemins séparés par un ,. Par exemple :
docker run --rm -v ~/reports:/usr/src/app codebuds/lighthouse audit -u https://debest.fr/ -p /en/blog/traefik-intro,/en/contact
Cela créera tous les résultats dans votre volume mais, par défaut, Lighthouse utilise uniquement le chemin de base et une date pour les noms de fichiers. donc lors de l'exécution de la commande précédente, les fichiers finaux dans le répertoire ~ / reports seront:
-
debest.fr_2020-07-03_14-51-58.report.html
-
debest.fr_2020-07-03_14-51-46.report.html
-
debest.fr_2020-07-03_14-51-36.report.html
Ce qui n'aide pas à déterminer quel fichier est lié à quelle page ou sous-page. C'est pourquoi j'ai ajouté une autre option: Ajoutez un nom de base par défaut aux fichiers, avec les options -n vous pouvez définir un nom par défaut qui prendra en compte les noms de chemin des sous-domaines (et supprimez / car cela peut être un problème sur l'OS).
docker run --rm -v ~/reports:/usr/src/app codebuds/lighthouse audit -u https://debest.fr/ -p /en/blog/traefik-intro,/en/contact -n debest.fr
Te donnera :
- debest.fr.report.html
- debest.fr_en_blog_traefik-intro.report.html
- debest.fr_en_contact.report.html
Ce qui facilitera la recherche du fichier correspondant à la page testée.
Si vous voulez avoir localement le nom de sous-domaine et une date, faites le moi savoir et j'ajouterai quelques options mais ce n'est pas mon cas. Je vais te dire pourquoi.
Gitlab-CI
Nous voilà ! Je veux que la plupart des choses de ma vie soient automatiques. J'ai un serveur exécutant GitLab et vous pouvez lui dire d'exécuter beaucoup de choses dès que vous envoyez des modifications à l'un de répositoires. Pour ce faire, il est facile d'ajouter simplement une tâche au fichier .gitlab-ci.yml dans votre projet :
audit_dev:
tags:
- main
stage: audit
image: codebuds/lighthouse
when: on_success
artifacts:
paths:
- ./*.report.html
script:
- audit -u https://debest.fr -p /en/blog/traefik-intro,/en/contact -n debest.fr
environment:
name: develop
url: https://debest.fr
only:
- developBien sûr, c'est celui que vous souhaitez exécuter en dernier lorsque toutes les tâches de génération et de déploiement ont été effectuées.
Ensuite, si cela a fonctionné (youpi!), Vous pouvez trouver les fichiers dans vos travaux GitLab CI / CD et les télécharger (ou si vous avez envie de les exécuter dans les pages GitLab).
Pleins de todo
Comme je l'ai mentionné, j'aime automatiser les choses. Une partie a été faite, mais je vois des choses à rajouter. Au lieu d'avoir à afficher ou à télécharger l'une des pages d'audit, je pourrai mettre Lighthouse en mode JSON et télécharger les données sur un serveur. Peut-être alors lui faire regarder la différence entre la nouvelle version et la dernière et déclenchez une alerte sur [Mattermost] (mattermost.com) grâce à notre [bundle] (https://packagist.org/packages/codebuds/mattermost- publication-bundle). Mais jusqu'à présent, cela nous fait déjà gagner beaucoup de temps et nous aide à maintenir nos sites en bon état.
N'hésitez pas à poser des questions dans les commentaires ou à créer des problèmes dans le gitlab.
Merci d'avoir lu, à bientôt.
Dennis de Best
Commentaires