Votre site rame : le voisin, le code ou l'offre
Ou : le voisin bruyant est un suspect commode, et il a souvent un alibi.
La réponse courte : un site lent sur un hébergement mutualisé a trois suspects, et trois tests suffisent à les départager. Si un simple fichier statique répond aussi lentement qu’une page PHP, le serveur ou le réseau sont en cause. Si seule la page PHP traîne, c’est le code, les extensions ou la base de données. Si la lenteur suit l’heure de la journée alors que les graphiques de votre compte restent calmes, c’est le voisinage, donc l’offre. Le repère de départ est le temps jusqu’au premier octet, le TTFB : web.dev conseille de viser 0,8 seconde ou moins pour la plupart des sites. Cette enquête fait partie de ce qu’il faut savoir faire avec l’hébergement partagé expliqué, avant d’accuser qui que ce soit.
Les hébergeurs défendent d’ailleurs leurs voisins. o2switch rappelle que les graphiques de consommation ne montrent que votre propre compte, qui peut tourner à 100 % de sa part pendant que le serveur reste sous 30 % d’utilisation. Infomaniak indique que ses serveurs mutualisés n’utilisent en moyenne que 40 % de la puissance de leurs processeurs. Ce sont leurs chiffres ; vos mesures diront le reste.
Pour qui : un site vitrine ou un blog sur un mutualisé dont l’hébergeur publie ses limites PHP et donne accès aux journaux de requêtes lentes.
À partir de : 5,75 € HT par mois pour l’hébergement web Infomaniak, facturé à l’année par défaut, sans prix promotionnel affiché (relevé du 12 novembre 2026).
Pour démarrer : commander l’hébergement web Infomaniak, activer un cache et lire les journaux d’erreurs et de requêtes lentes ; si le site dépasse durablement le mutualisé, passer à un serveur cloud managé Infomaniak.
Site lent sur un hébergement mutualisé : la méthode pour trouver la cause
Mesurer à plusieurs heures. La première étape compare deux adresses du même site, un fichier statique et une page générée par PHP, le matin, l’après-midi et le soir, avec une dizaine de requêtes à chaque fois :
| |
La mesure se fait depuis un point proche du serveur, en Europe pour un hébergement européen : depuis l’autre côté de l’Atlantique, la latence du trajet fausse la comparaison. On garde la médiane, pas la meilleure valeur.
Lire les graphiques du compte. Sur cPanel, l’outil « Utilisation des ressources » montre la consommation de processeur, de mémoire et de disque, les processus d’entrée et le nombre de processus, sur 24 heures ou sur sept jours. La FAQ d’o2switch sur le suivi des ressources juge normal d’atteindre le plafond une fois ou quelques fois, lors d’une sauvegarde ou d’un gros import ; des pics répétés signalent un processus qui s’emballe.
Lister les processus. En SSH, top ou ps -ef pendant une à deux minutes montre ce qui tourne vraiment. o2switch signale un cas qui surprend : chaque dossier d’une boîte mail synchronisé en IMAP ouvre un processus, soit trente processus pour dix comptes de trois dossiers connectés en même temps.
Lire les journaux. Le journal d’erreurs PHP, puis celui des requêtes lentes. La FAQ d’Infomaniak sur la surcharge d’un site invite à repérer les requêtes SQL de plus de cinq secondes, à limiter les robots trop insistants avec une directive Crawl-delay, et à éviter les ressources chargées depuis des serveurs extérieurs.
Chercher l’intrus. Une consommation forte sans visiteur, ou des fichiers aux noms étranges, évoquent un site piraté : o2switch conseille une analyse antivirus depuis le compte.
| Ce que vous observez | Suspect principal | Ce qu’il faut vérifier |
|---|---|---|
| Fichier statique et page PHP lents, à toute heure | serveur ou réseau | état des services de l’hébergeur |
| Page PHP lente, fichier statique rapide | code, extensions, base de données | journaux d’erreurs et de requêtes lentes |
| Lenteur aux heures de pointe, graphiques du compte calmes | voisinage, serveur chargé | mesures horodatées à transmettre au support |
| Graphiques du compte au plafond processeur ou disque | votre propre consommation | processus, cache, tâches planifiées |
| Erreurs 508 lors des pics de visites | processus d’entrée saturés | durée des requêtes, robots |
| Pics réguliers à heure fixe | tâche planifiée | planificateur du panneau et celui du CMS |
| Consommation sans visite, processus inconnus | piratage | analyse antivirus, fichiers récents suspects |
Si le support doit enquêter, il lui faut des faits. Infomaniak demande par écrit le nom du site, les dates et heures précises des lenteurs, la base ou le compte FTP concerné, votre adresse IP publique et le type de lenteur constatée. Un tableau de mesures horodatées vaut mieux que « le site est lent depuis lundi ».
Reste le cas où ni le voisin ni le code ne sont coupables : un site optimisé, mis en cache, qui touche ses plafonds au trafic normal. L’offre est alors trop juste. Hostinger fixe un seuil pratique dans son article sur les limites atteintes : si la limite de mémoire ou de processus est atteinte dix à vingt fois par mois, il recommande une offre supérieure. Infomaniak oriente vers un Serveur Cloud aux ressources dédiées quand le mutualisé ne suffit plus. Le cas propre à WordPress, extension par extension, se traite à part : ici, il s’agit de l’hébergement.
Les plafonds derrière les erreurs
Une erreur 508 aux heures de pointe ou des 503 au milieu d’un import pointent vers des plafonds précis, processus d’entrée ou mémoire. Ce que chaque hébergeur publie, et ce qu’il tait, est réuni dans les limites de processeur et de processus.
La capacité réelle de l’offre
Savoir combien de pages par seconde votre offre peut servir aide à dire si la lenteur vient d’un trafic trop fort ou d’un code trop lent. Le calcul, à partir des processus PHP et du temps de génération, est expliqué dans le nombre de visiteurs qu’un mutualisé supporte.
La tâche qui revient toutes les heures
Une lenteur qui revient à heure fixe trahit souvent une tâche planifiée trop lourde ou qui se chevauche avec elle-même. Les règles de chaque hébergeur et la parade du verrou flock sont détaillées dans les tâches cron sur un mutualisé.