Suivez cette checklist selon ce que montrent les mesures
Cette checklist en 47 points est un audit de travail pour les sites WordPress. Elle ne promet ni temps de chargement ni score précis : l’hébergement, le contenu, les appareils des visiteurs et les besoins métier varient. Partez de l’expérience utilisateur défaillante, choisissez les vérifications pertinentes et validez un type de changement à la fois.
Traitez les goulots d’étranglement mesurés avant le réglage avancé du serveur. Un changement qui économise une petite requête mais casse le tunnel de commande est une régression, même si le score de laboratoire s’améliore.
Établissez la référence
- Choisissez des URL représentatives : accueil, article, archive, produit et commande ; incluez des sessions connectées et anonymes.
- Notez la région d’hébergement, l’appareil, les conditions réseau, le navigateur et la version déployée pour que les tests suivants soient comparables.
- Lancez plusieurs fois des tests de laboratoire reproductibles et conservez l’éventail des résultats, pas seulement le plus rapide.
- Consultez le LCP, l’INP et le CLS d’utilisateurs réels lorsque des données terrain existent ; distinguez les données de l’URL de celles de l’origine.
- Examinez la requête du document et séparez les délais DNS, de connexion et de réponse du serveur.
- Capturez une trace du thread principal en reproduisant l’interaction lente, pas seulement pendant le chargement initial.
- Identifiez l’élément LCP réel et la chaîne de requêtes nécessaire pour l’afficher.
- Faites une sauvegarde restaurable et définissez les parcours utilisateur clés qui doivent encore fonctionner après les changements.
Réduisez le travail de l’origine
- Utilisez une version de PHP maintenue et compatible avec le site ; validez les mises à niveau en préproduction avant la production.
- Vérifiez l’état et la capacité d’OPcache. Ne désactivez pas la vérification des horodatages sauf si le déploiement invalide explicitement le cache.
- Profilez les chemins PHP lents et les requêtes répétées à la base de données avant de modifier les réglages du serveur.
- Examinez les requêtes aux API distantes pendant le rendu des pages ; utilisez un cache adapté et des délais d’expiration bornés.
- Vérifiez avec l’hébergeur le cache d’objets persistant et contrôlez l’invalidation lorsque le contenu change.
- Ne mettez en cache le HTML public que là où c’est sûr ; excluez les réponses authentifiées, de panier, de commande et personnalisées.
- Confirmez que deux utilisateurs différents ne peuvent pas recevoir les données en cache l’un de l’autre.
- Examinez la saturation du processeur, de la mémoire et des processus sous une charge représentative avant d’augmenter la concurrence.
- Validez l’exécution des tâches planifiées. Si vous confiez WP-Cron à un planificateur système, surveillez les tâches manquées et en échec.
- Examinez les plans d’exécution avant d’ajouter des index ; évaluez le surcoût à l’écriture et testez sur une copie de données représentative.
- Passez en revue les options chargées automatiquement trop volumineuses avec l’extension qui les possède. Sauvegardez avant un nettoyage ciblé.
- Paginez les requêtes volumineuses et évitez de charger en mémoire une collection non bornée.
Améliorez le rendu et l’interaction
- Ne supprimez les scripts et styles inutilisés qu’après avoir vérifié les menus, les formulaires, la commande et les besoins de l’éditeur.
- Différez les scripts compatibles en respectant l’ordre des dépendances ; async ne remplace pas une exécution ordonnée.
- Examinez les styles bloquant le rendu. Testez toute approche de CSS critique sur l’ensemble des modèles et des tailles d’écran.
- Gardez l’image LCP découvrable dans le HTML initial au lieu de l’insérer tardivement en JavaScript.
- Ne chargez pas l’image LCP en différé. Utilisez une priorité de téléchargement élevée de façon sélective, puis examinez la cascade.
- Découpez le JavaScript coûteux en morceaux mesurés et rendez la main au navigateur entre eux si nécessaire.
- Regroupez les lectures et écritures de mise en page pour éviter les recalculs forcés répétés.
- Supprimez les widgets tiers inutiles ; ne retardez les widgets facultatifs que si leur comportement et les règles de consentement le permettent.
- Réservez les dimensions des images, contenus intégrés et publicités avant l’arrivée de leurs ressources.
- Vérifiez les métriques des polices de secours et les décalages de mise en page ; utilisez font-display de façon réfléchie.
- Gardez les commandes interactives utilisables au clavier et avec les animations réduites.
- Testez des pages longues et des appareils peu puissants ; une page d’accueil rapide ne prouve pas que tous les modèles le sont.
Servez des ressources de taille adaptée
- Choisissez la largeur de chaque image selon l’emplacement où elle s’affiche et la densité de pixels attendue.
- Comparez AVIF, WebP et les formats existants sur le fichier réel au lieu de supposer un gain fixe.
- Fournissez des candidats srcset responsives et une valeur sizes qui reflète la mise en page.
- Chargez en différé les images hors écran et utilisez le décodage asynchrone lorsque c’est pertinent.
- Gardez en HTML les libellés et explications essentiels ; un petit texte dans une image est difficile à lire.
- Hébergez vous-même les polices ou limitez autrement leurs requêtes ; ne chargez que les graisses et jeux de caractères nécessaires au site.
- Ne préchargez que les ressources vraiment critiques, après avoir vérifié la cascade des requêtes.
- Vérifiez la compression gzip ou Brotli des ressources texte et évitez de recompresser des images déjà compressées.
- Utilisez un cache de longue durée pour les ressources statiques versionnées et changez leur URL lorsque leur contenu change.
- Chargez les vidéos de manière intentionnelle. Masquer une vidéo uniquement en CSS ne garantit pas l’arrêt de son téléchargement.
Vérifiez la mise en production
- Testez la connexion, la recherche, les formulaires de contact, le panier et la commande après avoir activé toute optimisation.
- Examinez les en-têtes de cache et l’invalidation du contenu sur les pages modifiées.
- Répétez les tests de laboratoire de référence dans les mêmes conditions et consignez les gains comme les régressions.
- Suivez les métriques terrain dans la durée ; une mise en production n’apparaît pas immédiatement dans une fenêtre de données glissante.
- Fixez des budgets de performance et tenez un journal des changements pour pouvoir relier une régression ultérieure à une mise en production.
Questions fréquentes
Que corriger en premier ?
Si le document initial est lent, profilez l’origine et le comportement du cache. Si le document arrive vite mais que le contenu principal apparaît tard, examinez la ressource LCP et le chemin de rendu. Si les clics semblent lents après le chargement, analysez le travail JavaScript et de mise en page pendant l’interaction. Gardez cette distinction visible dans vos notes d’audit.
Un score Lighthouse faible entraîne-t-il une pénalité de classement fixe ?
Aucune règle publiée n’attribue de pénalité fixe dans Google à un score Lighthouse inférieur à un seuil donné. Servez-vous du score pour repérer des pistes techniques et des données terrain pour comprendre les visiteurs réels.
Faut-il appliquer les 47 vérifications à chaque site WordPress ?
Non. Utilisez la checklist pour repérer les vérifications pertinentes, puis traitez en priorité le goulot d’étranglement qui touche un parcours client important. Un site vitrine et une boutique WooCommerce très fréquentée n’ont pas les mêmes besoins. Notez pourquoi une vérification est applicable, reportée ou inutile.
Que tester après avoir modifié les réglages de cache ou de scripts ?
Vérifiez les menus, la recherche, les formulaires, la connexion et la commande le cas échéant. Testez avec des sessions distinctes, modifiez et dépubliez du contenu pour contrôler l’invalidation, et comparez les performances à la référence initiale. Gardez un retour arrière disponible si une optimisation casse une interaction indispensable.
Sources et lectures complémentaires
Pour aller plus loin
Approfondissez le diagnostic du TTFB et des Core Web Vitals et la diffusion d’images responsives.




Leave a Reply