Combien de visiteurs avant que le mutualisé ne cède
Ou : un serveur ne compte pas les visiteurs, il compte les pages qu’on lui demande en même temps.
La réponse courte : la capacité d’un mutualisé ne se mesure pas en visiteurs mais en pages servies par seconde, et elle se calcule. Le nombre de pages que PHP peut préparer en même temps est borné par le nombre de processus du compte ; une page générée en un quart de seconde libère son processus quatre fois par seconde. Vingt processus produisent donc au mieux 80 pages par seconde, si le processeur suit (calcul). Cette relation entre requêtes en cours, débit et durée est la loi de Little, un résultat classique de la théorie des files d’attente : le nombre moyen de requêtes en cours égale le débit multiplié par le temps passé dans le système. Avec elle, les « quelques milliers de visites » des fiches d’offres deviennent un chiffre que vous pouvez vérifier, ce qui change la façon de lire une fiche d’offre mutualisée.
Le processeur, pourtant, cède souvent avant les processus. Un compte limité à un cœur, comme l’offre Premium d’Hostinger, qui dépense 0,2 seconde de calcul par page, ne produit pas plus de cinq pages par seconde, quel que soit son nombre de processus (calcul). Sans cache, c’est presque toujours ce chiffre-là qui fixe la limite.
Pour qui : un site vitrine, un blog ou une petite boutique dont le trafic se compte en milliers de visites par jour, avec des limites PHP publiées pour faire le calcul.
À 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 de pages, puis mesurer le temps de génération des pages qui y échappent.
Hébergement mutualisé et trafic : le calcul du nombre de visiteurs par jour
| Étape | Hypothèse | Résultat (calcul) |
|---|---|---|
| Processus PHP du compte | 20, comme les processus PHP d’Infomaniak ou les processus d’entrée de l’offre Économie de GoDaddy | 80 pages par seconde si chaque page prend 0,25 s |
| Processeur du compte | 1 cœur, 0,2 s de calcul par page sans cache | 5 pages par seconde, la vraie limite |
| Heure la plus chargée | 5 pages par seconde pendant une heure | 18 000 pages |
| Comportement des visiteurs | 3 pages par visite, 15 % du trafic quotidien dans l’heure la plus chargée | 18 000 ÷ (0,15 × 3) = 40 000 visiteurs par jour, à saturation |
| Marge de sécurité | moitié de la capacité | environ 20 000 visiteurs par jour |
Chaque ligne du tableau est une hypothèse à remplacer par vos chiffres. Le temps de génération d’une page se mesure avec son TTFB, le temps jusqu’au premier octet, sur une page qui échappe au cache. Le temps de calcul par page se lit dans les graphiques de consommation du compte, rapportés au nombre de pages servies. La part de l’heure la plus chargée vient de vos statistiques de visites. Un site qui reçoit son trafic d’une lettre d’information ou d’un réseau social concentre ses visites en quelques minutes : c’est là que les processus d’entrée saturent et que tombent les erreurs 508.
Le cache change tout. Une page servie depuis le cache ne lance pas PHP : elle occupe une place sur le serveur web quelques millisecondes, comme le décrit o2switch dans sa FAQ sur les ressources. Si neuf pages sur dix sortent du cache, le processeur ne travaille plus que pour la dixième, et la capacité calculée plus haut est multipliée par dix pour la partie PHP (calcul). Le plafond se déplace alors vers d’autres limites : processus d’entrée, débit disque, bande passante.
Les hébergeurs avancent leurs propres chiffres, sans préciser leurs hypothèses. LWS affiche des « visites mensuelles » indicatives de 30 000 pour son offre Perso, 100 000 pour Starter et 300 000 pour Performance sur la page de ses offres, soit environ 1 000 visites par jour pour la première (calcul). Le comparatif des offres d’o2switch annonce environ 1 000 000 de visites par mois pour Grow. dans son tableau principal, environ 3 000 000 dans la section de comparaison de la même page, puis environ 8 000 000 pour Cloud. et 10 000 000 pour Pro. Ces repères supposent un site léger et bien mis en cache ; aucun des deux hébergeurs ne dit combien de pages compte une visite.
| Offre | Visites annoncées par mois | Par jour (calcul, 30 jours) |
|---|---|---|
| LWS, Perso | 30 000 | 1 000 |
| LWS, Starter | 100 000 | environ 3 300 |
| LWS, Performance | 300 000 | 10 000 |
| o2switch, Grow. | environ 1 000 000 ou 3 000 000 selon la section | de 33 000 à 100 000 |
| o2switch, Cloud. | environ 8 000 000 | environ 267 000 |
Relevé du 12 novembre 2026 sur les pages officielles. L’écart entre ces annonces et le calcul plus haut tient surtout au cache et au poids des pages : un site statique ou une page servie depuis le cache coûte une fraction du calcul d’une page WordPress générée à chaque visite.
Retenez l’ordre de grandeur : sans cache, un compte d’un cœur sert quelques pages par seconde ; avec un cache bien réglé, il en sert beaucoup plus, jusqu’à buter sur d’autres plafonds. Quand le calcul honnête, marge comprise, reste en dessous de votre trafic réel, l’offre est trop petite, et la question devient celle du serveur suivant.
Les plafonds qui entrent dans le calcul
Processus PHP, cœurs, mémoire, débit disque : le calcul ne vaut que si l’on connaît les plafonds de son offre, et beaucoup d’hébergeurs ne les publient pas. Ceux qui le font sont réunis dans le tableau des limites par offre.
Mesurer le temps de génération d’une page
Le temps de génération se mesure avec un TTFB, depuis l’Europe, à plusieurs heures de la journée. La méthode, et ce qu’elle révèle sur un voisin bruyant ou un code trop lourd, est décrite dans l’enquête sur un site lent.
Plus de cœurs sans quitter le panneau
Hostinger passe de 1 à 4 cœurs avec son offre Cloud Startup, o2switch de 8 à 12 vCPU threads avec Cloud. : des offres qui gardent le panneau du mutualisé avec davantage de ressources. Ce que ces offres « cloud » apportent vraiment est examiné dans cloud ou mutualisé, la différence réelle.