Quand un site est lent, l’une des premières questions est de savoir si l’hébergement est en cause. Parfois oui, parfois non, et souvent la réponse est « en partie ». L’hébergement détermine la rapidité de réponse du serveur, sa capacité à supporter de nombreux visiteurs simultanés et la disponibilité d’outils comme le cache de page et le cache d’objets. Il ne détermine pas le poids des images, la quantité de JavaScript ou la structure des pages, qui dépendent du site lui-même.
Comprendre ce que l’hébergement peut et ne peut pas faire compte autant pour ceux qui doivent choisir un service que pour ceux qui se demandent s’il faut en changer. Dans cet article, nous voyons quels aspects de l’hébergement influent sur les Core Web Vitals, en quoi les principaux modèles diffèrent, du mutualisé au cloud, et comment comparer différentes offres sans se laisser tromper par des tests peu représentatifs.
Ce qui dépend de l’hébergement
Le principal lien entre l’hébergement et les Core Web Vitals passe par le TTFB, le temps que met le serveur à commencer à répondre. Le TTFB est le socle de toutes les autres métriques de chargement : le LCP ne peut pas arriver avant le HTML, et un TTFB d’une seconde ne laisse qu’une seconde et demie pour tout le reste si l’on veut rester dans le seuil de 2,5 secondes. Le seuil considéré comme bon pour le TTFB, au 75e percentile, est de 800 millisecondes.
Le TTFB dépend de plusieurs aspects de l’hébergement. La vitesse du processeur, surtout la vitesse monocœur, car la génération d’une page WordPress est un travail en grande partie séquentiel. La version de PHP et la configuration de son cache de code compilé, OPcache. La rapidité de la base de données et des disques, aujourd’hui presque toujours à semi-conducteurs, mais avec des performances très différentes. La disponibilité des caches : un cache de page au niveau du serveur et un cache d’objets comme Redis. Et la localisation du centre de données par rapport aux utilisateurs, avec la qualité du réseau qui le relie, qui détermine le coût de chaque aller-retour, comme nous l’avons vu dans l’article sur le DNS, le TLS et les connexions.
Il y a ensuite un aspect que les tests isolés ne montrent pas : la capacité sous charge. Un serveur qui répond en 300 millisecondes à une requête à la fois peut mettre trois secondes quand il reçoit cinquante requêtes simultanées. Le nombre de processus PHP disponibles, souvent appelés workers PHP, et la mémoire et la puissance de calcul réservées au site décident du moment où le service commence à ralentir.
Ce qui ne dépend pas de l’hébergement
Il est tout aussi important de savoir ce que l’hébergement ne corrige pas. Une image de trois mégaoctets reste une image de trois mégaoctets sur n’importe quel serveur ; deux mégaoctets de JavaScript demandent le même temps d’exécution sur le smartphone de l’utilisateur ; une bannière qui décale le contenu génère du CLS où que le site soit hébergé. De nombreux sites changent d’hébergeur en espérant résoudre des problèmes situés dans le front-end, et obtiennent un meilleur TTFB avec un LCP presque inchangé. Avant de changer, il vaut la peine de comprendre quelle part du temps de chargement dépend du serveur et quelle part du navigateur, par exemple avec la décomposition du LCP dans PageSpeed Insights : si le TTFB n’en représente qu’une petite fraction, le problème est ailleurs.
Les modèles d’hébergement
Les offres du marché peuvent se regrouper en quatre grands modèles, aux frontières de plus en plus floues. Au sein de chacun, les écarts de qualité entre un fournisseur et un autre sont énormes ; les caractéristiques qui suivent sont donc des tendances, pas des règles.
Hébergement mutualisé
Dans l’hébergement mutualisé, de nombreux sites vivent sur le même serveur et en partagent les ressources. C’est la solution la moins chère et la plus simple : le fournisseur gère tout et le client ne s’occupe que du site. La limite principale est l’imprévisibilité : les ressources disponibles pour chaque site sont limitées et dépendent aussi de l’activité des autres sites, les fameux voisins bruyants. Les performances peuvent être bonnes en conditions normales et s’effondrer aux moments de charge. Les offres à « ressources illimitées » doivent être lues avec attention : des limites existent toujours, souvent exprimées en processus simultanés, en utilisation du CPU ou en opérations sur disque.
Un bon hébergement mutualisé, avec des serveurs modernes, un cache de page au niveau du serveur et peu de sites par machine, peut convenir à des sites vitrines et à des blogs au trafic modeste. Il devient juste pour les boutiques en ligne, les sites avec de nombreux utilisateurs connectés ou avec des pics de trafic prévisibles.
Serveur privé virtuel
Un VPS offre des ressources réservées, processeur, mémoire et disque, sur une machine virtuelle dédiée. Les performances sont prévisibles et le contrôle est complet : vous choisissez le système d’exploitation, le serveur web, la version de PHP, la configuration des caches. L’envers de la médaille est la gestion : dans la version non managée, l’installation, la configuration, les mises à jour de sécurité, les sauvegardes et le monitoring sont à la charge du client. Un VPS puissant mais mal configuré, sans cache et avec les paramètres par défaut, peut être plus lent qu’un bon hébergement mutualisé.
Hébergement WordPress managé
Les hébergeurs managés spécialisés dans WordPress proposent un environnement déjà optimisé : cache de page au niveau du serveur, souvent un cache d’objets, des versions récentes de PHP, des mises à jour et des sauvegardes automatiques, et un support qui connaît la plateforme. Pour de nombreux sites professionnels, c’est le meilleur compromis entre performance et simplicité. Les limites se trouvent dans le détail des offres : nombre de workers PHP par formule, qui détermine combien de requêtes dynamiques le site peut traiter à la fois ; limites de trafic ou de visites ; plugins interdits ; suppléments pour des ressources additionnelles.
Cloud évolutif
Les infrastructures cloud permettent d’augmenter les ressources à mesure que la charge croît, même automatiquement, et de répartir le site sur plusieurs serveurs et régions. C’est la solution pour les sites à gros volumes de trafic ou à pics très marqués, mais elles exigent des compétences spécifiques pour être conçues et gérées, et les coûts peuvent croître de façon moins prévisible. Il existe aussi des services managés construits sur des infrastructures cloud, qui en offrent l’évolutivité avec une gestion simplifiée.
La différence se voit sous charge
La façon la plus courante de comparer deux hébergeurs, un test PageSpeed Insights sur la page d’accueil, est aussi la moins significative. La page d’accueil est presque toujours en cache, et un test isolé mesure un serveur qui répond à une seule requête. Dans ces conditions, presque tous les hébergeurs paraissent rapides. Les différences apparaissent sur les pages qui ne peuvent pas être mises en cache, comme le panier, le tunnel de commande, l’espace membres et la recherche, et quand de nombreux utilisateurs les demandent en même temps.
Un test de charge, qui simule de nombreux utilisateurs simultanés, est le moyen le plus fiable d’évaluer un hébergeur, et nous le verrons en détail dans l’article sur les pics de trafic. Même sans outils spécifiques, quelques vérifications sont toutefois à la portée de tous : mesurer le TTFB de l’administration et des pages dynamiques, à différents moments de la journée et depuis un lieu proche des utilisateurs ; consulter les données de Search Console et du Chrome UX Report pendant les semaines de plus fort trafic ; demander au fournisseur combien de processus PHP sont disponibles et ce qui se passe quand ils sont épuisés.
N’oubliez pas que les comparatifs publiés, même ceux des fournisseurs, mesurent souvent des configurations différentes, comme nous l’avons vu dans l’article quand le benchmark voit un autre site : la comparaison utile est celle qui est faite sur votre propre site, avec vos propres pages et vos propres plugins.
Questions à poser à un fournisseur
- Où sont les serveurs ? Pour un public francophone, en France ou en Europe proche ; pour un public international, avec un CDN ou plusieurs régions.
- Quelles ressources sont garanties ? Processeur, mémoire, nombre de processus PHP, limites d’utilisation, et ce qui se passe quand elles sont dépassées.
- Quel cache est disponible ? Cache de page au niveau du serveur, cache d’objets, intégration avec WordPress pour la purge automatique.
- Quelle pile logicielle ? Versions de PHP et de la base de données, serveur web, prise en charge de HTTP/2 et HTTP/3, compression Brotli.
- Comment les pics sont-ils gérés ? Si les ressources peuvent être augmentées temporairement, délais et coûts.
- Qui s’occupe de quoi ? Mises à jour, sécurité, sauvegardes, monitoring, support en cas de problèmes de performance.
L’hébergement et le CDN
Un CDN ne remplace pas un bon hébergement, mais il peut compenser certaines de ses limites. En servant les ressources statiques et, s’il est configuré pour cela, les pages en cache depuis des nœuds proches des utilisateurs, il réduit la charge sur le serveur d’origine et les temps de réseau pour les visiteurs éloignés. Il n’aide cependant pas pour les pages dynamiques, qui doivent toujours être générées par le serveur. Ici aussi s’applique la distinction entre CDN et cache de page vue dans l’article sur Cloudflare : activer un CDN sur un hébergement lent améliore la diffusion des images, mais n’accélère pas le panier d’une boutique.
La pile doit être entretenue
Les performances d’un hébergement ne sont pas figées dans le temps. Chaque nouvelle version de PHP a apporté des gains de vitesse, et un site resté sur une version vieille de plusieurs années renonce à des gains gratuits, en plus de s’exposer à des problèmes de sécurité. Il en va de même pour la base de données, le serveur web et les bibliothèques système. De nombreux hébergeurs permettent de changer la version de PHP depuis le panneau de contrôle : avant de le faire, il vaut la peine de vérifier la compatibilité du thème et des plugins dans un environnement de test, mais repousser la mise à jour pendant des années coûte autant en performance qu’en sécurité.
Un exemple concret aide à comprendre l’ordre de grandeur. Une boutique en ligne sur un hébergement mutualisé bon marché a un TTFB d’environ 400 millisecondes sur les pages en cache et de 1,8 seconde sur le panier et le tunnel de commande, qui passe au-dessus de trois secondes aux heures du soir. Le passage à un hébergement managé avec cache de page au niveau du serveur, cache d’objets et un nombre adapté de processus PHP ramène les pages en cache sous 100 millisecondes et les pages dynamiques autour de 500, sans variation significative aux heures de pointe. Le reste du site ne change pas : images, scripts et structure sont les mêmes, et les améliorations ultérieures du LCP dépendront du travail sur le front-end.
Quand changer
Changer d’hébergement a du sens quand les données indiquent que le serveur est le goulot d’étranglement : TTFB élevé même sur les pages en cache, ou sur les pages dynamiques malgré un cache d’objets et un site bien optimisé ; ralentissements récurrents aux heures de pointe ; erreurs ou temps de réponse très élevés pendant les campagnes ; impossibilité d’obtenir des versions récentes des logiciels ou les outils de cache nécessaires. Cela n’a aucun sens quand le problème principal est le poids du front-end : dans ce cas, un meilleur hébergement n’améliore que légèrement un problème qui se trouve ailleurs.
Lorsque vous décidez de changer, la migration elle-même doit être planifiée pour ne pas perdre en performance, avec des mesures avant et après, la vérification des configurations de cache et le suivi des données de terrain dans les semaines suivantes : nous en parlons dans l’article sur les migrations.
En résumé
L’hébergement influe sur les Core Web Vitals principalement par le TTFB : vitesse du processeur, version de PHP, base de données, disponibilité des caches, localisation du serveur et capacité à supporter de nombreux utilisateurs simultanés. Il n’influe pas sur le poids et la complexité du front-end, qui restent de la responsabilité du site.
Mutualisé, VPS, WordPress managé et cloud répondent à des besoins différents, et au sein de chaque modèle la qualité varie beaucoup. Les comparer demande des mesures sur des pages dynamiques et sous charge, pas un test de la page d’accueil. Et avant de changer, il vaut la peine de vérifier que le serveur est bien le goulot d’étranglement : le meilleur hébergement du monde ne rendra pas légère une page lourde, mais un hébergement inadapté peut rendre lente même la page la plus légère.
