Site lent : les causes fréquentes et l'ordre des vérifications

Un site WordPress lent n’a presque jamais une cause unique. Il additionne trois ou quatre petits excès qui, pris séparément, passeraient inaperçus : une bannière de deux mégaoctets, quatre extensions qui chargent leurs scripts partout, un thème généreux en fonctions inutilisées, une formule d’hébergement saturée aux heures de pointe. La tentation consiste à installer une extension de mise en cache et à espérer. Elle masque parfois le problème, elle ne le résout pas. Le diagnostic gagne à suivre un ordre stable, du plus fréquent au plus rare, et à mesurer avant et après chaque modification plutôt qu’à changer cinq choses d’un coup.

Mesurer avant de toucher à quoi que ce soit

Sans point de départ chiffré, aucune amélioration ne se prouve. Trois indicateurs suffisent à cadrer une situation.

Le temps de réponse du serveur mesure le délai entre la demande du navigateur et le premier octet reçu. Il reflète le travail de fabrication de la page. Le poids total de la page additionne toutes les ressources téléchargées : images, feuilles de style, scripts, polices. Le nombre de requêtes compte les allers-retours nécessaires avant l’affichage complet.

Un site vitrine sain se situe le plus souvent sous une seconde de temps de réponse, sous le mégaoctet de poids total et sous une cinquantaine de requêtes. Ces repères ne sont pas des normes officielles, mais un écart marqué sur l’un des trois désigne immédiatement la piste à suivre.

Une distinction évite de longues errances. Le temps de réponse du serveur relève de ce qui se passe avant l’envoi de la page : requêtes en base, exécution du code, assemblage par le thème. Le poids et le nombre de requêtes relèvent de ce qui se passe après, dans le navigateur du visiteur. Un site dont le serveur répond en deux secondes n’a pas le même problème qu’un site qui répond vite mais télécharge huit mégaoctets d’images. Confondre les deux conduit à installer une solution inadaptée et à conclure que rien ne fonctionne.

Il faut aussi mesurer plusieurs pages, et pas seulement l’accueil. Une page d’accueil optimisée peut masquer une page de contenu bien plus lourde, chargée d’une galerie ou d’un élément intégré. Trois pages représentatives donnent une image bien plus fidèle qu’une mesure unique.

La mesure se prend toujours dans les mêmes conditions : même page, même outil, connexion comparable, et navigation privée pour éviter le cache du navigateur. Mesurer la page d’accueil connectée en administrateur donne des résultats trompeurs, car la barre d’outils et les scripts de l’interface s’ajoutent au chargement.

Site WordPress lent : les causes classées par fréquence

L’expérience des petits sites fait ressortir un ordre assez stable. Le tableau ci-dessous le résume, avec le symptôme qui trahit chaque cause.

Suivre cet ordre évite de commencer par le plus difficile. Un site lent dont les images pèsent quatre mégaoctets n’a pas besoin d’un changement d’hébergement : il a besoin d’une heure de préparation d’images.

Les images, encore et toujours

Les fichiers visuels représentent souvent soixante à quatre-vingts pour cent du poids d’une page vitrine. Une photographie envoyée telle qu’elle sort d’un appareil pèse plusieurs mégaoctets pour une largeur très supérieure à ce que l’écran affichera. La correction est mécanique : redimensionner, compresser, choisir un format moderne. La méthode complète figure dans notre article sur le poids et les formats des images.

Le chargement différé complète utilement ce travail en retardant le téléchargement des images situées hors de l’écran. Une exception : la grande image visible dès l’ouverture doit en rester exclue, sinon elle apparaît avec un temps de retard visible. Les versions récentes du logiciel appliquent déjà cette exception aux premières images de la page ; le contrôle consiste à vérifier qu’un thème ou une extension ne la remet pas en cause.

Extensions et thème : la chasse au superflu

Chaque extension active ajoute du code exécuté à chaque visite, parfois des requêtes en base, souvent des fichiers chargés sur toutes les pages, y compris celles qui n’en ont aucun usage. Une extension de formulaire qui charge ses scripts sur les vingt pages d’un site alors qu’un seul formulaire existe illustre parfaitement le problème.

La méthode de tri se déroule sur un environnement de test, jamais en production. On désactive toutes les extensions, on mesure, puis on les réactive une par une en mesurant à chaque fois. L’écart apparaît sans ambiguïté, et il surprend souvent : une seule extension représente fréquemment la moitié du surpoids constaté.

La question à se poser pour chacune est simple : quelle fonction visible pour le visiteur cette extension apporte-t-elle ? Celles qui ne répondent pas se désinstallent. Une extension seulement désactivée reste présente sur le serveur et continue d’occuper de l’espace, sans bénéfice.

Certaines catégories pèsent plus lourd que d’autres. Les constructeurs de pages, les diaporamas animés, les galeries à effets et les outils statistiques embarqués figurent régulièrement en tête des mesures. À l’inverse, une extension de formulaire simple ou une extension de sauvegarde qui travaille en arrière-plan n’ont pratiquement aucun effet sur l’affichage public. La charge visible ne se répartit donc pas uniformément : deux ou trois composants concentrent presque toujours le surpoids.

Un dernier point échappe souvent à l’attention : les polices de caractères. Un thème qui charge quatre familles de polices en six graisses télécharge des fichiers considérables avant d’afficher le moindre texte. Se limiter à deux familles et à trois graisses produit un gain immédiat, sans perte visuelle réelle.

Le thème se teste selon la même logique. Basculer temporairement sur un thème sobre de la bibliothèque officielle et remesurer donne une réponse immédiate. Si l’écart est important, le thème est en cause, et les critères de sélection d’un remplaçant figurent dans notre analyse consacrée au choix d’un thème.

Le cache : ce qu’il fait, ce qu’il ne fait pas

Sans cache, chaque visite déclenche une reconstruction complète de la page : interrogation de la base, assemblage par le thème, exécution des extensions. Avec un cache de pages, la première visite déclenche cette fabrication, puis le résultat est conservé et servi tel quel aux suivantes. Le gain sur le temps de réponse est souvent spectaculaire, en particulier sur un hébergement mutualisé.

Trois précautions accompagnent cette mise en place. Le cache doit se vider automatiquement à chaque publication ou modification, faute de quoi les visiteurs verront une version périmée. Les pages qui doivent rester dynamiques, comme une confirmation de formulaire, s’excluent explicitement. Le contrôle du résultat se fait toujours en navigation privée, sinon on mesure son propre cache de navigateur.

Un cache mal réglé produit des symptômes déroutants : modifications invisibles, formulaires qui se comportent bizarrement, affichage différent selon le navigateur. Devant un comportement incohérent après une intervention, vider le cache est le premier réflexe à avoir.

D’autres couches existent : cache d’objets, compression des fichiers, réseau de diffusion. Elles apportent un gain réel sur des sites à trafic important et restent souvent superflues sur une vitrine de huit pages dont les images ont été correctement préparées.

Deux options proposées par la plupart des extensions de cache méritent une mention à part, parce qu’elles causent presque tous les incidents rencontrés après leur activation. La combinaison des fichiers de style et de script en un fichier unique réduit le nombre de requêtes et casse parfois une mise en page ou une animation. Le report du chargement des scripts améliore l’affichage initial et peut désactiver un menu déroulant ou un formulaire. Ces deux réglages s’activent un par un, avec un contrôle du site entre chaque, jamais ensemble dans la précipitation.

Hébergement, base de données et ressources externes

Quand les images sont légères, les extensions triées, le thème sobre et le cache actif, et que la lenteur persiste, l’infrastructure entre en jeu.

Une lenteur qui n’apparaît qu’à certaines heures désigne un serveur partagé saturé. La version de PHP employée compte également : les versions récentes exécutent le même code sensiblement plus vite que les anciennes, et le passage à une version supérieure se fait le plus souvent depuis l’espace client, après une sauvegarde. Les critères qui distinguent une bonne formule d’une formule juste bon marché sont détaillés dans notre article sur l’hébergement et l’installation.

La base de données s’encombre avec le temps : révisions d’articles conservées sans limite, contenus supprimés qui restent en corbeille, tables abandonnées par des extensions désinstallées. Un nettoyage périodique allège l’ensemble, précédé d’une sauvegarde puisque l’opération touche directement au contenu. L’effet se ressent surtout dans l’administration, plus rarement sur les pages publiques.

Les ressources externes, enfin, échappent à votre contrôle. Polices distantes, cartes intégrées, lecteurs vidéo, outils de mesure : chacun ajoute des connexions vers d’autres serveurs, et une seule ressource lente suffit à retarder l’affichage complet. Héberger localement ce qui peut l’être, et retirer ce qui ne sert plus, produit souvent un gain immédiat pour un effort minime.

Un site WordPress lent se répare presque toujours dans cet ordre, et rarement par une seule action spectaculaire. Mesurer, corriger un point, remesurer : la méthode est lente à décrire et rapide à appliquer. Elle a surtout l’avantage de dire ce qui a marché, ce qu’aucune intervention groupée ne permet jamais de savoir.