Pourquoi votre site WordPress est-il lent ? Causes et solutions

Un site WordPress lent s’explique presque toujours par l’une de ces quatre causes : un serveur qui met trop de temps à générer chaque page, l’absence de cache de pages, trop de travail effectué par les extensions et le thème, ou des images et des scripts trop lourds dans le navigateur. La solution consiste à identifier laquelle vous pénalise réellement, puis à les traiter dans l’ordre, en commençant par la réponse du serveur et en terminant par les finitions côté front-end.

Mesurez avant de modifier quoi que ce soit

Deviner est la manière la plus coûteuse d’accélérer WordPress. Avant de désactiver des extensions ou de changer d’hébergeur, établissez une base de référence à laquelle vous pourrez comparer vos résultats.

• Données d’utilisateurs réels : passez votre URL dans corewebvitals.page. Si votre site a assez de trafic, l’outil affiche les données terrain de vrais utilisateurs de Chrome pour le LCP, l’INP et le CLS. Ce sont elles que Google utilise pour l’expérience de page.
• Données de laboratoire : la section Lighthouse juste en dessous correspond à un seul chargement simulé. Elle aide à repérer les causes, mais le score varie d’un test à l’autre.
• Réponse du serveur : vérifiez combien de temps prend le HTML lui-même.

curl -s -o /dev/null -w "TTFB: %{time_starttransfer}s\n" https://example.com/

Lancez la commande plusieurs fois et pour plusieurs types de pages : la page d’accueil, un article, une archive de catégorie. Si le premier octet prend déjà plus d’une seconde environ, le problème se situe côté serveur, et aucune extension d’images ne le résoudra. web.dev conseille de viser, à titre indicatif, un TTFB de 0,8 seconde ou moins (en anglais).

Pour aller plus loin sur les données de laboratoire et de terrain, et sur la façon de mener un test avant/après équitable, consultez le guide pour mesurer correctement la vitesse d’un site.

Hébergement et temps de réponse du serveur

Chaque requête WordPress non mise en cache démarre PHP, charge le cœur de WordPress, toutes les extensions actives et le thème, puis exécute des dizaines, voire des centaines de requêtes en base de données. La vitesse de ce processus dépend fortement du serveur.

Signes que l’hébergement est le goulot d’étranglement

• Le TTFB est élevé même sur des pages simples avec peu de contenu.
• Le site ralentit nettement aux heures de pointe ou pendant l’envoi d’une newsletter.
• L’interface wp-admin est poussive, alors qu’elle n’a rien à voir avec les ressources front-end.
• Le tableau de bord de votre hébergeur montre que les limites de CPU ou de mémoire sont atteintes.

Ce que vous pouvez faire

• Mettez PHP à jour. Les versions récentes de PHP sont généralement plus rapides et reçoivent encore des correctifs de sécurité. Vérifiez quelle version votre hébergeur propose et testez votre site sur la plus récente prise en charge par vos extensions.
• Ajoutez un cache d’objets persistant. Redis ou Memcached conserve en mémoire les résultats des requêtes répétées en base de données. De nombreux hébergeurs infogérés le proposent sous forme d’option à activer ; il aide surtout sur les pages dynamiques et dans wp-admin.
• Passez à une offre supérieure ou changez d’hébergeur si le serveur est tout simplement sous-dimensionné pour votre trafic. C’est parfois vraiment la bonne réponse, et aucun réglage d’extension ne remplace un CPU suffisant.

Si le temps de réponse est votre principal problème, le guide dédié pour réduire le TTFB détaille pas à pas les corrections côté serveur, application et edge.

Cache de pages

Le cache de pages est le levier le plus puissant pour la plupart des sites WordPress. Au lieu de construire la même page avec PHP et MySQL pour chaque visiteur, le site sert directement une copie en cache du HTML final. Le manuel développeur de WordPress propose une bonne vue d’ensemble des différentes couches de cache (en anglais).

Vous avez trois options courantes :

Ces couches peuvent fonctionner ensemble. L’essentiel est que les visiteurs anonymes reçoivent du HTML en cache, et que les pages qui doivent rester personnelles en soient exclues.

Ce qui ne doit pas être mis en cache

• Les utilisateurs connectés et wp-admin (WordPress pose des cookies de connexion, et la plupart des caches se contournent en leur présence).
• Les aperçus de commentaires et les articles protégés par mot de passe.
• Le panier, la commande et les pages de compte si vous gérez une boutique. Le guide pour accélérer WooCommerce détaille ces règles.

Vérifier que le cache fonctionne

Regardez les en-têtes de réponse. La plupart des caches ajoutent un en-tête qui indique un hit ou un miss :

curl -sI https://example.com/ | grep -i -E "cache|age"

Si chaque requête affiche un miss, ou s’il n’y a aucun en-tête de cache, quelque chose contourne le cache. Les coupables habituels sont une extension qui pose un cookie à chaque visite, des en-têtes Cache-Control: no-cache envoyés par une extension de sécurité, ou des paramètres d’URL issus de liens de suivi.

Extensions et thèmes

Le nombre d’extensions compte moins que ce qu’elles font. Une seule extension mal conçue peut ajouter plus de charge que vingt petites.

Repérer les plus gourmandes

• Installez Query Monitor sur une copie de préproduction (staging). Il affiche, pour chaque chargement de page, les requêtes en base de données, les requêtes lentes, les appels à l’API HTTP et les hooks par extension.
• Cherchez les extensions qui effectuent des requêtes HTTP externes au chargement de la page (vérifications de licence, compteurs sociaux, polices distantes). Elles bloquent la page en attendant un autre serveur.
• Désactivez les suspectes une par une sur la préproduction et mesurez de nouveau le TTFB. Ne faites pas cela sur une boutique en production.

Schémas courants qui ralentissent les sites

• Les constructeurs de pages qui chargent tout leur CSS et JavaScript sur chaque page, même là où ils ne servent pas.
• Les sliders, pop-ups et widgets de chat qui chargent plusieurs scripts au-dessus de la ligne de flottaison.
• Les extensions d’articles similaires et de statistiques qui exécutent des requêtes lourdes à chaque visite.
• Plusieurs extensions qui font le même travail (deux extensions SEO, deux extensions de cache).

Un thème plus léger aide souvent davantage que n’importe quelle extension d’optimisation. Si votre thème embarque un framework volumineux que vous utilisez à peine, ce code s’exécute quand même sur chaque page.

Images et médias

Les images représentent généralement la plus grande part du poids d’une page WordPress, et l’image hero est souvent l’élément qui détermine votre LCP.

• Téléversez des tailles raisonnables. Une photo de 4 000 pixels prise au téléphone n’a rien à faire dans une colonne de contenu de 800 pixels. WordPress génère des tailles plus petites et utilise srcset, mais seulement si le thème les affiche correctement.
• Utilisez des formats modernes. WebP et AVIF sont bien plus légers que JPEG et PNG à qualité comparable.
• Chargez en différé sous la ligne de flottaison, pas au-dessus. WordPress ajoute automatiquement loading="lazy", mais le chargement différé de l’image hero retarde le LCP. Assurez-vous que l’image principale se charge immédiatement.
• Définissez la largeur et la hauteur pour que le navigateur réserve l’espace et que la mise en page ne saute pas (CLS).

Le guide pour optimiser les images pour le web approfondit les formats, les dimensions et la stratégie de chargement.

Base de données et tâches de fond

Les sites WordPress anciens accumulent un encombrement qui ralentit chaque requête non mise en cache.

• Options chargées automatiquement : les extensions stockent leurs réglages dans wp_options, et les entrées marquées autoload sont lues à chaque requête. Les extensions supprimées laissent souvent derrière elles des entrées volumineuses. La Santé du site, dans les versions récentes de WordPress, avertit lorsque les données chargées automatiquement deviennent trop importantes.
• Les transients expirés et les révisions d’articles gonflent les tables. Nettoyez-les avec une extension de maintenance ou WP-CLI, après une sauvegarde.
• WP-Cron exécute par défaut les tâches planifiées lors des affichages de pages normaux. Sur les sites très fréquentés, désactivez-le dans wp-config.php et déclenchez-le plutôt avec une vraie tâche cron du serveur :

define( 'DISABLE_WP_CRON', true );

• API Heartbeat : les onglets d’éditeur ouverts envoient des requêtes à admin-ajax.php à intervalles réguliers. Sur un hébergement modeste, cela finit par peser ; certaines extensions de performance permettent d’en réduire la fréquence.

Corrigez dans le bon ordre

Travailler dans le bon ordre fait gagner du temps, car les premières étapes rendent souvent les suivantes inutiles.

1. Mesurez le TTFB et les Core Web Vitals sur vos types de pages les plus importants.
2. Corrigez la réponse du serveur : version de PHP, cache d’objets, ressources suffisantes.
3. Activez le cache de pages pour les visiteurs anonymes et vérifiez les en-têtes de cache.
4. Supprimez ou remplacez les extensions lourdes et allégez ce que charge le thème.
5. Optimisez les images : taille, format, pas de chargement différé sur l’image hero.
6. Nettoyez la base de données et confiez WP-Cron à une tâche cron du serveur.
7. Mesurez à nouveau avec les mêmes outils et les mêmes pages, puis comparez.

Si vos visiteurs viennent de plusieurs pays, la distance jusqu’à votre serveur ajoute aussi de la latence à chaque requête, même avec un bon cache sur l’origine. C’est là qu’un cache edge est utile.

Comment fast.site vous aide

fast.site se place devant votre hébergement WordPress existant. Vous gardez votre hébergeur et votre site ; vous ajoutez votre domaine dans le tableau de bord et faites pointer vos serveurs de noms vers fast.site. fast.site gère ensuite votre DNS : vérifiez donc que tous les enregistrements existants, y compris les enregistrements MX pour les e-mails, figurent dans la zone DNS de fast.site.

Les pages consultées par des visiteurs anonymes sont alors servies par Fast Edge Cache™ depuis des serveurs edge proches de vos visiteurs, dans les régions disponibles avec votre offre. Un cache HIT n’atteint jamais votre origine, ce qui soulage le serveur aux heures de pointe. Les sessions connectées et wp-admin doivent contourner le cache, et l’en-tête de réponse fs-cache indique HIT, MISS ou BYPASS pour que vous puissiez vérifier chaque page vous-même. Après une publication, vous pouvez purger des URL individuelles dans le tableau de bord ou via l’API, et un cache warmer garde les pages clés à jour dans le cache.

Côté front-end, fast.site peut convertir à la volée les JPEG et PNG en WebP (AVIF selon l’offre) et, en option, précharger l’image hero et ajouter les dimensions d’image manquantes. Consultez la page WordPress et la documentation sur le cache pour les détails.

Mesurez votre site avant et après avec les mêmes tests. Vous pouvez l’essayer avec un essai gratuit de 7 jours, sans carte bancaire.

Questions fréquentes

Pourquoi mon site WordPress est-il lent uniquement quand je suis connecté ?

La plupart des caches de pages contournent les utilisateurs connectés : chaque page que vous consultez est donc générée à nouveau par PHP. La barre d’administration et les scripts de l’éditeur ajoutent du travail supplémentaire. Testez dans une fenêtre de navigation privée pour voir ce que reçoivent réellement les visiteurs.

Trop d’extensions ralentissent-elles WordPress ?

Le nombre compte moins que ce que fait chaque extension. Quelques extensions lourdes qui lancent des requêtes lentes ou appellent des services externes à chaque visite coûtent plus que beaucoup de petites. Utilisez Query Monitor sur un site de préproduction pour repérer les plus gourmandes.

Une extension de cache suffit-elle ?

Pour un petit site aux visiteurs locaux, une extension de cache bien configurée sur un hébergement correct suffit souvent. Si vos visiteurs sont répartis dans plusieurs régions, ou si vous connaissez des pics de trafic, un cache edge devant le serveur réduit la distance et soulage l’origine.

Pourquoi l’administration de mon site WordPress est-elle lente ?

wp-admin n’est jamais mis en cache : il reflète donc la vitesse brute de votre serveur, de vos extensions et de votre base de données. Des pages d’administration lentes révèlent généralement un hébergement sous-dimensionné, l’absence de cache d’objets, des options autoload trop volumineuses ou une extension qui effectue un travail lourd à chaque requête d’administration.