Un site WordPress lent peut gêner la lecture, l’ouverture du menu ou l’envoi d’une demande. Avant de changer d’hébergement ou d’ajouter une extension, il faut identifier ce qui attend : le serveur, un média, un script ou une interaction. Ce guide propose un ordre de diagnostic et une façon de vérifier les corrections. Il ne promet ni score PageSpeed déterminé, ni augmentation des ventes.
Choisir les pages et les parcours à mesurer
Commencez par les pages utiles à votre activité : l’accueil, une page de service, le contact et, pour une boutique, une fiche produit et le parcours de commande. Notez leurs adresses, le navigateur, l’appareil, les conditions du test et la date. Un relevé isolé sur une seule page ne décrit pas tout le site.
Préparez aussi une liste de gestes à refaire après chaque correction : ouvrir le menu, consulter une réalisation, utiliser un filtre, remplir un formulaire de test et retrouver sa confirmation. Si une amélioration accélère l’affichage mais casse une de ces actions, elle n’est pas prête à être publiée. Pour un nouveau projet, ces parcours peuvent être cadrés dès la création du site vitrine.
Distinguer le score de test de l’expérience réelle
Le score Lighthouse est une mesure en conditions simulées. Les données de terrain décrivent des visites réelles lorsqu’un échantillon est disponible. Un score de laboratoire ne remplace pas ces données ; leur absence ne prouve pas que le site est rapide ou lent.
Les trois Core Web Vitals sont le LCP pour l’affichage du principal contenu, l’INP pour la réactivité et le CLS pour les décalages visuels. Les seuils « bons » sont respectivement de 2,5 secondes, 200 millisecondes et 0,1 au plus. L’évaluation de terrain se fait au 75e percentile, en distinguant mobile et ordinateur. Ces repères sont détaillés dans la documentation Web Vitals. Le TTFB peut aider au diagnostic, mais ce n’est pas un quatrième Core Web Vital.
Vérifier le serveur avant d’envisager une migration
Un délai avant la première réponse mérite une vérification de l’hébergement, de la configuration et du travail exécuté par WordPress. Demandez les versions utilisées et les limites réellement atteintes, plutôt que de déduire les performances du seul prix de l’abonnement.
WordPress recommande actuellement PHP 8.3 ou plus, MariaDB 10.11 ou plus ou MySQL 8.0 ou plus, ainsi que HTTPS. Consultez les prérequis officiels de WordPress avant une évolution. Une version compatible avec WordPress doit aussi être testée avec le thème et les extensions du site. Prévoyez une sauvegarde vérifiée, un environnement d’essai et un retour arrière. Changer de version ne garantit pas un gain chiffré.
Traiter le média qui retarde le premier écran
Identifiez d’abord l’élément LCP dans le diagnostic : ce n’est pas nécessairement le logo ni la première image du document. Si c’est une image, vérifiez son poids, ses dimensions, sa découverte par le navigateur et son ordre de chargement. Ne mettez pas toutes les images en haute priorité.
L’image LCP ne doit pas être chargée paresseusement. Une priorité élevée peut être pertinente pour une image réellement critique, à vérifier dans le chargement des ressources. Google précise ces distinctions dans son guide d’optimisation du LCP.
Pour votre contrôle visuel, comparez le premier écran sur mobile et ordinateur : le média doit rester net, correctement cadré et ne pas repousser le contenu pendant son affichage. Réduire le poids ne doit pas produire une image illisible. Conservez la charte graphique et les photographies autorisées ; la performance n’exige pas de remplacer les visuels par des illustrations inventées.
Examiner les scripts qui gênent les interactions
Une page déjà visible peut encore mal répondre. L’exécution de scripts et les tâches longues peuvent retarder une interaction ; le travail effectué par ses gestionnaires peut aussi ralentir le prochain affichage. Le guide d’optimisation de l’INP recommande d’identifier ces délais et de limiter ou répartir le travail bloquant.
Partez d’un geste précis qui gêne l’utilisateur, puis retrouvez les scripts impliqués. Ne désactivez pas une ressource simplement parce qu’elle est volumineuse : elle peut gérer le menu, le consentement, un paiement ou une confirmation. Essayez une modification à la fois, avec une liste des pages concernées. Conservez la fonction utile et contrôlez les messages d’erreur, pas seulement le chronomètre.
Configurer le cache sans casser les contenus variables
Le cache de page peut servir une version déjà préparée et réduire le traitement demandé au serveur. Le cache du navigateur et celui des objets répondent à d’autres besoins. Les possibilités dépendent de l’hébergement et du contenu ; la documentation d’optimisation WordPress présente ces différents leviers. Empiler des extensions de cache n’est pas un diagnostic.
Listez ce qui varie selon le visiteur avant de toucher aux règles : connexion, panier, commande, données privées ou confirmation de formulaire. Vérifiez les exclusions avec le responsable technique et testez dans un environnement adapté. Contrôlez ensuite une première visite et une visite répétée, ainsi que l’affichage après modification d’un contenu. Une réponse rapide ne doit jamais présenter à quelqu’un les informations d’un autre utilisateur.
Recevoir les corrections avec un vrai avant-après
Refaites les mesures sur les mêmes pages et dans les mêmes conditions. Gardez les captures, les réglages appliqués et les éventuelles différences de contexte. Présentez séparément le résultat du test de laboratoire, les données de terrain disponibles et la vérification fonctionnelle. Ne transformez pas un score en preuve de ventes supplémentaires.
- Les contenus, médias et liens restent présents sur les pages contrôlées.
- Le menu, le thème et les actions importantes fonctionnent sur mobile et ordinateur.
- Les formulaires de test et, si nécessaire, les commandes de test suivent le parcours attendu, sans engager une vente réelle.
- Les redirections, adresses canoniques et règles d’indexation prévues sont conservées.
- Les anomalies sont corrigées avant livraison et un retour arrière reste disponible.
Relier la performance au SEO et à l’entretien du site
De bons Core Web Vitals ne garantissent pas une première place dans Google. La pertinence du contenu et l’expérience globale comptent aussi ; Google déconseille de poursuivre un score parfait uniquement pour le référencement. Sa documentation sur l’expérience de page explicite cette limite.
Une correction doit donc s’inscrire dans le travail de référencement du site, sans remplacer la réponse aux besoins du visiteur. Prévoyez des contrôles après les évolutions importantes et précisez ce qui relève de la maintenance. Pour discuter de votre WordPress, transmettez quelques pages et le problème rencontré via le formulaire de contact. Le périmètre de l’intervention et les vérifications à livrer sont à définir avant de commencer.
