Craft et technique
Pourquoi les animations d’un site saccadent-elles malgré un bon score Lighthouse ?
Un bon score Lighthouse ne garantit pas que toutes les animations restent fluides pendant la visite. Le score synthétise des métriques dans les conditions d’un audit. Une scène sollicitée après le chargement, un menu ouvert au-dessus d’une vidéo ou une succession de transitions peuvent révéler d’autres difficultés.
L'essentiel.
Lighthouse produit une mesure de performance dans un scénario défini ; il ne résume pas toute l’expérience interactive. Pour comprendre des saccades, il faut enregistrer le passage qui pose problème et distinguer calcul, rendu, mémoire et conditions de l’appareil.
- Distinguer le score d’un audit et la qualité de chaque séquence interactive.
- Reproduire le problème avec un scénario et des conditions identifiables.
- Examiner les tâches JavaScript, le rendu et les ressources avant de modifier l’effet.
- Comparer les corrections sur le même parcours, puis vérifier les autres appareils utiles.
Pour comprendre les saccades, il faut reproduire le moment précis où elles apparaissent, sur l’appareil concerné, puis enregistrer son fonctionnement. Changer une bibliothèque ou réduire tous les effets sans diagnostic peut masquer le problème sans traiter sa cause.
Comprendre ce que le score dit et ce qu’il laisse ouvert
La documentation de Lighthouse décrit un score composé de métriques pondérées et explique sa variabilité selon les conditions. Ce résultat aide à repérer des problèmes ; il ne constitue pas une appréciation complète de chaque moment du site.
Une animation peut être déclenchée seulement lorsque le visiteur atteint un chapitre. Plusieurs médias peuvent se superposer après une interaction. Une scène peut accumuler des ressources lors des retours. Ces situations demandent des scénarios spécifiques.
L’expression « le site rame » doit donc être précisée. Est-ce le premier mouvement qui hésite, toute la séquence qui manque de régularité ou la réponse à une commande qui arrive tard ? La réponse oriente les mesures et évite de confondre plusieurs problèmes sous le même mot.
Localiser la cause avant de chercher une recette
Le navigateur doit traiter des événements, calculer des styles, mettre en page, dessiner et composer le résultat. Un effet peut solliciter plusieurs de ces étapes. Le guide d’animation de web.dev recommande d’examiner notamment les propriétés qui déclenchent des recalculs de disposition ou de peinture.
| Symptôme observé | Hypothèse à examiner | Vérification utile |
|---|---|---|
| Blocage au premier passage | Préparation d’une ressource ou travail initial | Comparer premier et second passage |
| Saccade à chaque défilement | Travail répété trop coûteux | Enregistrer la séquence concernée |
| Dégradation après plusieurs pages | Ressources conservées ou boucles multipliées | Répéter les allers-retours |
| Problème sur certains appareils | Charge graphique ou conditions différentes | Tester la même scène sur ces appareils |
Ces hypothèses ne sont pas des diagnostics. Une même manifestation peut avoir plusieurs causes. Le panneau Performance de Chrome DevTools permet d’enregistrer le parcours et d’examiner son activité. Les outils équivalents d’autres navigateurs peuvent compléter l’enquête.
Exemple pédagogique : un titre animé au-dessus d’une vidéo
Imaginons un site fictif dont l’ouverture est fluide, mais dont le titre saccade lors du défilement. La scène combine une vidéo, un flou animé et une modification continue de la taille du texte. Le score d’audit ne permet pas de choisir lequel de ces éléments est responsable.
L’équipe prépare plusieurs variantes de diagnostic : vidéo conservée mais effet de flou retiré, titre stable, puis animation de déplacement simplifiée. Chaque variante est observée dans le même passage. Les tests servent à isoler le coût de chaque choix, sans présumer du résultat.
Diagnostiquer une saccade
- ReproduireDécrire l’appareil, les étapes et le moment exact du problème.
- EnregistrerObserver l’activité du navigateur pendant cette séquence.
- IsolerModifier un coût à la fois : effet, média, travail ou ressource.
- ComparerRejouer le même parcours et contrôler la fidélité visuelle.
Supposons qu’une variante rende le texte plus régulier tout en conservant le geste artistique. La décision doit encore vérifier la lisibilité, le mobile et les états de reprise. Une optimisation qui supprime la saccade mais introduit un saut de composition ne résout qu’une partie du problème.
Mesurer la régularité et documenter les conditions
Une moyenne peut masquer quelques interruptions très visibles. Il est utile d’observer le déroulement de la séquence, les moments difficiles et leur répétition. Les objectifs de fluidité doivent être définis pour le projet et ses appareils de référence ; un seuil universel détaché du contexte serait trompeur.
Consignez le navigateur, l’appareil, la taille de la fenêtre, l’état du cache et les étapes effectuées. Répétez la visite après un certain temps d’utilisation, sans transformer une observation isolée en conclusion générale. Les conditions thermiques et les autres activités de l’appareil peuvent aussi influencer ce que l’on constate.
La correction peut porter sur le contenu, le rythme ou l’architecture. Réduire une résolution, éviter un travail répété, suspendre un effet invisible ou simplifier une composition sont des pistes différentes. Le choix doit préserver ce qui rend la scène identifiable.
Enfin, gardez une mesure de référence et une trace du scénario corrigé. Lors d’une mise à jour de contenu ou de dépendance, cette séquence peut être rejouée. La performance devient ainsi un critère suivi pendant la vie du site, plutôt qu’un score obtenu une seule fois.
Questions fréquentes
Faut-il abandonner Lighthouse pour un site très animé ?
Non. L’outil reste utile pour ce qu’il mesure. Il faut le compléter par l’observation de parcours interactifs et, lorsque cela est possible, par des données d’usage réelles. Un audit de chargement et un enregistrement d’animation répondent à des questions différentes et peuvent révéler des problèmes complémentaires.
Une animation CSS est-elle toujours plus rapide qu’une animation JavaScript ?
Non. Le résultat dépend des propriétés modifiées, du travail demandé et de la façon dont l’animation est exécutée. Il est préférable de comparer les réalisations réelles. Le choix du langage ou de la bibliothèque ne remplace pas l’examen du rendu et du scénario d’utilisation.
Peut-on se fier à une vidéo de démonstration ?
Elle montre un rendu enregistré dans certaines conditions, mais ne révèle pas nécessairement la réponse aux gestes ni les variations entre appareils. Elle peut servir de référence visuelle. La validation technique exige de manipuler le site réel et de reproduire les interactions importantes.
Sources
LVX : relier la fluidité au geste artistique
LVX peut définir les séquences dont la qualité compte le plus dans la perception du site, puis les intégrer aux critères de recette. Avec l’équipe de développement, les variantes sont comparées sur des parcours précis et des appareils identifiés. L’objectif est de préserver le rythme, les repères et la matière visuelle tout en traitant les causes observées des ralentissements. Cette méthode permet de discuter les compromis sur des éléments concrets, sans confondre un score favorable avec une expérience entièrement aboutie. Discuter du projet avec LVX.
