Pourquoi les sites WordPress deviennent lents avec le temps

Un site WordPress ralentit pour cinq raisons cumulatives : chaque extension ajoute des requêtes en base et des fichiers à charger, la base grossit sans jamais être purgée, un constructeur de pages produit du HTML nettement plus lourd que nécessaire, l'hébergement mutualisé se dégrade à mesure que le voisinage se remplit, et personne ne mesure. Aucune de ces causes n'apparaît le jour de la mise en ligne. Toutes se voient au bout de dix-huit à trente-six mois.

Mécanisme 1, l'accumulation d'extensions

Une extension WordPress n'est pas un module isolé. Elle s'accroche au cycle de vie de la page, elle ajoute ses propres requêtes en base, elle charge ses feuilles de style et ses scripts, et elle le fait le plus souvent sur toutes les pages, y compris celles où elle ne sert à rien.

Un formulaire de contact charge son code sur la page d'accueil. Un curseur d'images charge le sien sur les pages qui n'en contiennent pas. Une extension de traduction interroge la base à chaque chaîne affichée.

Le mécanisme est cumulatif et invisible. Chaque ajout coûte peu, quinze ajouts coûtent une seconde. Et personne ne désinstalle jamais rien : sur les sites que nous auditons, il y a toujours des extensions actives qui ne servent plus depuis des années.

Ce qu'on peut faire : un audit périodique, l'exécution conditionnelle des scripts par page, et la désinstallation réelle de ce qui ne sert plus. C'est efficace, et c'est un travail récurrent que personne ne budgète.

Mécanisme 2, la base de données gonfle

WordPress conserve une révision de chaque article à chaque enregistrement. Un article retouché quarante fois porte quarante copies. Les extensions désinstallées laissent leurs tables et leurs options. Les commentaires indésirables s'accumulent. Les métadonnées orphelines survivent aux contenus supprimés.

Une base de plusieurs centaines de mégaoctets pour un site de trois cents pages n'a rien d'exceptionnel. Chaque requête devient plus lente, et WordPress en fait beaucoup par page.

Le cas particulier de WooCommerce mérite d'être signalé : la table des options de WordPress est chargée en grande partie à chaque requête, et certaines extensions y écrivent des données volumineuses qui sont chargées automatiquement. C'est une cause de lenteur importante et discrète.

Ce qu'on peut faire : limiter le nombre de révisions, purger périodiquement, et surveiller les données chargées automatiquement. Cela demande d'y toucher, donc quelqu'un qui sait.

Mécanisme 3, le constructeur de pages

Divi, Elementor, WPBakery et leurs semblables produisent leur mise en page par des conteneurs imbriqués. Une section simple sort en cinq ou six niveaux de div, avec des classes et des styles en ligne.

Le HTML est plus lourd, le CSS aussi, et le constructeur charge sa propre bibliothèque sur chaque page. S'y ajoutent les modules complémentaires, qui suivent la même logique.

Le coût réel n'est pas seulement la vitesse. C'est l'enfermement : une page construite avec ces outils n'existe pas hors d'eux. Le sujet est traité à part dans notre article sur la dette technique des constructeurs de pages.

Ce qu'on peut faire : peu de choses sans changer d'approche. Les optimisations sur un site construit ainsi grattent des dixièmes sur un problème structurel.

Mécanisme 4, l'hébergement

Un hébergement mutualisé bon marché fonctionne bien au lancement. Puis le serveur se remplit, votre trafic augmente, et les ressources sont partagées avec des centaines d'autres sites.

Le symptôme caractéristique : un site rapide aux heures creuses et lent aux heures ouvrées. Si vos mesures varient fortement selon l'heure, l'hébergement est en cause, et aucune optimisation de code ne le compensera.

Ce qu'on peut faire : changer d'hébergement. C'est souvent l'intervention la plus rentable, et la plus rapide à mettre en œuvre.

Mécanisme 5, personne ne mesure

Le mécanisme le plus important, et le plus simple à corriger.

Un site est mesuré à la livraison, puis plus jamais. La dégradation est progressive, donc invisible pour ceux qui l'utilisent tous les jours. On s'en aperçoit quand un client le signale, ou quand le trafic a déjà baissé.

Ce qu'on peut faire : regarder le rapport Signaux web essentiels de la Search Console une fois par trimestre. C'est gratuit, ce sont des mesures réelles chez vos visiteurs, et cela prend cinq minutes.

Ce qui ne règle pas le problème

Les extensions de cache. Elles sont nécessaires et elles ne traitent pas la cause. Un site lourd mis en cache est un site lourd servi plus vite la deuxième fois. Le premier visiteur de chaque page paie toujours le prix, et les moteurs sont souvent ce premier visiteur.

Les extensions d'optimisation. Elles compressent, elles diffèrent, elles combinent. Elles ajoutent aussi une extension de plus. Sur un site déjà chargé, le gain net est faible et les effets de bord fréquents.

Ajouter des ressources serveur. Cela repousse le seuil sans changer la pente.

Quand il faut arrêter d'optimiser

Il existe un moment où le coût cumulé des interventions dépasse celui d'une reconstruction. Trois signaux le désignent.

Vous n'osez plus mettre à jour. Parce que la dernière fois quelque chose a cassé. C'est le signal le plus fiable : le site n'est plus maintenable, il est seulement conservé.

Chaque modification demande un développeur. Alors que le site avait justement été construit pour être modifiable par l'équipe.

Les optimisations ne produisent plus rien. Vous avez fait le cache, les images, l'hébergement, et vous restez au-dessus des seuils. La cause est structurelle.

À ce stade, la discussion change de nature : elle porte sur ce que le site doit faire dans les cinq prochaines années, pas sur la façon de gagner deux dixièmes. C'est l'objet de notre article sur la migration de WordPress vers Next.js.

Questions fréquentes

WordPress est-il lent par nature ?

Non. Un WordPress avec un thème sobre, peu d'extensions et un bon hébergement est rapide. Ce qui ralentit, c'est l'accumulation dans le temps, favorisée par un modèle où chaque besoin se résout en installant quelque chose. La question n'est pas ce dont l'outil est capable, mais ce qu'il devient sans entretien.

Combien d'extensions est-ce trop ?

Le nombre importe moins que ce que chacune charge sur la page publique. Vingt extensions qui n'agissent que dans l'administration pèsent moins que cinq qui injectent des scripts partout. Regardez ce qui se charge réellement dans le code source d'une page, pas la liste des extensions actives.

Une extension de cache suffit-elle ?

Elle améliore le temps de réponse pour les pages déjà visitées et ne change rien au poids de ce qui est envoyé. Sur les Signaux web essentiels, mesurés chez de vrais visiteurs, l'effet est réel mais partiel. Une page de trois mégaoctets reste une page de trois mégaoctets, mise en cache ou non.

Faut-il changer d'hébergeur avant d'optimiser ?

Si vos mesures varient fortement selon l'heure de la journée, oui, commencez par là : c'est le symptôme d'un mutualisé saturé, et toute autre optimisation sera masquée par cette variabilité. Sinon, faites d'abord l'inventaire des extensions et le poids des images, qui coûtent moins cher à corriger.

Ce qu'il faut retenir

La dégradation d'un WordPress n'est pas un accident, c'est le résultat prévisible d'un modèle où l'on ajoute sans jamais retrancher. Elle se ralentit par de l'entretien régulier, et elle ne s'arrête que par un choix d'architecture. Ce que Next.js règle et ce qu'il ne règle pas est détaillé dans notre article sur les Core Web Vitals, et nous menons ces migrations, c'est l'objet de notre page migration WordPress vers Next.js.