Un site lent et un site qui s’écroule le jour où l’infolettre part, ce ne sont pas deux degrés du même problème : ce sont deux problèmes différents, avec deux causes et deux réparations différentes. Le premier vient d’un site trop lourd ou mal servi, le second d’un plafond de ressources atteint. Le réflexe le plus courant, installer une extension de cache de plus, ne règle ni l’un ni l’autre. Voici la méthode de diagnostic que nous suivons, en couches, du serveur jusqu’au navigateur.
Lent, ou saturé ? Deux problèmes différents
La lenteur constante est reproductible : le site met quatre secondes à s’afficher à 3 h du matin comme à midi. La saturation, elle, est un effet de seuil : tout va bien jusqu’à ce que le nombre de visiteurs simultanés dépasse ce que l’offre autorise, et là tout tombe d’un coup.
Trois observations tranchent en une minute. Lancez un test de vitesse à une heure creuse, puis un second pendant un pic : si l’écart est faible, vous avez un problème de poids, pas de capacité. Regardez ensuite si les erreurs arrivent par vagues, avec des visiteurs servis normalement entre deux, ce qui est la signature d’une file d’attente saturée. Enfin, ouvrez le contrat d’hébergement et cherchez le nombre de processus simultanés autorisés : c’est ce chiffre, et non la puissance annoncée, qui décide de ce que le site encaisse.
| Ce que vous observez | Lenteur constante | Saturation |
|---|---|---|
| Horaires | Identique jour et nuit | Uniquement aux pics |
| Symptôme | Pages longues à s’afficher | Erreurs 503 ou 508 par vagues |
| Cause dominante | Poids des pages, absence de cache | Plafond de processus ou de mémoire |
| Première réparation | Cache, images, base de données | Cache en périphérie, puis capacité |
Lire les erreurs que renvoie le serveur
Les codes que voient vos visiteurs sont un diagnostic gratuit, à condition de savoir les lire (référence des codes de réponse HTTP sur MDN).
503, service indisponible
Le serveur refuse de répondre parce qu’il est occupé ou volontairement en maintenance. Neuf fois sur dix sur WordPress, c’est la file des processus PHP qui est pleine : chaque requête non servie par le cache mobilise un processus, et quand ils sont tous pris, les suivants sont rejetés. Une extension de sécurité ou un filtrage en amont peuvent produire le même code.
504, délai d’attente dépassé
Un maillon a attendu un autre maillon trop longtemps, typiquement PHP qui attend la base de données. Cherchez du côté d’une requête lente, d’un import en cours, d’une tâche planifiée lourde ou d’un appel à une interface externe sans délai maximal. Un 504 désigne presque toujours une opération précise, pas une insuffisance générale.
508, limite de ressources atteinte
Ce message est propre aux hébergements mutualisés : le compte a dépassé son quota de mémoire, de processus ou d’entrées-sorties. Ce n’est pas une panne, c’est un plafond contractuel. Détail utile à connaître : dans la norme HTTP, le code 508 signifie tout autre chose, c’est une convention d’hébergeur. Autrement dit, le serveur va bien, c’est votre part du serveur qui est pleine.
429 et blocages en amont
Trop de requêtes en trop peu de temps. Le coupable habituel n’est pas un visiteur mais un robot : outil d’exploration mal réglé, aspirateur de contenu, ou attaque de faible intensité qui ne cherche pas à faire tomber le site mais y parvient accessoirement. Les journaux d’accès du serveur donnent l’adresse IP et le motif en quelques lignes.
La chaîne de mesure, du serveur au navigateur
Quatre étages, quatre indicateurs, et surtout quatre responsables différents.
- Le temps de réponse du serveur, ou TTFB, mesure le délai avant le premier octet. Un bon repère se situe sous 0,8 seconde. C’est l’étage de l’hébergement, du cache serveur et de la base de données.
- Le LCP mesure l’affichage du plus grand élément visible ; l’objectif est 2,5 secondes ou moins. C’est l’étage des images, des polices et du chemin critique.
- L’INP mesure la réactivité aux interactions ; l’objectif est 200 millisecondes ou moins. Il a remplacé le FID en mars 2024, et beaucoup d’articles français citent encore l’ancienne métrique. C’est l’étage du JavaScript.
- Le CLS mesure la stabilité visuelle ; l’objectif est 0,1 ou moins. C’est l’étage des dimensions d’images et des bannières insérées après coup.
Ces seuils s’apprécient au 75e centile des visites réelles, mobile et ordinateur confondus (les signaux web essentiels sur web.dev). Retenez surtout la règle de tri : un mauvais temps de réponse serveur ne se corrige jamais par de l’optimisation d’images. Si le TTFB est à deux secondes, compresser les photos ne changera rien, parce que rien n’a encore commencé à s’afficher quand ces deux secondes sont écoulées.
Les sept causes qui reviennent presque toujours
- Un mutualisé sous-dimensionné, ou un voisin bruyant. Symptôme : lenteurs par plages horaires sans rapport avec votre trafic. Vérification : comparer votre courbe de visites et celle des lenteurs. Si elles ne se recoupent pas, le problème n’est pas chez vous.
- Aucun cache de page, ou un cache neutralisé. Symptôme : le TTFB est identique à la première et à la deuxième visite. Vérification : regarder les en-têtes de réponse. Une extension qui force la personnalisation sur toutes les pages désactive le cache sans le dire.
- Une base de données jamais entretenue. Révisions d’articles par centaines, données temporaires expirées jamais purgées, options chargées à chaque page. Vérification : le volume des options chargées automatiquement ; au-delà d’un mégaoctet, chaque page paie la facture.
- Des images non compressées et non redimensionnées. Symptôme : une photo de 3 Mo affichée dans un cadre de 400 pixels. Vérification : le poids total de la page dans l’onglet réseau du navigateur. C’est le poste le plus rentable, et le plus simple.
- Un constructeur de pages qui empile conteneurs et scripts. Symptôme : une page vitrine qui charge trente fichiers pour afficher trois paragraphes. Vérification : le nombre de requêtes et le poids du JavaScript.
- Les scripts tiers. Traceurs publicitaires, widgets sociaux, bulles de discussion, bandeaux divers : chacun ajoute une connexion à un domaine que vous ne maîtrisez pas. Vérification : trier les requêtes par domaine et regarder ce qui n’est pas chez vous.
- Une requête lente provoquée par une extension mal écrite. C’est la vraie coupable sur beaucoup de sites marchands : un filtre de recherche produit, un calcul de stock ou un module de fidélité qui interroge la base à chaque affichage. Vérification : un profileur de requêtes, ou la lecture du journal des requêtes lentes de la base.
Corriger dans le bon ordre
L’ordre se décide au rapport effort sur gain, jamais à l’enthousiasme technique.
D’abord ce qui est gratuit et immédiat. Activer un cache de page avec des exclusions correctes pour le panier, la commande et l’espace client. Compresser et redimensionner les images, servir des formats modernes, préciser les dimensions dans le code pour supprimer les sauts de mise en page. Purger les révisions et les données temporaires. En une demi-journée, un site lambda gagne souvent la moitié de son temps d’affichage.
Ensuite ce qui demande du tri. Passer les extensions en revue une à une et supprimer celles dont personne ne connaît la fonction. Remettre en question chaque script tiers en posant la seule question qui vaille : que se passe-t-il si je le retire ? Déplacer les tâches planifiées hors des heures de trafic. Un détail à fort rendement sur les sites très visités : par défaut, WordPress déclenche ses tâches planifiées à l’occasion des visites, ce qui fait payer à un visiteur au hasard le coût d’une sauvegarde ou d’un envoi d’infolettre. Basculer ce déclenchement sur une tâche système du serveur supprime ce hasard.
Enfin ce qui coûte. Monter en infrastructure, ou reconstruire la façade du site. Passer d’un mutualisé à un serveur dédié avant d’avoir fait les deux premières étapes revient à payer chaque mois pour masquer un défaut de code : le site sera un peu plus rapide, il restera lourd, et la facture, elle, sera définitive.
Notre position : quand changer d’hébergement devient la bonne décision
Nous préférons alléger un site que le suralimenter. Mais il existe des cas où la migration est la bonne réponse, et ils sont identifiables sans discours commercial :
- La saturation persiste alors que le site a été allégé et que le cache fonctionne.
- Vous ne pouvez pas choisir votre version de PHP, ce qui vous condamne à rester sur une version sans correctifs.
- L’hébergement ne propose ni cache serveur ni cache d’objets, donc rien pour absorber les pics.
- Il n’existe aucun environnement de préproduction, donc aucune façon de tester sans risque.
- Vos pics sont prévisibles : campagnes, saisonnalité, passages presse. Dans ce cas, mettre un cache en périphérie devant son site absorbe l’essentiel de la charge pour un coût sans commune mesure avec un serveur surdimensionné.
Le choix de l’offre compte davantage que le nom de l’hébergeur : nous détaillons les critères dans bien choisir son hébergement. Et si vos lenteurs se transforment en indisponibilités complètes, ce n’est plus un sujet de performance : suivez le protocole des soixante premières minutes. Pour un état des lieux chiffré, nous proposons un audit de performance et intervention qui commence toujours par la mesure, jamais par une recommandation d’achat.
Un site qui tombe aux heures de pointe manque presque toujours de ressources dédiées : c’est ce que corrige notre hébergement cloud à Pau.
Conclusion
La vitesse n’est pas un réglage, c’est une conséquence. Un site sobre, bien hébergé et entretenu est rapide sans effort ; un site lourd restera lent quelle que soit la puissance achetée, et coûtera simplement plus cher à héberger. C’est exactement la logique de la conception d’un site léger et rapide : moins de ressources consommées, moins d’énergie dépensée, et un site plus rapide pour tout le monde. Commencez par mesurer votre TTFB : ce seul chiffre vous dira si le problème vient du serveur ou de la page.
À lire aussi : l’impact de la vitesse sur vos conversions
Faire auditer les performances de mon site Parler hébergement et infrastructure
