Pourquoi votre site WordPress est lent : six causes, par ordre de fréquence

« Mon site est lent » est un symptôme, pas un diagnostic. La réponse réflexe — installer une extension de cache — masque le problème dans un cas sur deux et l’aggrave dans les autres. Voici ce qu’on trouve réellement en ouvrant le capot, par ordre de fréquence.

Mesurer avant de toucher à quoi que ce soit

Un point de méthode, parce qu’il détermine tout le reste. Avant la moindre modification, relevez deux chiffres : le temps de réponse du serveur seul, et le poids total d’une page. Le premier isole l’hébergement, le second isole le contenu.

Sans ces deux repères, on optimise à l’aveugle et on ne sait jamais ce qui a produit le gain — donc ce qu’il faut reproduire ailleurs.

1. Des images publiées telles quelles

De loin la première cause, et la plus facile à corriger. Une photo sortie d’un téléphone pèse 4 à 8 Mo pour 4 000 pixels de large, affichée dans un cadre qui en fait 800. Le navigateur télécharge la totalité, puis réduit.

Sur une page d’accueil avec huit photos de chantier, cela représente 30 Mo à télécharger pour afficher l’équivalent de 800 Ko d’information utile. Sur une connexion mobile en zone moyennement couverte, on parle de dizaines de secondes.

Le correctif

• Redimensionner avant l’envoi, à la taille maximale d’affichage réelle.
• Servir un format moderne — WebP ou AVIF — qui divise le poids par trois à cinq à qualité équivalente.
• Déclarer largeur et hauteur dans le code, ce qui règle au passage les sauts de mise en page.
• Différer le chargement des images situées hors de l’écran au premier affichage.

2. Trop d’extensions actives

Chaque extension ajoute du code exécuté à chaque visite, et souvent ses propres fichiers CSS et JavaScript sur toutes les pages — y compris celles qui ne l’utilisent pas. Un formulaire de contact présent sur une seule page charge fréquemment ses ressources sur les quarante autres.

Le nombre compte moins que la nature. Une extension de sauvegarde qui tourne la nuit est sans effet sur vos visiteurs. Un constructeur de pages, un curseur d’images ou un module d’avis clients pèsent sur chaque affichage. Au-delà de vingt extensions actives, la question n’est plus de savoir s’il y a un problème mais lequel.

Le correctif

Désactiver une extension à la fois, en vérifiant le site après chaque désactivation. Les candidates évidentes sont celles installées pour tester une idée abandonnée depuis, et celles qui font doublon — deux extensions de référencement, trois systèmes de formulaires.

3. Un thème polyvalent et son constructeur

Un thème conçu pour convenir à tous les métiers embarque de quoi servir tous les métiers. Le constructeur visuel qui l’accompagne produit en outre un empilement de conteneurs imbriqués sur cinq ou six niveaux là où deux suffiraient. Le navigateur doit calculer cette structure à chaque affichage, sur chaque appareil.

C’est la cause la plus difficile à traiter, parce qu’elle est structurelle : on ne l’allège qu’à la marge. C’est aussi celle qui fait basculer un dossier de « réparation » vers « refonte ».

4. Un hébergement mutualisé saturé

Sur une offre à 3 € par mois, votre site partage un serveur avec plusieurs centaines d’autres. Le symptôme est caractéristique : un temps de réponse initial qui dépasse la seconde, avant même le moindre téléchargement, et qui s’effondre aux heures de pointe — typiquement en fin de journée, quand vos visiteurs sont les plus nombreux.

Aucune optimisation côté site ne rattrape ce retard. C’est le seul poste où le remède est un changement de fournisseur, et il coûte rarement plus de quelques euros supplémentaires par mois.

5. Les scripts tiers

Statistiques, cartes interactives, avis clients, discussion en ligne, gestionnaire de consentement, pixels publicitaires. Chacun paraît anodin ; ensemble, ils dépassent souvent le poids du site lui-même.

Ce sont aussi les premiers responsables d’un mauvais INP, car ils monopolisent le fil d’exécution au moment précis où le visiteur essaie de cliquer. Le cas le plus courant : une bannière de consentement qui surveille tout le document et recalcule les styles à chaque mouvement de la page.

Le correctif

Faire l’inventaire honnête. Pour chaque script, une question : qui consulte les données qu’il produit, et à quelle fréquence ? Les outils dont personne ne regarde jamais le tableau de bord se suppriment sans regret. Le reste se charge en différé, après l’affichage du contenu.

6. Une base de données jamais entretenue

Révisions d’articles accumulées par centaines, tables laissées par des extensions désinstallées, données temporaires expirées jamais purgées, journaux d’activité de plusieurs années. L’effet est plus discret que les précédents, mais il devient sensible sur l’administration et sur les pages qui listent beaucoup de contenus.

Un nettoyage annuel suffit, avec une sauvegarde préalable — c’est la seule opération de cette liste où une erreur est irréversible.

Par où commencer

1. Mesurer, pour savoir d’où l’on part.
2. Traiter les images : meilleur rapport gain sur effort, sans exception.
3. Désactiver les extensions inutilisées, une par une.
4. Vérifier le temps de réponse du serveur et changer d’hébergement s’il dépasse 600 millisecondes à vide.
5. Différer ou supprimer les scripts tiers qui ne servent pas directement le visiteur.
6. Nettoyer la base de données, sauvegarde faite.
7. Le cache en dernier.

Ce que le cache ne fera jamais

Cet ordre n’est pas indifférent, et le cache est en dernier pour une raison précise. Une extension de cache garde une copie de la page fabriquée et la ressert. Elle évite donc le travail du serveur — mais elle ne réduit ni le poids des images, ni la quantité de JavaScript, ni le nombre de scripts tiers. Or ce sont eux qui pèsent sur ce que vit réellement le visiteur.

Installer le cache en premier, c’est éteindre le voyant sans ouvrir le capot. Le score de test s’améliore, l’expérience réelle ne bouge pas, et le jour où une page sort du cache — la première visite, une page peu consultée, un contenu qui vient d’être modifié — le visiteur retrouve le site tel qu’il est vraiment.

Un exemple chiffré

Pour rendre l’ordre de grandeur concret, voici une répartition typique constatée sur un site vitrine d’une dizaine de pages, avant intervention.

Trois enseignements se lisent dans ce tableau.

Le premier : les images représentaient à elles seules les deux tiers du poids, et leur traitement a demandé une demi-journée. C’est le meilleur rapport effort sur résultat de toute la liste.

Le deuxième : le poids du thème n’a pas bougé. C’est le propre d’une réparation — on ne touche pas à la structure. Un site sur mesure aurait chargé 120 Ko à cet endroit au lieu de 1,8 Mo, et c’est précisément ce qui distingue une remise en état d’une refonte.

Le troisième : le changement d’hébergement a fait gagner une seconde pleine, sans aucune modification du site. C’est souvent l’intervention la moins chère et la plus rapide, et celle à laquelle on pense en dernier.

Les fausses solutions

Quatre remèdes reviennent constamment dans les forums et font perdre du temps.

Empiler les extensions d’optimisation. Deux extensions de cache qui tournent ensemble se marchent dessus et produisent des pages incohérentes. Une seule, bien configurée, suffit toujours.

Activer toutes les options de minification. Regrouper et compresser les fichiers aide, jusqu’au jour où une option casse un script sans prévenir. Le symptôme est déroutant : un menu qui ne s’ouvre plus, un formulaire qui n’envoie plus, sans qu’aucune erreur ne soit visible. Activez une option à la fois, en vérifiant.

Passer sur un réseau de distribution de contenu pour tout régler. Un CDN rapproche vos fichiers de vos visiteurs, ce qui est utile sur un public international. Sur un site local dont les visiteurs sont à trente kilomètres, le gain est négligeable et ne compensera jamais des images de six mégaoctets.

Supprimer les images pour alléger. Vu plus souvent qu’on ne le croit. Les photos de chantier sont ce qui convainc un visiteur d’appeler : le sujet n’est pas leur nombre, c’est leur poids.

Combien de temps, combien ça coûte

Pour un site vitrine, une optimisation complète représente deux à cinq jours de travail, mesures et vérifications comprises. L’essentiel du gain se produit généralement dès la première journée, sur les images et les scripts tiers.

Si, au terme de ce travail, le site reste lent, le diagnostic change de nature : le problème est structurel, et c’est la question de la refonte qui se pose — sur des chiffres, cette fois, et non sur une impression.