Partez du symptôme, pas d’une extension
Une page peut répondre vite et pourtant sembler lente. Le Time to First Byte (TTFB) mesure combien de temps une navigation attend le premier octet de la réponse ; le Largest Contentful Paint (LCP) concerne le plus grand contenu visible ; l’Interaction to Next Paint (INP), la réactivité aux clics, aux touchers et au clavier. Améliorer l’un ne corrige pas automatiquement les autres.
Ceci est un guide de diagnostic, pas le compte rendu d’une mission client mesurée. Utilisez vos propres mesures avant et après pour juger si un changement a fonctionné.
Établissez une référence comparable
- Choisissez des modèles représentatifs : un article, une catégorie, un produit et un tunnel de commande. Incluez des sessions connectées et anonymes.
- Notez l’appareil, le réseau, la localisation, l’URL, l’état du cache et la version déployée. Répétez les tests de laboratoire dans les mêmes conditions au lieu de retenir le meilleur score.
- Consultez les données terrain dans PageSpeed Insights ou la Search Console. Une URL peu visitée peut ne pas avoir de données propres ; les données de l’origine sont plus générales et doivent être présentées comme telles.
- Séparez les succès de cache des échecs. Une réponse rapide à chaud peut masquer une origine lente lors d’une invalidation ou d’un pic de trafic.
Réduisez le travail du serveur sans prendre de risque
Examinez la requête du document dans le panneau Réseau du navigateur, puis analysez PHP, les requêtes à la base de données et les appels à des API externes. Les requêtes lentes, les appels distants répétés, la saturation des processus et une origine éloignée demandent des solutions différentes. Un cache d’objets persistant peut réduire le travail répété en base, mais ce n’est pas la même chose que mettre en cache une réponse HTML complète.
Le cache de page complète peut aider pour les pages éditoriales anonymes. Ne placez pas dans un cache public les pages de compte, les paniers, les tunnels de commande, les réponses authentifiées ni les réponses contenant des informations personnelles. Vérifiez avec votre hébergeur les cookies, les méthodes de requête, les paramètres d’URL et les clés de cache. Testez avec deux sessions indépendantes avant le déploiement et confirmez que les modifications de contenu invalident le cache concerné.
Améliorez ce que le navigateur affiche
Identifiez l’élément LCP réel dans une trace de performance. S’il s’agit d’une image, exposez son URL dans le HTML initial, fournissez des variantes de taille adaptée et ne la chargez pas en différé. S’il s’agit de texte, examinez les styles bloquant le rendu et le chargement des polices. Réservez l’espace des images et des contenus intégrés pour limiter les décalages de mise en page.
Pour l’INP, reproduisez l’interaction lente et examinez le thread principal. Réduisez le travail inutile, découpez les tâches longues et regroupez les lectures de mise en page avant les écritures. Reporter du travail à une tâche ultérieure n’aide que si cette tâche ne devient pas à son tour un gros bloc.
// Yield between bounded chunks; feature-detect the scheduling API.
async function yieldToBrowser() {
if (globalThis.scheduler?.yield) {
await globalThis.scheduler.yield();
} else {
await new Promise(resolve => setTimeout(resolve, 0));
}
}
// Process a small, measured batch, yield, then process the next batch.Vérifiez l’expérience après le déploiement
Les seuils « bons » des Core Web Vitals sont un LCP de 2,5 secondes ou moins, un INP de 200 millisecondes ou moins et un CLS de 0,1 ou moins, évalués au 75ᵉ centile des visites. Le TTFB aide au diagnostic, mais ce n’est pas en soi une Core Web Vital. Un test de chargement Lighthouse ne mesure pas l’INP de sessions réelles.
Retestez le tunnel de commande, la navigation, les outils de consentement et les widgets tiers. Suivez les mesures terrain dans la durée ; la fenêtre de collecte glissante ne reflétera pas immédiatement une mise en production. Consignez le changement et toute régression à côté de vos mesures.
Questions fréquentes
Réussir les Core Web Vitals garantit-il un meilleur classement ?
Non. Une expérience plus rapide aide les lecteurs et peut soutenir les performances dans la recherche, mais la pertinence, l’utilité du contenu et d’autres signaux comptent toujours. Traitez la vitesse comme une amélioration produit mesurable, pas comme une promesse de classement.
Le TTFB fait-il partie des Core Web Vitals ?
Non. Le TTFB mesure le délai jusqu’au premier octet de la réponse et aide à diagnostiquer le chemin serveur et réseau. Les Core Web Vitals sont le LCP, l’INP et le CLS. Servez-vous du TTFB pour enquêter sur une réponse lente, puis vérifiez séparément quand le contenu utile apparaît et comment se comportent les interactions.
Pourquoi ma page d’accueil en cache est-elle rapide alors que le tunnel de commande est lent ?
Une page d’accueil publique peut réutiliser du HTML en cache, alors que le tunnel de commande exige un travail neuf et propre à chaque session. Mesurez la requête sans cache et examinez les requêtes à la base de données, les extensions et les services externes. Ne rendez pas le tunnel de commande cacheable publiquement juste pour améliorer un test ; vérifiez la confidentialité et l’exactitude des transactions.
Comment comparer les performances avant et après un changement ?
Gardez comparables l’URL, l’appareil, le profil réseau et l’état du cache, et répétez le test. Notez l’éventail des résultats et testez la même action client. Utilisez les données terrain à mesure qu’elles deviennent disponibles ; un seul test de laboratoire rapide ne décrit pas tous les visiteurs. La checklist de performance propose une séquence de vérification plus large.
Sources et lectures complémentaires
Pour aller plus loin
Utilisez la checklist de vitesse WordPress en 47 points pour élargir l’audit, ou découvrez le service de performance web.
Leave a Reply