Votre site répond encore. Il finit par s'afficher, au bout de dix, vingt ou trente secondes, et le tableau de bord est souvent pire que les pages publiques. Aucun message d'erreur à recopier dans un moteur de recherche, juste un onglet qui tourne.
Ce guide traite ce cas précis, un site qui fonctionnait normalement et qui est devenu inutilisable, et pas l'optimisation d'un site qui va bien. La différence n'est pas cosmétique, elle change l'ordre dans lequel on cherche.
Ce que vous avez sous les yeux
Aucun code, aucune page d'erreur, rien de mesurable au premier regard. Les descriptions se ressemblent toutes : trente-quatre secondes pour charger l'accueil, plusieurs minutes pour se connecter, plusieurs secondes à chaque clic dans l'administration, et souvent une intermittence qui brouille tout.
Dans les outils de développement du navigateur, cela se voit à la première ligne du tableau réseau, bloquée sur Waiting for server response. Cette barre mesure le temps que met le serveur avant de commencer à répondre. Tant qu'elle est longue, compresser une image ou activer un cache ne changera rien, puisque rien de tout cela ne se produit pendant cette attente.
Et ce n'est pas votre ordinateur. Redémarrer la box, vider le cache du navigateur, essayer depuis un autre appareil, tout cela ne coûte que du temps.
En trente secondes
Deux requêtes, rien à installer, aucun compte à créer. Ouvrez un terminal et lancez ceci en remplaçant l'adresse par la vôtre.
curl -s -o /dev/null -w "%{time_starttransfer}\n" https://votre-site.fr/
curl -s -o /dev/null -w "%{time_starttransfer}\n" https://votre-site.fr/readme.html
La première ligne demande votre page d'accueil, qui traverse le serveur web, puis PHP, puis la base de données. La seconde demande un fichier posé sur le disque, qui ne traverse que le serveur web. L'écart entre les deux valeurs est votre diagnostic.
Sur le WordPress sain de notre banc d'essai, la page d'accueil sort à 0,05 seconde et le fichier statique à 0,0006 seconde, presque cent fois moins, parce qu'il n'y a ni PHP ni base derrière lui.
- Le fichier statique est rapide, la page est lente. Le serveur va bien, le temps se passe dans WordPress, dans une extension, dans la base ou dans quelque chose que votre site attend. Les six causes ci-dessous sont pour vous.
- Les deux sont lents. Le problème est en amont de WordPress : le serveur, la machine qui l'héberge, ou le réseau. Ni cache, ni réseau de diffusion, ni compression d'images n'y changera quoi que ce soit.
Un piège rencontré en montant ce test. Beaucoup de tutoriels proposent d'interroger /favicon.ico. Sur notre installation ce fichier n'existe pas physiquement, et la réécriture envoie la requête à WordPress, qui répond quand même 200. PHP a donc tourné, et le test ne mesure plus rien : il rend un chiffre faussement rassurant. Deux en-têtes trahissent WordPress dans la réponse, mesurés ici : Content-Type: text/html; charset=UTF-8 au lieu d'un type de fichier statique, et surtout une ligne Link: <…/wp-json/>; rel="https://api.w.org/", que jamais un fichier servi tel quel ne porte. Vérifiez donc votre fichier témoin avec curl -I avant de l'utiliser : /readme.html est présent sur toute installation et sa réponse ne contient aucune de ces deux lignes.
Le signal gratuit qui va avec. Si un outil de mesure en ligne n'arrive pas à terminer son analyse et renvoie une expiration au lieu d'un score, vous n'avez plus un problème d'optimisation : un outil qui abandonne, c'est un serveur trop lent pour être mesuré.
Notez trois choses avant de demander de l'aide à qui que ce soit : vos deux valeurs, la date où la lenteur a commencé, et si elle est permanente ou par périodes. Sans elles, vous recevrez la liste générique des dix conseils d'optimisation, et vous l'avez déjà lue.
Si votre site est simplement perfectible, ce guide n'est pas le bon
Un site qui charge en deux secondes et que vous aimeriez voir charger en une seconde n'est pas en panne. C'est un travail d'optimisation, qui se mène au calme sur plusieurs jours et relève d'un forfait d'agence, et les trente premières pages de Google sur ce sujet le font très bien.
Ce guide et le dépannage d'un WordPress devenu inutilisable qui va avec traitent l'autre situation : le site ne se travaille plus, il ne s'utilise plus. Vous ne cherchez pas un meilleur score, vous cherchez ce qui a changé.
Si le navigateur affiche un code d'erreur, ce n'est plus ce guide
Un serveur trop lent finit par renoncer. Quand le délai d'attente est dépassé, la page ne s'affiche plus du tout et le navigateur montre un code : 502 Bad Gateway ou 504 Gateway Time-out.
Le mécanisme est le même que celui décrit ici, seul le moment change. Tant que la page finit par s'afficher, même après trente secondes, vous êtes au bon endroit. Dès qu'un code remplace la page, passez au guide de l'erreur 502 et 504, qui traite les deux et dont les premiers gestes diffèrent. Cette frontière n'est écrite nulle part, ni dans les pages sur la lenteur, ni dans celles sur le 504.
Les causes, classées par ce qui a changé
Les articles d'optimisation classent leurs causes par fréquence générale, en commençant par les images. Sur un site devenu lent brutalement, ce classement fait perdre du temps : vos images sont les mêmes qu'avant-hier, quand tout allait bien. Un site ne ralentit pas tout seul, quelque chose a changé. Répondez donc d'abord à ces quatre questions.
| La question | Ce que la réponse désigne |
|---|---|
| Est-ce permanent, ou par périodes ? | Par périodes, regardez la machine partagée et les tâches planifiées. En permanence, regardez le site lui-même. |
| Vos autres sites du même hébergement sont-ils touchés ? | Oui, la cause est commune : la machine, PHP, la base. Non, elle est dans ce site-là. |
| Le public et l'administration sont-ils lents tous les deux ? | L'administration seule, voyez OPcache, l'autoload et les appels externes. Le cache masque très bien un site public malade. |
| Qu'avez-vous touché dans la semaine ? | Une mise à jour, une extension, un réglage d'hébergement. La mise à jour est le suspect le plus commode, et souvent le mauvais. |
Les six causes qui suivent sont classées par le nombre de fils de discussion publics où elles apparaissent comme cause réelle, sur les dix-neuf que nous avons lus en entier. Les trois dernières sont absentes du corpus francophone, ce qui explique qu'on les cherche rarement.
La machine est partagée, et le voisin consomme
Signature : la lenteur va et vient sans logique, votre hébergeur confirme que vos quotas ne sont pas atteints, et il a raison.
En mutualisé, votre site partage un processeur avec des centaines d'autres. Sur un serveur privé aussi, puisqu'un serveur privé est une part d'une machine physique partagée. Quand un voisin s'emballe, vos pages attendent sans que votre consommation ne bouge. Le phénomène porte un nom chez les administrateurs système, le vol de processeur, et il n'est mesurable que de leur côté. C'est la cause la plus citée dans les fils que nous avons lus, et celle qui met le plus de temps à être trouvée, puisque tous vos indicateurs restent au vert.
Ce qui la confirme : vos autres sites du même compte ralentissent en même temps, la lenteur suit des plages horaires, un redémarrage rend le site rapide dix minutes avant que tout recommence.
Ne demandez pas au support si votre compte dépasse ses quotas, la réponse sera non. Demandez si la machine physique présente une charge anormale, si d'autres comptes la saturent, et s'il est possible de vous déplacer sur un autre serveur. Cette formulation obtient des réponses là où « mon site est lent » n'en obtient aucune.
Des robots tapent sur votre site
Ce qui la trahit : la charge est élevée sans que votre trafic réel ait augmenté, et le journal d'accès est plein de la même adresse ou du même fichier.
Deux cas documentés. Quelqu'un a passé des mois à croire que son hébergeur était mauvais : son journal montrait un déluge de requêtes sur xmlrpc.php, au point qu'Apache consommait près de trois gigaoctets de mémoire. Sur le forum officiel, un autre a survécu à la mise à jour des extensions, au passage de PHP 7.4 à 8.1, à la désactivation de tout et au vidage des caches, avant qu'on ne trouve un robot d'indexation qui saturait les processus PHP en tapant en boucle des liens de téléchargement non protégés. Dans les deux cas, la réponse était dans le journal d'accès.
Ce journal se trouve dans le panneau de l'hébergeur, parfois sous le nom de journaux web, ou dans ~/logs/, /var/log/apache2/ ou /var/log/nginx/. On y cherche les adresses les plus bavardes et les fichiers les plus demandés :
awk '{print $1}' access.log | sort | uniq -c | sort -rn | head -20
awk '{print $7}' access.log | sort | uniq -c | sort -rn | head -20
La position des colonnes dépend du format de journal, vérifiez sur une ligne avant de conclure. Ce que vous cherchez saute aux yeux : une adresse avec des dizaines de milliers de requêtes, ou un fichier appelé des milliers de fois par minute, le plus souvent xmlrpc.php, wp-login.php ou un lien de téléchargement d'extension. Pour regarder pendant que le site rame, tail -f suffit.
Interdire xmlrpc.php coupe certaines applications mobiles et certains services connectés : une protection par mot de passe au niveau du serveur sur wp-login.php est plus sûre. Et si vous voyez surtout des fichiers PHP inconnus servis depuis vos dossiers d'envois, la charge vient de votre propre site : le guide du site WordPress piraté prend le relais, et le nettoyage passe avant la performance.
Les tâches planifiées se sont accumulées
Le symptôme est particulier : le site est rapide la plupart du temps, et très lent pour le premier visiteur après une longue période creuse.
WordPress n'a pas d'horloge. Ses tâches planifiées ne se déclenchent pas à l'heure dite mais lors d'une visite. Sur un site à faible trafic elles s'empilent et retombent en bloc sur le premier visiteur du jour, qui attend pendant que le site rattrape son retard. Avec une extension de commerce, ces files se comptent parfois en milliers.
Si votre hébergeur propose WP-CLI, la liste se lit avec wp cron event list. Sur notre installation saine de WordPress 7.1, sans aucune extension, elle compte onze tâches, toutes à échéance future. Si la vôtre en affiche des centaines, ou beaucoup de tâches en retard, vous tenez quelque chose.
La correction consiste à couper le déclenchement à la visite pour le remplacer par une vraie tâche serveur. Dans wp-config.php, avant la ligne qui dit de ne pas toucher à ce qui suit :
define( 'DISABLE_WP_CRON', true );
Puis on crée dans le panneau de l'hébergeur une tâche planifiée qui appelle https://votre-site.fr/wp-cron.php?doing_wp_cron toutes les dix ou quinze minutes. L'avertissement est sérieux : sans cette tâche serveur, plus rien ne s'exécute. Les articles programmés ne se publient pas, les sauvegardes ne partent pas, et rien ne vous prévient.
OPcache est trop petit pour votre site
Signature : l'administration est lente alors que le site public tient encore, et le retard se produit avant même que vos extensions ne commencent leur travail.
OPcache garde en mémoire le code PHP déjà compilé pour éviter de le recompiler à chaque requête. Quand la place manque, une partie du code est recompilée en permanence et le coût est payé sur chaque page. Un praticien a documenté le cas complet : ses pages d'administration sont passées de onze secondes à deux une fois OPcache dimensionné correctement. Son indice de départ désigne la couche PHP comme aucun autre symptôme ne le fait : le cœur de WordPress, seul, sans extensions, mettait plus de trois secondes à se charger.
Sur notre banc d'essai en PHP 8.3, les valeurs par défaut sont opcache.memory_consumption à 128 mégaoctets et opcache.max_accelerated_files à 10 000. Un WordPress nu, thème par défaut et rien d'autre, y occupe déjà 567 fichiers et 31,7 mégaoctets. Ajoutez une boutique, un constructeur de page et cinquante extensions, et vous voyez où passe la marge.
Pour mesurer chez vous, déposez à la racine un fichier zz-opcache.php, appelez-le dans le navigateur, puis supprimez-le aussitôt : il renseigne un visiteur sur votre configuration.
<?php
$s = opcache_get_status( false );
printf( "libre %.1f Mo, fichiers %d sur %s, plein %s, redemarrages %d\n",
$s['memory_usage']['free_memory'] / 1048576,
$s['opcache_statistics']['num_cached_scripts'],
ini_get( 'opcache.max_accelerated_files' ),
var_export( $s['cache_full'], true ),
$s['opcache_statistics']['oom_restarts'] );
Un cache plein signifie que la mémoire est saturée. Des redémarrages autres que zéro signifient qu'il se vide et se reconstruit en boucle, ce qui est le pire des cas. Sur notre installation saine, les deux sont à zéro. Ne recopiez pas les réglages de quelqu'un d'autre, ils dépendent de la mémoire disponible et du nombre de sites qui partagent le même OPcache : en mutualisé, cette mesure sert surtout à formuler une demande précise au support.
La table wp_options s'est remplie d'options chargées à chaque page
Ici la lenteur paraît soudaine alors que l'accumulation, elle, a duré des mois. Ce qui est soudain, c'est le franchissement d'un seuil.
WordPress charge à chaque page un lot d'options marquées pour un chargement automatique, quelques dizaines de kilo-octets sur un site sain. Quand une extension mal réglée y dépose des données temporaires qu'elle ne nettoie jamais, ce lot enfle jusqu'à peser sur chaque requête, administration comprise.
Le seuil au-delà duquel WordPress s'inquiète est écrit dans son propre code, wp-admin/includes/class-wp-site-health.php, fonction get_test_autoloaded_options() : 800 000 octets par défaut. Au-delà, l'écran Outils, Santé du site affiche une alerte que peu de gens savent lire, et qui les renvoie vers leur hébergeur, lequel répond en général à côté.
Sur notre WordPress sain, la mesure donne 50 678 octets pour 121 options, seize fois sous le seuil. La requête se passe dans phpMyAdmin ou par WP-CLI, en adaptant le préfixe wp_ si le vôtre diffère :
SELECT SUM(LENGTH(option_value)) AS octets, COUNT(*) AS nombre
FROM wp_options
WHERE autoload IN ('yes','on','auto','auto-on');
Attention à une requête qui traîne partout et qui ne marche plus. Les articles anglophones et hispanophones donnent tous WHERE autoload = 'yes'. Sur les versions récentes de WordPress, cette colonne ne contient plus yes et no mais on, off et auto. Sur notre installation en 7.1, la requête historique renvoie zéro option et zéro octet, ce qui donne l'impression rassurante et parfaitement fausse que tout va bien.
Pour voir qui pèse, remplacez la somme par option_name, LENGTH(option_value) et triez en ordre décroissant. Sur notre site sain, les deux plus grosses entrées sont des données temporaires posées par le cœur lui-même, ce qui confirme ce que dit la communauté : quand cette table déborde, ce sont presque toujours des données temporaires jamais purgées.
Une précaution absolue pour finir. Ne supprimez pas les options dont vous ne reconnaissez pas le nom, certaines sont indispensables à une extension et leur disparition casse le site sans message. Celles dont le nom commence par _transient_ se suppriment sans risque. Pour le reste, on désactive le chargement automatique plutôt que de détruire, et on sauvegarde la table avant d'y toucher.
Une extension attend une réponse qui ne vient pas
Le symptôme : une lenteur uniforme, qui ressemble à un temps d'attente fixe, alors que rien dans le site n'a changé.
Beaucoup d'extensions interrogent un service distant pendant la génération de la page : licence, statistiques, outil de courriel, passerelle de paiement. Tant que ce service répond, personne ne s'en aperçoit. Le jour où il devient injoignable sans refuser franchement la connexion, chaque page attend le délai d'expiration, cinq secondes par défaut dans WordPress.
Nous l'avons reproduit sur le banc d'essai, avec un service qui accepte la connexion et ne répond jamais. La page d'accueil est passée de 0,044 seconde à 5,05 secondes, exactement le délai d'expiration, pendant que le fichier statique du même site continuait de sortir en 0,0006 seconde sans varier d'un millième. C'est la meilleure illustration du test des trente secondes, et l'écart désigne le coupable.
Pour confirmer, WordPress sait couper toutes ses requêtes sortantes. Ajoutez temporairement dans wp-config.php :
define( 'WP_HTTP_BLOCK_EXTERNAL', true );
Rechargez, puis remesurez avec la commande curl du début. Si la page redevient rapide, vous tenez la cause. Nous avons vérifié le comportement dans le code de WordPress : une requête bloquée revient en 0,0001 seconde avec un message explicite au lieu de faire patienter la page, et les appels vers localhost et vers votre propre domaine restent autorisés, ce qui laisse fonctionner les mécanismes internes. Pour rouvrir seulement ce dont vous avez besoin, une seconde constante accepte une liste de domaines, jokers compris :
define( 'WP_ACCESSIBLE_HOSTS', 'api.wordpress.org,*.votre-fournisseur.fr' );
Ce blocage est un outil de diagnostic, pas une réparation : laissé en place, il empêche les mises à jour, les licences et les paiements. Une fois le coupable identifié, on met l'extension à jour, on la remplace, ou on la configure pour qu'elle cesse d'interroger son service à chaque page.
Deux pistes que nous n'avons pas vérifiées
Une source espagnole attribue des pics de charge processeur inhabituels au chargement spéculatif introduit dans WordPress 6.8, qui précharge les pages au survol des liens et transforme donc des survols en requêtes serveur. Un filtre d'une ligne le désactive. Nous ne l'avons pas mesuré et ne pouvons ni confirmer ni infirmer l'ampleur de l'effet.
Seconde piste, venue des commentaires d'une vidéo technique et reprise nulle part ailleurs : une extension de cache qui, pendant son préchargement, parcourt tout le site et sature elle-même le processeur. Si votre lenteur a commencé avec l'installation ou la reconfiguration d'une extension de cache, la coïncidence mérite d'être examinée.
Ce qui ne servira à rien
Chacune de ces manipulations a été tentée, dans les fils que nous avons lus, avant que la vraie cause ne soit trouvée. Elles ne sont pas mauvaises en soi, elles sont hors sujet ici.
| La manipulation | Pourquoi elle ne donne rien |
|---|---|
| Ajouter un réseau de diffusion | Il n'intervient qu'après la réponse de votre serveur. Si l'origine met huit secondes, il transmet huit secondes. |
| Installer une extension de cache de plus | Elle n'accélère pas l'administration, et ne change rien au temps de réponse d'un site déjà en cache. |
| Compresser encore les images | Sans effet sur le temps de réponse du serveur. Un cas de forum a montré que l'extension de compression installée ne compressait rien. |
| Monter la limite mémoire à deux gigaoctets | Une valeur énorme amplifie une fuite au lieu de la corriger. |
| Désactiver Heartbeat par précaution | Des fonctions du tableau de bord en dépendent. Prouvez d'abord que c'est lui, par des appels répétés à admin-ajax.php aux heures des pics. |
| Croire l'hébergeur qui dit que vos quotas ne sont pas atteints | Il dit vrai, et cela n'exclut rien : votre compte peut respecter ses limites pendant que la machine étouffe. |
Vous avez déjà tout appliqué et le site est toujours lent
C'est le cas dont personne n'écrit, et il est très courant : cache installé, images compressées, extensions inutiles supprimées, thème allégé, et le site reste lent. Reprenez alors le test des trente secondes proprement, et si le fichier statique sort vite pendant que la page traîne, descendez dans les six causes ci-dessus au lieu d'optimiser le contenu de la page une fois de plus.
Cherchez aussi une incompatibilité entre deux extensions plutôt qu'une extension fautive. Un cas résolu mérite d'être connu : une extension de traduction et une extension de commerce fonctionnaient parfaitement chacune de son côté, et ajoutaient ensemble plus d'une seconde au temps de réponse sur une même page. Une désactivation en bloc ne révèle jamais ce genre de couple, puisque tout redevient normal dès qu'on coupe tout. Il faut réactiver par moitiés, puis par quarts, et observer.
Si rien n'a marché
Le matériel de l'hébergeur. Un fil de forum coopératif français a duré trois mois : extension de cache, cache objet, réglages, tickets successifs. La cause était une carte réseau défectueuse sur le serveur de fichiers de l'hébergeur. Quand vos deux mesures sont lentes et que vos autres sites du même hébergement le sont aussi, arrêtez de bricoler et insistez auprès du support.
La configuration des noms de domaine. Une durée de vie d'enregistrement DNS mal réglée ajoute du délai avant même que votre serveur ne soit contacté. Un outil externe le vérifie en une minute.
Ce que notre forfait ne couvre pas. Nous remettons en service un site devenu inutilisable et nous documentons la cause. Nous ne reconstruisons pas une mise en page abîmée dans un constructeur, nous ne refondons pas un thème, et nous ne promettons aucun score de mesure : un score est le résultat d'un travail d'optimisation, pas d'un dépannage.
Comment éviter que ça recommence
Repérez vos journaux maintenant, à froid. Le jour où le site rame, savoir où votre hébergeur expose le journal d'accès vaut une heure de tâtonnement.
Mesurez votre site sain une fois, et notez le chiffre. Les deux commandes curl du début, lancées un jour où tout va bien, vous donnent votre référence. Sans elle, vous ne saurez pas dire si vos huit secondes sont une dégradation ou votre état normal depuis toujours.
Ne mettez pas tout à jour d'un coup. Quarante extensions mises à jour dans la même minute, c'est quarante suspects. Et la requête sur les options, passée deux fois par an, repère une accumulation bien avant le seuil.
Questions fréquentes
Pourquoi mon site WordPress est lent ?
Deux familles de raisons, sans rapport entre elles. Soit le site est lourd et jamais entretenu, et c'est de l'optimisation : images, cache, thème, extensions. Soit il était normal et il est devenu lent, et c'est une panne : ressources partagées saturées, robots qui frappent le serveur, tâches planifiées accumulées, code PHP recompilé en permanence, options chargées à chaque page, ou une extension qui attend un service distant. Le test des deux commandes curl décrit plus haut dit dans laquelle des deux familles vous êtes.
Pourquoi mon site est long à charger alors que je n'ai rien touché ?
Le changement n'est pas toujours de votre fait. Un voisin sur la même machine physique, un robot qui a découvert votre site, un service distant qu'une extension interroge et qui est tombé, un seuil interne franchi après des mois d'accumulation : aucun de ces événements ne laisse de trace dans votre tableau de bord.
Comment savoir si la lenteur vient de mon hébergeur ?
Comparez le temps de réponse d'une page et celui d'un simple fichier statique du même site. Si les deux sont lents, le problème est le serveur ou le réseau. Si seul le dynamique est lent, l'hébergeur n'y est pour rien. Second signal, gratuit : un outil de mesure qui expire au lieu de rendre un score désigne toujours le serveur.
Mon site public est rapide mais l'administration rame, est-ce normal ?
Non. Le cache accélère les pages publiques et ne fait rien pour l'administration, qui a besoin de données fraîches à chaque écran. Un site public rapide avec une administration lente signifie donc souvent que le site est malade et que le cache le cache. Regardez OPcache, les options chargées automatiquement, les appels sortants des extensions et les tâches planifiées.
Un site lent peut-il finir par afficher une erreur 504 ?
Oui, c'est la suite logique. Quand la génération de la page dépasse le délai que le serveur s'accorde, la page n'est plus servie et le visiteur reçoit un 504 Gateway Time-out, ou un 502 Bad Gateway selon la configuration. Même mécanisme, stade plus avancé. Tant que la page finit par s'afficher, ce guide s'applique.