Mesurer l’état initial d’une route
Objectif : Produire un rapport Lighthouse reproductible pour une page d’itinéraire.
Une amélioration de performance n’a de sens que si vous pouvez la comparer à un état initial fiable. Sans protocole stable, deux rapports Lighthouse peuvent différer simplement parce que l’un a été réalisé sur un serveur de développement et l’autre sur une version optimisée, ou parce que les conditions réseau ont changé.
Vous allez établir une référence pour la page d’itinéraire `/randonnees/cretes-du-jura`. Les indicateurs LCP, INP et CLS, leurs seuils et leur lecture au percentile 75 ont été définis dans la leçon précédente ; ici, vous vérifiez une route précise dans des conditions documentées.
Préparer une mesure représentative
Utilisez une version de production de l’application : démarrez-la avec la commande de production prévue par le projet, puis ouvrez la route dans Chrome. Le serveur de développement ajoute des outils et des comportements qui ne correspondent pas à l’expérience déployée. Vérifiez d’abord que la page répond correctement et que son contenu principal, notamment l’itinéraire, est visible.
- Conservez la même version de Chrome et la même machine entre les comparaisons.
- Utilisez le même profil de simulation Lighthouse, par exemple Mobile, et gardez les paramètres réseau et processeur identiques.
- Fermez les onglets et les applications qui consomment fortement les ressources, puis évitez toute navigation pendant l’audit.
- Notez l’URL exacte, la date, la version de l’application, le profil et le mode de navigation utilisés.
Lancer Lighthouse sur la route
Dans Chrome, ouvrez les outils de développement, puis l’onglet Lighthouse. Sélectionnez l’audit de performance et le profil Mobile, puis lancez l’analyse sur la page complète. Vérifiez que l’adresse auditée est bien celle de l’itinéraire, et non la page d’accueil du catalogue.
Le rapport présente un score de performance et des diagnostics détaillés. Examinez les opportunités et les avertissements associés aux ressources, aux images et à l’exécution des scripts : ils donnent des pistes d’investigation, mais ne constituent pas à eux seuls une preuve qu’un correctif précis améliorera l’expérience réelle. Notez aussi tout élément qui pourrait rendre la mesure atypique, comme une erreur de chargement ou un contenu absent.
Conserver le rapport de référence
Enregistrez le rapport Lighthouse au format HTML ou JSON, puis associez-le à une fiche de mesure conservée avec les livrables du projet. Le nom du fichier doit permettre d’identifier la route et la date, par exemple `cretes-du-jura-2025-03-08-mobile.html` ; adaptez la date au jour réel de votre audit. Ne modifiez pas les fichiers applicatifs du catalogue pour consigner ces résultats.
| Élément à consigner | Exemple |
|---|---|
| Route et URL | /randonnees/cretes-du-jura |
| Version testée | Identifiant de commit ou numéro de version |
| Environnement | Build de production, serveur et origine de la page |
| Conditions | Chrome, profil Mobile, paramètres de simulation |
| Résultats | Score Lighthouse, indicateurs affichés et diagnostics notables |
| Fichier archivé | Rapport HTML ou JSON et date de l’audit |
Cette fiche rend les comparaisons ultérieures interprétables : vous pouvez relier un écart à une version et à un contexte identifiables. Si la route échoue ou ne rend pas le contenu attendu, consignez l’échec plutôt que d’archiver un score comme s’il décrivait une page fonctionnelle.
À retenir
- Auditez la route d’itinéraire sur un build de production, pas sur le serveur de développement.
- Gardez constants le navigateur, le profil Lighthouse et les conditions de mesure.
- Archivez le rapport avec la version testée et les conditions qui permettent de le reproduire.
- Traitez ce résultat comme une référence de laboratoire ; les mesures des visiteurs seront étudiées séparément.
Dans la prochaine leçon, vous utiliserez cette référence pour définir un budget de JavaScript client et contrôler les ressources chargées par la page.