Un site à plus de 80 extensions qui chargeait en 7 secondes

Le client nous a contactés en urgence. Leur plateforme de formation en ligne, principale source de revenus, était devenue pratiquement inutilisable. Les sessions figeaient. L'administration de la boutique refusait de répondre. Les pages prenaient entre 5 et 7 secondes à charger pour un utilisateur connecté, avec des pointes mesurées à 38 secondes au moment du diagnostic.

Deux entreprises avaient été contactées avant nous. Toutes les deux avaient proposé de faire un audit. On a choisi une approche différente : demander les accès complets et entrer directement dans le système pour régler le problème, pas seulement le documenter.

Un paradoxe matériel

La première chose qui frappe quand on regarde la configuration : le serveur est costaud. 24 coeurs, 31 Go de mémoire vive. Du matériel largement suffisant pour faire tourner une plateforme de cette taille sans aucun problème. Et pourtant, un site WordPress lent à ce point, sur cette infrastructure, c'est un signal clair : le problème n'est pas là où on le cherche habituellement.

La réponse réflexe, dans ce genre de situation, c'est d'installer un plugin de cache. C'est souvent pertinent sur un site vitrine ou un blogue. Mais cette plateforme combine une boutique transactionnelle, des cours en ligne et un espace communautaire de membres. Les pages des utilisateurs connectés sont générées en direct, en fonction de leur profil, de leurs achats, de leur progression. Elles ne peuvent pas être mises en cache de façon classique. Un plugin de cache aurait aidé les visiteurs non connectés, rien de plus.

Il fallait comprendre ce qui se passait réellement.

Ce que le diagnostic a révélé

Premier constat, et probablement le plus spectaculaire : environ 71 secondes cumulées de requêtes réseau externes à chaque chargement de page. Pas des appels qui tournaient en arrière-plan pendant que la page s'affichait. Des appels synchrones : le site attendait une réponse avant de continuer. Un plugin tentait de joindre un serveur externe qui ne répondait plus. Un autre validait sa licence sur un serveur en erreur. Le résultat, c'est que chaque visite d'un utilisateur connecté déclenchait une série d'attentes qui s'empilaient avant que le moindre contenu s'affiche.

Deuxième constat : les réglages serveur étaient ceux, génériques, qui conviennent à la majorité des sites, mais pas à une plateforme de cette complexité. Le cache de compilation des scripts n'était que partiellement actif. Une partie des fichiers était bien servie depuis la mémoire, mais le reste était recalculé à chaque visite. Sur un site de cette complexité, avec plus de 80 extensions actives, c'est une quantité considérable de travail répété inutilement.

Troisième constat : un mécanisme interne de WordPress s'emballait. Des requêtes répétées toutes les quinze secondes, même sur des pages où ce comportement n'avait aucune utilité. Multipliées par des dizaines d'utilisateurs connectés simultanément, ces requêtes saturaient les processus serveur disponibles. On mesurait environ 35 processus actifs en même temps, là où une plateforme bien configurée n'en aurait pas eu besoin de plus d'une dizaine.

Quatrième constat : toutes les extensions se chargeaient sur toutes les pages, sans distinction. Les scripts de la boutique s'exécutaient sur les pages de cours. Des outils d'administration s'activaient côté visiteur. Chaque affichage déclenchait un volume de travail sans rapport avec ce que la page demandait réellement.

Cinquième constat, contre-intuitif : un plugin conçu pour optimiser les images ralentissait le site. Il analysait des milliers d'images de façon synchrone à chaque chargement, ajoutant une charge importante à chaque requête.

Aucun de ces problèmes, pris isolément, n'aurait suffi à expliquer des temps de 38 secondes. Ensemble, ils formaient un engorgement systématique.

Ce qui a changé

On a coupé les appels réseau qui bloquaient l'affichage. Pas désactivé les plugins concernés, mais coupé les appels inutiles qui empêchaient la page de se construire. On a ajusté la configuration du serveur au volume particulier de ce site. On a calmé le mécanisme interne qui se déclenchait trop souvent et trop largement. On a fait en sorte que chaque page ne charge que ce dont elle a réellement besoin. Et on a servi les visiteurs non connectés à partir de pages statiques, ce que la structure du site permettait enfin de faire correctement.

Le design n'a pas bougé d'un pixel. Aucune extension essentielle n'a été désactivée.

Les résultats

Les chiffres sont mesurés avant et après, sur les mêmes pages, dans les mêmes conditions.

• Pages de cours pour un utilisateur connecté : de 5 à 7 secondes à 1,5 seconde
• Page d'accueil pour un visiteur non connecté : de 5 à 7 secondes à quasi instantané
• Interface d'administration de la boutique : de plus de 5 secondes à 2,2 secondes
• Temps cumulé des appels réseau externes par page : de 71 secondes à 1 seconde
• Processus serveur simultanés : d'environ 35 à environ 10

De 38 secondes au pire moment du diagnostic à 1,5 seconde pour les utilisateurs connectés. La plateforme est redevenue fonctionnelle. L'administration de la boutique répond. Les sessions ne figent plus.

Le matériel n'est presque jamais le vrai problème

C'est la leçon que je retiens de ce genre de cas, et elle se confirme régulièrement : un site WordPress lent sur un serveur puissant, c'est rarement un problème de ressources. C'est un problème de configuration, de comportement non contrôlé, de charge inutile accumulée couche par couche au fil des mises à jour et des ajouts d'extensions.

Ajouter de la mémoire n'aurait rien réglé ici. Installer un plugin de cache non plus. Ce qui a changé la situation, c'est un diagnostic complet avant toute action, suivi d'interventions ciblées sur les vrais goulots d'étranglement.

Si une plateforme complexe ralentit malgré une infrastructure correcte, la prochaine étape n'est pas un rapport de plus. C'est d'aller voir ce qui se passe réellement, de l'intérieur. C'est exactement ce que nous faisons avec notre service d'optimisation WordPress.