Optimiser un site WordPress : par où commencer, et dans quel ordre

Cherchez comment accélérer WordPress et vous tombez sur des listes : trente astuces, cinquante extensions, toutes les options activées. Suivez-en une et l’histoire habituelle commence. Le score bouge, puis un menu ne s’ouvre plus, un formulaire n’envoie plus, et personne ne sait lequel des dix réglages en est la cause.

Ce guide prend l’autre chemin. Il vous donne un ordre : ce qu’il faut mesurer d’abord, comment trouver le vrai problème, et quel levier actionner pour lui, du plus sûr au plus délicat. Chaque étape renvoie vers un guide dédié quand vous voulez aller plus loin.

Ce que « rapide » veut dire pour Google

Google juge la vitesse d’une page avec trois indicateurs, les Core Web Vitals, mesurés sur vos vrais visiteurs :

• LCP (Largest Contentful Paint) : le moment où le contenu principal, souvent l’image du haut ou le titre, s’affiche. Bon sous 2,5 s.
• INP (Interaction to Next Paint) : le temps que met la page à réagir à un toucher ou à un clic. Bon sous 200 ms.
• CLS (Cumulative Layout Shift) : à quel point le contenu saute pendant le chargement. Bon sous 0,1.

Le verdict est rendu au 75e centile des visites sur 28 jours : trois visites sur quatre doivent être bonnes. Un seul test lancé depuis votre ordinateur rapide n’en dit pas grand-chose.

Étape 1 : mesurer le terrain d’abord, puis le labo

Il existe deux sortes de données, et elles répondent à des questions différentes :

• Les données de terrain (Search Console, et la section du haut de PageSpeed Insights) viennent de vos vrais visiteurs. Elles vous disent s’il y a un problème, et où.
• Les données de labo (le score de PageSpeed Insights, Lighthouse) viennent d’un chargement simulé. Elles aident à comprendre pourquoi, et à vérifier un changement tout de suite.

Commencez par le rapport Core Web Vitals de Search Console. Il regroupe vos URL par pages similaires, c’est-à-dire le plus souvent par modèle de page : accueil, articles, fiches produit, catégories, pages d’atterrissage. C’est l’unité sur laquelle vous allez travailler, parce qu’une correction dans un modèle corrige toutes les pages construites dessus.

Avant de changer quoi que ce soit, notez le point de départ de chaque modèle : les trois métriques de terrain, et un test labo sur mobile. Quand les deux ne sont pas d’accord, et c’est fréquent, notre guide sur les données de labo et de terrain explique comment les lire.

Étape 2 : trouver quelle métrique échoue, sur quel modèle

Chaque métrique renvoie à une famille de causes différente. C’est ce qui vous évite de tout activer :

• LCP mauvais : le serveur répond tard, ou l’image principale arrive tard (trop lourde, découverte tard, chargée en différé par erreur, bloquée derrière les feuilles de style).
• CLS mauvais : images sans espace réservé, police web qui change en cours de route, bandeau ou bloc injecté après le premier affichage.
• INP mauvais : trop de JavaScript sur le fil principal, venu du thème, du builder ou de services tiers.

Regardez aussi le temps de réponse du serveur (TTFB, affiché dans PageSpeed Insights). Si le HTML lui-même met plus de 0,8 s environ à arriver, aucune optimisation côté navigateur ne rattrapera ce retard : l’étape suivante passe en premier.

Étape 3 : le serveur et le cache de page

WordPress construit chaque page en PHP, avec des requêtes en base de données, à chaque visite. Un cache de page garde le HTML terminé et le sert directement aux visiteurs suivants : c’est le levier qui agit le plus sur le temps de réponse, et sur un site de contenu il est sans risque pour les visiteurs anonymes.

• Un seul moteur de cache, pas deux. Beaucoup d’hébergeurs mettent déjà les pages en cache côté serveur. Empiler un cache d’extension par-dessus crée deux couches qui se purgent à des moments différents, et vous finissez par servir des pages périmées. Choisissez-en une pour gérer le cache de page.
• Vérifiez les bases de l’hébergement : une version de PHP encore maintenue, et un cache d’objets (Redis ou Memcached) si le site est dynamique.
• Les sites avec comptes ou panier ont besoin d’une frontière entre ce qui peut être mis en cache et ce qui ne doit jamais l’être. Sur WooCommerce, cette frontière est tout le sujet de notre guide pour accélérer une boutique WooCommerce.

Étape 4 : les images et l’image principale

Les images sont en général la partie la plus lourde d’une page, et la principale est souvent le LCP. Les premiers gestes sont tous sans risque, parce qu’ils envoient la même image en moins d’octets : compression, format moderne (WebP ou AVIF), et bonne taille pour l’écran. Si PageSpeed vous demande encore de dimensionner correctement les images malgré un srcset, la cause est presque toujours l’attribut sizes : voyez notre guide srcset et sizes.

Occupez-vous ensuite de l’image principale elle-même :

• ne la chargez jamais en différé : le lazy loading est fait pour les images sous la ligne de flottaison ;
• aidez le navigateur à la trouver tôt avec un preload et une priorité de chargement haute, et si elle diffère entre téléphone et desktop, préchargez-en une par appareil ;
• si c’est un fond CSS posé par un builder, le navigateur la découvre tard : notre guide sur les heros en image de fond montre les corrections ;
• et gardez les grandes illustrations hors du SVG inline, qui alourdit le HTML lui-même : le SVG inline, c’est pour les icônes.

Étape 5 : le CSS

Le navigateur n’affiche rien tant qu’il n’a pas téléchargé et lu les feuilles de style du <head>. Sur un thème à builder, cela peut représenter plusieurs centaines de kilo-octets, dont la plupart ne servent pas sur la page en cours. Deux techniques s’en occupent :

• Le Critical CSS : les styles de ce qui est visible au chargement sont insérés dans la page, et la feuille complète se charge sans bloquer.
• Le CSS utilisé (souvent appelé « Supprimer le CSS inutilisé ») : les règles que la page n’utilise pas sont retirées.

Les deux sont très efficaces, et les deux peuvent casser quelque chose, parce qu’ils jugent à partir d’un seul instantané de la page. Un menu, une fenêtre modale ou un mini-panier fermés à ce moment-là semblent inutiles, et perdent leurs styles. Comment retrouver la règle manquante et la remettre : notre guide sur les styles manquants, avec deux cas fréquents : le menu qui s’affiche ouvert et le mini-panier qui disparaît.

Étape 6 : le JavaScript et la réactivité

Le JavaScript pèse sur tout : il concurrence l’image principale sur le réseau, et il occupe le fil principal quand le visiteur touche l’écran. Le levier le plus fort consiste à reporter les scripts inutiles au chargement jusqu’à la première interaction. C’est aussi le levier qui casse le plus de sites :

• un menu qui ne s’ouvre qu’au deuxième toucher : notre guide sur le menu burger ;
• un slider, un formulaire ou un bandeau de consentement qui ne marche plus : comment trouver le script fautif ;
• un bandeau de consentement qui arrive tard et retient le reste : notre guide sur les bandeaux de consentement.

Ne reportez jamais ce dont le visiteur a besoin tout de suite : l’outil de consentement, le menu, les scripts d’ajout au panier et de paiement. Et connaissez la limite de l’exercice : certains thèmes livrent tout leur code dans un seul gros fichier, ce qui plafonne ce que toute optimisation peut faire. Comment les repérer.

Étape 7 : la stabilité de la mise en page

Un contenu qui saute a rarement une seule grosse cause, plutôt plusieurs petites : des images sans width ni height, une police web qui change la taille du texte en arrivant, un bandeau cookies ou une barre promo qui pousse la page vers le bas, un slider qui démarre dans un état et finit dans un autre. Réservez l’espace, et choisissez exprès le font-display de vos polices : swap affiche le texte tout de suite mais peut le déplacer à l’arrivée de la police, optional ne le déplace jamais mais garde parfois la police de secours. Les builders ajoutent leurs propres causes, traitées dans notre guide CLS pour Divi et Elementor.

Votre builder, votre boutique

L’ordre ci-dessus vaut pour tous les sites WordPress. Certaines configurations ont leurs propres pièges, avec un guide dédié :

• Divi : beaucoup de CSS et d’images de fond d’origine, et des options qui font doublon avec n’importe quelle extension d’optimisation. Accélérer un site Divi, étape par étape.
• Elementor et Divi : des décalages de mise en page propres aux builders. Corriger le CLS sur les thèmes à builder.
• WooCommerce : cache, fragments de panier, images produit et scripts de paiement. Accélérer une boutique WooCommerce.

La méthode qui garde le site en état de marche

Tous les leviers ne se valent pas. Certains réduisent seulement le poids des fichiers ou donnent une indication au navigateur, et ne peuvent rien casser. D’autres changent ce qui s’exécute, dans quel ordre, ou ce qui est servi, et demandent un test. Notre guide sur les optimisations sans risque les trie un par un.

Avec Mantys Core

En résumé

• Lisez d’abord les données de terrain, modèle par modèle : elles vous disent s’il y a un problème et où.
• Associez la métrique qui échoue à sa famille de causes : LCP au serveur et aux images, CLS à l’espace réservé, INP au JavaScript.
• Corrigez dans l’ordre : serveur et cache de page, images, CSS, JavaScript, stabilité.
• Activez d’abord les leviers sans risque, puis les délicats un par un, en testant sur mobile et desktop, déconnecté.
• Confirmez en labo tout de suite, et sur le terrain quatre semaines plus tard.