Les causes liées à l’hébergement (et que votre hébergeur ne met pas en avant)

1. Un hébergement mutualisé saturé

C’est la cause la plus fréquente et la moins avouée. Sur un hébergement mutualisé, vous partagez les ressources serveur (CPU, RAM, bande passante) avec des dizaines, parfois des centaines d’autres sites. Quand l’un d’eux connaît un pic de trafic, c’est tout le voisinage qui ralentit.

Solution : migrer vers un hébergement VPS ou un hébergeur spécialisé WordPress comme Kinsta ou WP Engine. Le surcoût est réel, mais le gain de performance l’est tout autant — et il est immédiatement mesurable.

2. Un serveur géographiquement éloigné de votre audience

Si votre hébergeur a ses serveurs aux États-Unis et que 90 % de votre trafic est français, chaque requête fait un aller-retour transatlantique. Ce TTFB (Time To First Byte) élevé plombe tous vos scores de performance, indépendamment des optimisations front-end.

Solution : choisir un datacenter en Europe (Paris, Francfort, Amsterdam), et compléter avec un CDN (Content Delivery Network) comme Cloudflare pour servir les ressources statiques depuis le nœud le plus proche du visiteur.

3. L’absence de PHP 8.x

WordPress tourne sur PHP, et la version de PHP installée sur votre serveur a un impact direct sur les performances. PHP 8.2 est en moyenne 3 fois plus rapide que PHP 7.4 sur des benchmarks WordPress équivalents. Beaucoup d’hébergements mutualisés restent sur des versions obsolètes par défaut.

Solution : vérifier la version PHP active dans votre panel d’hébergement (cPanel, Plesk) et la mettre à jour vers PHP 8.2 ou 8.3. Vérifier au préalable la compatibilité de vos plugins via PHP Compatibility Checker.

Les causes liées aux plugins (le vrai problème, pas le nombre)

4. Des plugins qui chargent leurs scripts sur toutes les pages

C’est l’erreur la plus sous-estimée. Un plugin de formulaire de contact charge ses scripts CSS et JavaScript sur chaque page du site — y compris celles où il n’y a aucun formulaire. Multipliez par dix plugins de ce type, et vous avez une page d’accueil qui charge 40 ressources inutiles.

Solution : utiliser un plugin comme Asset CleanUp pour désactiver les scripts et styles plugin par plugin, page par page. C’est chronophage mais l’impact sur le LCP (Largest Contentful Paint) est immédiat.

5. Des plugins redondants qui font la même chose

Deux plugins de cache actifs simultanément. Un plugin SEO et un plugin de sitemap séparés. Un plugin d’optimisation d’images et un CDN qui optimise déjà les images. Ces redondances créent des conflits, des ressources doublées et parfois des comportements imprévisibles.

Solution : auditer votre liste de plugins avec Query Monitor pour identifier les doublons fonctionnels et les conflits de ressources.

6. Des plugins abandonnés qui génèrent des requêtes inutiles

Un plugin non maintenu depuis deux ans peut continuer à faire des requêtes SQL régulières en base de données — pour vérifier des licences, synchroniser des données, nettoyer des tables. Ces requêtes fantômes consomment des ressources sans que vous le sachiez.

Solution : désactiver et supprimer tout plugin non mis à jour depuis plus de 12 mois, ou dont vous n’utilisez plus activement la fonctionnalité. La désactivation seule ne suffit pas — un plugin désactivé peut encore laisser des tables en base.

Les causes liées à la base de données

7. Une base de données non optimisée

WordPress stocke absolument tout en base : les révisions d’articles, les données de sessions, les transients expirés, les métadonnées d’images supprimées. Au bout de quelques années, une base de données WordPress non entretenue peut peser plusieurs centaines de mégaoctets — ce qui ralentit chaque requête.

Solution : utiliser WP-Optimize pour nettoyer les révisions, les commentaires spam, les transients expirés et optimiser les tables InnoDB. Planifier ce nettoyage mensuellement.

8. Un nombre de révisions illimité

Par défaut, WordPress conserve une révision à chaque sauvegarde d’article. Un article révisé 50 fois génère 50 entrées en base. Sur un site avec 200 articles publiés, cela représente potentiellement des milliers de révisions inutiles.

Solution : ajouter cette ligne dans le fichier wp-config.php : define('WP_POST_REVISIONS', 3); Et nettoyer les révisions existantes via WP-Optimize.

9. Des requêtes SQL non optimisées générées par le thème

Certains thèmes premium — notamment les constructeurs de pages type Avada, Divi ou BeBuilder — génèrent des dizaines de requêtes SQL par chargement de page pour récupérer leurs options de configuration. Query Monitor permet de visualiser en temps réel le nombre et le temps d’exécution de chaque requête.

Solution : si le thème génère plus de 50 requêtes SQL par page, c’est un signal d’alarme. Envisager un thème plus léger comme GeneratePress ou Kadence.

Les causes liées aux médias et au front-end

10. Des images au mauvais format

JPEG et PNG sont encore largement dominants sur les sites WordPress en production. Or, le format WebP offre une compression supérieure de 25 à 35 % à qualité équivalente, et AVIF fait encore mieux. Ces formats modernes sont pris en charge par tous les navigateurs récents.

Solution : convertir automatiquement les images au format WebP via Imagify ou ShortPixel. Activer le chargement lazy load natif HTML (loading="lazy") pour les images hors écran.

11. Un thème qui charge une police Google Fonts à chaque page

Google Fonts est pratique, mais chaque appel à l’API Google génère une requête externe qui peut ajouter 200 à 400 ms au chargement. Certains thèmes chargent trois ou quatre familles de polices différentes, avec plusieurs graisses chacune.

Solution : héberger les polices localement via OMGF (Optimize My Google Fonts) ou réduire le nombre de variantes chargées au strict nécessaire.

12. Un slider ou carousel en page d’accueil

Les sliders JavaScript sont parmi les pires ennemis du LCP. Ils chargent toutes leurs images simultanément (même celles non visibles), injectent du JavaScript lourd et bloquant, et retardent l’affichage du contenu principal. Google lui-même déconseille explicitement leur usage dans ses recommandations UX.

Solution : remplacer le slider par une image statique unique, optimisée et chargée en priorité via l’attribut fetchpriority="high". L’impact sur le LCP est spectaculaire.

Les causes liées à la configuration WordPress

13. L’absence de cache serveur (pas juste de cache plugin)

Un plugin de cache comme W3 Total Cache ou WP Rocket génère des fichiers HTML statiques pour éviter de reconstruire la page à chaque visite. Mais sans cache serveur (OPcache pour PHP, ou cache Redis/Memcached pour la base de données), les gains restent partiels.

Solution : vérifier avec votre hébergeur si OPcache PHP est activé. Pour les hébergements qui le permettent, activer Redis comme système de cache objet — WP Redis permet de l’intégrer nativement à WordPress.

14. Des redirections en chaîne non nettoyées

Chaque refonte, chaque changement de plugin SEO, chaque réorganisation de contenu laisse des traces sous forme de redirections. Avec le temps, certaines URLs passent par trois ou quatre redirections successives avant d’atteindre leur destination — chaque saut ajoutant 50 à 150 ms au TTFB.

Solution : auditer l’intégralité des redirections actives avec Screaming Frog et aplatir toutes les chaînes (A→B→C devient A→C directement).

15. Un fichier wp-cron.php qui s’exécute sur chaque visite

WordPress utilise un système de tâches planifiées (WP-Cron) pour gérer les publications programmées, les vérifications de mise à jour, les emails automatiques. Par défaut, ce système se déclenche à chaque chargement de page — ce qui signifie que chaque visiteur peut déclencher involontairement une tâche de fond.

Solution : désactiver WP-Cron natif en ajoutant define('DISABLE_WP_CRON', true); dans wp-config.php, puis configurer une vraie tâche CRON système via le panel d’hébergement pour exécuter wp-cron.php toutes les 15 minutes. La documentation officielle WordPress détaille la procédure complète.