Vous testez votre site WordPress dans PageSpeed Insights, sur mobile, et la note s’affiche en rouge. C’est le lot commun : selon HTTP Archive, le site WordPress médian obtient 43 sur 100 à ce test. Pourtant, près d’un site WordPress sur deux passe les seuils de Google sur mobile. La note et le verdict ne mesurent pas la même chose.
Le verdict, ce sont les Core Web Vitals : trois mesures relevées sur les vraies visites de votre site. Google s’en sert pour classer les pages. Et sur mobile, les sites WordPress perdent du temps à un endroit précis, avant même que la page ne s’affiche.
Nous créons et maintenons des sites WordPress. Voici ce que Google mesure vraiment, où ces sites ralentissent, et ce que vous pouvez vérifier vous-même.
Google ne regarde pas votre note, il observe vos visiteurs
Les trois Core Web Vitals décrivent ce que vit une personne qui ouvre votre page. Google fixe un seuil pour chacun.
Le LCP mesure le temps d’affichage du plus gros élément visible, souvent l’image principale ou le titre. Il doit rester sous 2,5 secondes.
L’INP mesure le délai de réaction après un toucher ou un clic : 200 millisecondes au plus. Il a remplacé l’ancien indicateur, le FID, en mars 2024.
Le CLS mesure les sauts de mise en page, pendant le chargement et tant que la page reste ouverte. Son score doit rester sous 0,1.
Ces mesures viennent des navigateurs Chrome de vos visiteurs, sur les 28 derniers jours. Une page passe quand au moins trois visites sur quatre respectent chaque seuil. Mobile et ordinateur sont jugés séparément. Dans la Search Console, la plus mauvaise des trois mesures donne son verdict à tout un groupe de pages.
Google utilise ces mesures pour classer les pages, sans en faire un critère décisif. Sa documentation l’écrit noir sur blanc. « La recherche Google s’efforce de toujours afficher le contenu le plus pertinent, même si l’expérience sur la page est décevante. » La vitesse ne remplace donc pas le contenu. Elle compte d’abord pour vos visiteurs, et Google la mesure.
PageSpeed Insights mélange deux mondes. En haut, les données de vos vrais visiteurs, quand Google en a. En dessous, un test de laboratoire : un téléphone Moto G Power simulé, sur une connexion 4G lente. La note sur 100 vient de ce test. Il ne mesure pas l’INP : il le remplace par un indicateur voisin, le Total Blocking Time.
Encore faut-il que Google ait des données. Chrome ne publie les mesures que des sites assez fréquentés, selon un seuil qui n’est pas communiqué. En dessous, la Search Console reste vide et PageSpeed affiche « Aucune donnée ». C’est le cas de notre propre page d’accueil, comme vous le verrez plus bas.
Sur mobile, WordPress perd du temps dès le serveur
HTTP Archive publie chaque mois ces mesures pour des millions de sites, classés par technologie. En septembre 2026, 48 % des sites WordPress passaient les trois seuils sur mobile. L’ensemble du web faisait à peine mieux, avec 53 %.
Le détail est plus parlant que la moyenne. WordPress devance l’ensemble du web sur deux mesures. En réactivité, 90 % de bons scores, contre 79 %. En stabilité, 87 % contre 83 %. Il décroche sur l’affichage du contenu principal : 55 % de bons LCP, contre 66 % pour l’ensemble du web.
La cause se lit une étape plus tôt. Le temps de réponse du serveur ne fait pas partie des Core Web Vitals. Mais chaque milliseconde perdue avant le premier octet se retrouve dans le LCP. Seuls 23 % des sites WordPress répondent en moins de 0,8 seconde, le seuil jugé bon par Google. C’est deux fois moins que l’ensemble du web.
Sans cache, WordPress reconstruit chaque page à chaque visite. Le code PHP interroge la base de données, assemble la page, puis l’envoie. Chaque extension peut ajouter ses propres requêtes. Sur un hébergement mutualisé, le serveur partage en plus ses ressources avec d’autres sites.
Nous l’avons vu sur un site de recettes belge. Hébergé sur l’offre mutualisée la plus haute d’OVH, il atteignait régulièrement les limites de ressources de son serveur. Résultat : des ralentissements et un site instable. Son extension de cache, mal réglée, servait même par moments une redirection vers la page d’installation de WordPress.
Un cache de pages bien configuré supprime l’essentiel de cette attente. Le serveur envoie une copie prête, sans rien recalculer. Si l’hébergement reste trop lent malgré tout, mieux vaut changer d’hébergeur qu’empiler les extensions d’optimisation.
Une image lente attend plus qu’elle ne charge
Le LCP se découpe en quatre étapes. Le serveur répond. Le navigateur lit la page et repère l’image principale. Il la télécharge. Puis il l’affiche.
Sur web.dev, Brendan Kenny a mesuré ces étapes sur les visites réelles de Chrome, tous sites confondus. Sur un site typique au LCP mauvais, le serveur met 2,27 secondes à répondre. L’image attend ensuite 1,29 seconde avant que son téléchargement ne commence. Le téléchargement lui-même ne prend que 0,35 seconde.
Compresser ses images règle donc rarement le problème. Il faut que le serveur réponde plus vite, et que le navigateur découvre l’image principale plus tôt.
Sur WordPress, trois habitudes retardent cette découverte. La première : une extension qui charge toutes les images en différé, y compris celle du haut de page. La deuxième : une image d’en-tête posée en arrière-plan, comme le permettent les constructeurs de pages. Le navigateur ne la trouve qu’après avoir lu les feuilles de style.
La troisième : un diaporama en haut de page, dont la première image attend souvent son script. Google le résume sans nuance : l’image principale ne doit jamais être chargée en différé.
WordPress fait déjà le ménage, vos extensions le défont parfois
Le cœur de WordPress a beaucoup travaillé sur ce point. En 2022, sur web.dev, Felix Arntz et Rick Viscomi ont fait un constat. Appliqué partout, le chargement différé pouvait ralentir l’affichage des pages WordPress. Le logiciel s’est corrigé.
Depuis la version 6.3, sortie en 2023, WordPress ne diffère plus les premières images d’une page. Il désigne aussi au navigateur l’image la plus susceptible d’être l’élément principal. Le navigateur la charge alors en priorité.
Ce n’est pas le seul réglage automatique. Depuis la version 5.5, WordPress ajoute largeur et hauteur aux images de vos contenus qui n’en ont pas. Elles ne font ainsi plus sauter le texte en arrivant. Depuis la 6.8, sortie en 2025, il précharge aussi la page vers laquelle pointe un lien. Il suffit que le visiteur commence à cliquer dessus.
Ces réglages ne valent que si rien ne les écrase. Certaines extensions d’optimisation remplacent les images par des espaces réservés, puis les chargent en JavaScript. L’image principale se retrouve alors différée, comme avant 2023. Avant d’en installer une, vérifiez qu’elle épargne l’image du haut de page. Et gardez en tête que chaque extension peut charger son propre code sur chaque page.
Réactivité et stabilité : les points forts à ne pas gâcher
Sur la réactivité, WordPress part avec une longueur d’avance. Ce qui la menace, ce sont les tâches longues de JavaScript. Tant que le processeur du téléphone les exécute, la page ne répond pas au toucher.
Les constructeurs de pages, souvent accusés, n’entament guère cette réactivité. Ils pèsent sur le chargement. Selon HTTP Archive, 41 % des sites sous Elementor ont un bon LCP sur mobile, et 48 % sous Divi. Pour WordPress dans son ensemble, c’est 55 %. Ces chiffres décrivent les sites qui utilisent ces outils, pas l’outil seul.
Chez Tenakoe, nous avons justement retiré le constructeur. Construit sous Divi, le site était lourd et pénalisé sur mobile. Le nouveau thème, écrit pour lui, s’en passe. Son CSS est intégré à la page, ses polices sont hébergées sur le site, et il n’appelle aucun service tiers.
Sur la stabilité, les décalages qui restent viennent souvent d’éléments greffés au site. Publicités, vidéos intégrées sans place réservée, polices web : tout ce qui arrive après le texte peut le pousser. Sur web.dev, Katie Hempenius et Barry Pollard désignent un suspect habituel. « Les bandeaux de consentement aux cookies sont une source très courante de décalages de mise en page » (notre traduction).
Le remède est simple : un bandeau posé en bas de l’écran, par-dessus la page, ne pousse rien. Sur mobile, un long bandeau peut même devenir l’élément mesuré par le LCP.
Ce que vous pouvez vérifier vous-même cette semaine
Quatre contrôles, dans cet ordre.
Ouvrez la Search Console, rapport Core Web Vitals, côté mobile. Il classe vos pages en trois états, de « Bon » à « Médiocre », sur des visites réelles. S’il reste vide, Google n’a pas assez de données sur votre site.
Testez vos trois pages les plus visitées dans PageSpeed Insights, version mobile. Lisez d’abord le bloc du haut : vos vrais visiteurs. Le test de laboratoire, dessous, sert à trouver les causes. Notre page d’accueil en donne un exemple : 96 sur 100 au test, mais pas encore de données de visiteurs.
Toujours dans ce test, déroulez la Répartition du LCP. Si la réponse du serveur domine, regardez l’hébergement et le cache. Si le délai avant le chargement pèse lourd, l’image principale est découverte trop tard.
Dans WordPress, ouvrez Outils > Santé du site. Depuis la version 6.1, WordPress vérifie lui-même qu’un cache de pages est actif. Il contrôle aussi que le serveur répond en moins de 600 millisecondes.
Enfin, faites la liste de vos scripts tiers : fenêtre de discussion, pixels, bandeau de cookies, polices externes. Gardez ceux qui servent, retirez les autres, puis refaites le test.
Si le diagnostic pointe vers le serveur ou les extensions, c’est le quotidien de nos contrats de maintenance. Ils couvrent aussi l’hébergement et l’infogérance du serveur. Et si votre site doit changer de base technique, exposez-nous votre besoin.
Commentaires