La lenteur n’est pas un problème unique. Le serveur peut répondre tard, l’image principale démarrer tard, un script bloquer une interaction ou une bannière déplacer un bouton au moment du clic. Chaque défaut demande ses propres preuves et réparations.
Commencez par la page, l’appareil et l’action essentiels. Un accueil rapide sur ordinateur ne démontre pas la rapidité du produit ou du paiement sur mobile. Comparer des tests différents peut attribuer une variation à la mauvaise cause.
Périmètre de cet audit
Ce qui peut être mesuré
- Performance publique via PageSpeed Insights, résultats de laboratoire Lighthouse et métriques CrUX lorsque le fournisseur les retourne.
- Stratégie mobile ou ordinateur, URL mesurée, pistes d’amélioration, diagnostics et preuves par métrique disponibles.
Ce qu’il ne prouve pas
- Le laboratoire est un échantillon contrôlé. Le terrain peut manquer ou couvrir l’origine entière plutôt que la page exacte.
- Local Agent utilise une mesure locale limitée distincte, pas Lighthouse hébergé ni CrUX.
L’accès dépend de l’offre et de la disponibilité du fournisseur. Les mesures absentes sont indiquées indisponibles plutôt que remplacées par des données inventées.
1. Lire séparément laboratoire et terrain
Lighthouse réalise un scénario répétable pour diagnostiquer une page. CrUX agrège des expériences réelles admissibles lorsqu’il y a assez de données. Public, appareils, réseau et périodes différents peuvent expliquer des désaccords. La documentation PageSpeed Insights présente les deux sources.
Lisez la provenance de chaque métrique : une valeur peut venir du terrain et une autre du laboratoire. Vérifiez si les données représentent l’URL exacte ou toute l’origine. L’absence de terrain est un échantillon manquant, pas un échec Core Web Vitals ni une preuve d’absence de visiteurs.
2. Comprendre les trois Core Web Vitals
| Métrique | Description | Bonne limite de référence |
|---|---|---|
| LCP | Affichage du plus grand élément visible | 2,5 secondes ou moins |
| INP | Réactivité aux interactions | 200 millisecondes ou moins |
| CLS | Mouvement inattendu de mise en page | 0,1 ou moins |
Sur le terrain, ces seuils s’évaluent au 75e percentile des visites, en séparant les catégories d’appareils. Consultez Web Vitals. Un chiffre de laboratoire ne constitue pas une réussite terrain. Time to First Byte et First Contentful Paint sont des diagnostics utiles, pas des Core Web Vitals supplémentaires.
3. Relier le symptôme à la preuve
Ces priorités sont illustratives : l’effet sur une tâche essentielle compte davantage que le titre d’une alerte.
| Symptôme | Priorité contextuelle | Preuves à examiner |
|---|---|---|
| Contenu principal tardif | Haute si l’offre reste incompréhensible | Élément LCP, réponse et chronologie réseau |
| Bouton d’achat lent | Haute pour la conversion | Trace d’interaction et tâches longues |
| Contenu glissant sous le pointeur | Haute si actions accidentelles | Éléments déplacés et dimensions réservées |
| Gros script inutilisé | Moyenne avant mesure du coût | Octets, exécution et utilisation |
Une estimation d’économie n’est pas garantie. Deux recommandations peuvent se chevaucher et une ressource lourde être nécessaire. Confirmez la cause avant de supprimer une fonction ou changer l’infrastructure.
4. Corriger le composant responsable du délai
Contenu tardif : identifiez d’abord l’élément LCP. Pour une réponse serveur lente, examinez backend et cache. Pour une image principale découverte tard, rendez-la accessible tôt dans le document et évitez son chargement différé. Livrez des dimensions adaptées. Le guide LCP détaille les phases.
Interaction lente : cherchez gestionnaires coûteux, rendu synchrone et travail des tiers. Divisez les tâches longues et réduisez les opérations superflues. Total Blocking Time aide au diagnostic de laboratoire sans être équivalent à INP. Utilisez le guide INP et un enregistrement d’interaction réel.
Déplacement : réservez la place des images, intégrations et bannières avant leur arrivée. La réparation dépend de l’élément et de la cause du mouvement.
5. Comparer avant et après avec contrôle
- Notez URL exacte, stratégie, heure et source.
- Appliquez une correction cohérente liée au blocage observé.
- Répétez plusieurs essais comparables et lisez la tendance, pas le meilleur résultat.
- Examinez visuellement et accomplissez l’action principale.
- Vérifiez qu’un composant partagé n’a pas dégradé un autre modèle.
- Observez ensuite le terrain : une fenêtre agrégée ne reflète pas immédiatement une publication.
Conservez les diagnostics, pas seulement la note. Une image plus rapide qui provoque des déplacements laisse le problème incomplet. Retestez les écrans étroits et contenus tardifs : consentement, polices et widgets.
6. Reconnaître les limites du test
Une navigation n’exerce pas tous les états d’une application complexe. Une page peut charger vite puis mal réagir après une longue session d’édition. Le laboratoire peut rencontrer un consentement, compte ou contenu différent d’un vrai client.
Le rapport hébergé Sitelemetry indique stratégie et sources disponibles. Local Agent examine la livraison locale avec une autre méthode limitée ; ne comparez pas directement sa note à Lighthouse public. Si PageSpeed manque, résolvez ou retentez la mesure plutôt que lire une case vide comme zéro. Les preuves doivent préciser ce qui a réellement tourné.
7. Intégrer la vitesse au travail produit
Définissez des budgets pour vos modèles et actions : images, scripts tiers et calculs côté client. À chaque ajout de chat, analytique ou animation, testez la page avant et après au lieu de supposer le fournisseur sans coût.
Préservez ensemble exactitude, accessibilité et rapidité. Un formulaire stable qui indique sa progression vaut mieux qu’une bonne note obtenue en cachant du contenu. Priorisez votre page mobile commerciale, lancez la mesure disponible et rédigez une correction avec acceptation mesurable. Associez accessibilité et intégrations lorsque le même composant touche les trois domaines.
Questions fréquentes
Pourquoi deux essais donnent-ils des notes différentes ?
Réseau, charge serveur, cache et variabilité du laboratoire jouent un rôle. Comparez même URL et appareil sur plusieurs essais équivalents, puis les métriques.
Sans données CrUX, sommes-nous lents ?
Non. Les données terrain admissibles manquent pour ce périmètre. Utilisez le laboratoire pour diagnostiquer, sans conclure à une réussite ou un échec terrain.
TBT et INP sont-ils identiques ?
Non. TBT diagnostique le travail bloquant en laboratoire ; INP décrit la réactivité pendant les interactions utilisateur.
Sources et lectures
- Google : à propos de PageSpeed Insightsdevelopers.google.com
- web.dev : Web Vitalsweb.dev
- web.dev : optimiser Largest Contentful Paintweb.dev
- web.dev : optimiser Interaction to Next Paintweb.dev
Rédigé par l’équipe Sitelemetry et vérifié par rapport au périmètre du produit et aux sources primaires citées. Les exemples sont illustratifs, sauf mention explicite d’un cas observé.
