La plupart des conseils en matière de performance se concentrent sur ce qui se passe lorsque le trafic augmente, comme la planification de la capacité, le réchauffement du cache et la mise à l’échelle. Pour la plupart des sites WordPress, l’histoire commune va dans l’autre sens : une période de baisse du trafic lorsque l’activité revient à la normale après la fin d’une campagne, un pic saisonnier ou le lancement d’un produit.
Lorsque le trafic diminue, vous pouvez supposer que la situation de votre hébergement s’améliore car vos ressources sont moins sollicitées. En pratique, c’est le contraire qui peut se produire. Comprendre pourquoi en dit long sur le fonctionnement de la plupart des environnements d’hébergement.
Pourquoi les performances de l’hébergement ne devraient pas dépendre de vos modèles de trafic
Pour l’utilisateur final, l’hébergement mutualisé offre souvent un meilleur rapport qualité-prix, mais il comporte un risque plus élevé de problèmes de sécurité et de performances irrégulières. La tentation pour un fournisseur d’hébergement mutualisé est d’utiliser l’espace serveur pour en tirer le plus de revenus possible.
Une approche courante est la « survente » Cela se produit lorsqu’un fournisseur alloue aux clients plus de ressources qu’il n’y en a physiquement sur le serveur. Le fonctionnement est similaire à celui des banques : elles génèrent des intérêts en prêtant l’argent déposé par d’autres clients. Le système fonctionne tant que tout le monde n’essaie pas de retirer son argent en même temps.
Les environnements d’hébergement partagé placent des centaines ou des milliers de sites sur le même serveur physique, de sorte que lorsque la demande augmente, il n’y a souvent pas assez de ressources pour tout le monde.
C’est là qu’intervient l’« allocation dynamique des ressources », qui donne la priorité aux sites actifs par rapport aux sites silencieux. Un trafic plus important pour votre site signifie qu’il reçoit plus de ressources que les sites moins fréquentés. Le modèle donne effectivement la priorité aux sites très fréquentés tout en allouant moins de ressources aux sites moins fréquentés.
Toutefois, cela n’est pas dû à un plan à plusieurs niveaux. Le serveur décide simplement en temps réel où diriger les ressources disponibles. Les performances dépendent du trafic plutôt que de l’infrastructure.
Cosmick Media, client de Kinsta, a connu des symptômes similaires. L’agence a dû faire face à des temps d’arrêt intermittents et à des problèmes de vitesse de page avec ses précédents fournisseurs d’hébergement. Ces problèmes ne sont apparus qu’au moment où l’équipe a augmenté sa clientèle et où les limites des ressources de l’infrastructure partagée sont devenues plus difficiles à ignorer.
L’étranglement caché qui se produit pendant les opérations normales
L’étranglement sur l’hébergement mutualisé prend plusieurs formes et permet d’expliquer comment les ressources sont rationnées entre les sites :
- Les limites de l’unité centrale plafonnent la puissance de traitement qu’un site peut utiliser à tout moment.
- L’allocation de RAM limite la quantité de mémoire qu’un site peut utiliser.
- Les restrictions d’E/S contrôlent la vitesse à laquelle un site lit et écrit sur le disque.
Lorsque le trafic est élevé, votre site a tendance à consommer davantage de ressources disponibles. Lorsque l’activité diminue, ces ressources partagées sont rapidement utilisées par d’autres sites sur le serveur. La conséquence visible est la dégradation de l’interface utilisateur, mais la conséquence moins visible (et souvent plus dommageable) est ce qui se passe au niveau des opérations en arrière-plan.
WP-Cron déclenche des tâches d’arrière-plan telles que l’optimisation de la base de données, la vérification des mises à jour des extensions, la publication planifiée et le nettoyage des transients au sein de WordPress. Ces tâches s’exécutent en arrière-plan mais sont toujours en concurrence pour les mêmes ressources limitées. Sur un serveur surchargé, elles ne sont plus fiables – elles s’exécutent en retard, échouent silencieusement, ou ne s’exécutent pas du tout.
La dégradation des performances s’accumule au fil du temps
Le coût réel de l’étranglement est cumulatif, chaque tâche manquée s’ajoutant à la suivante :
- Les fenêtres d’optimisation de la base de données manquées s’ajoutent au gonflement qui ralentit les requêtes à chaque nouvelle requête.
- Les tâches d’arrière-plan qui échouent laissent des trous dans le cycle de maintenance qui ne se réinitialisent pas automatiquement lorsque le trafic se rétablit.
- La lenteur des opérations d’administration retarde la maintenance de routine (mises à jour d’extensions, changements de contenu et tâches de configuration) qui maintient la stabilité et la sécurité d’un site WordPress.
Les révisions d’articles, les transients et les options chargées automatiquement sont tous stockés dans la base de données de WordPress. Sans optimisation régulière, les tables grossissent et les requêtes ralentissent. Sur un serveur disposant de ressources constantes, le nettoyage se déroule comme prévu. Cependant, sur un serveur mutualisé, il ne s’exécute que lorsque des ressources suffisantes sont disponibles. Pendant les périodes de faible trafic, ces tâches de nettoyage peuvent être exécutées beaucoup moins souvent.
Il en résulte une boucle de rétroaction où la dégradation des performances rend la maintenance plus difficile, ce qui produit un site moins sain. Cette dégradation des performances peut accélérer le déclin du trafic organique en raison du ralentissement du chargement des pages et de l’affaiblissement des scores Core Web Vitals.
Comment l’architecture de conteneurs de Kinsta élimine la performance dépendante du trafic
Chaque site WordPress sur Kinsta fonctionne à l’intérieur d’un conteneur Linux isolé et ne partage pas son allocation avec d’autres sites sur la plateforme. Il n’y a pas non plus de files d’attente prioritaires pour déterminer quels sites reçoivent plus de ressources.
Un site qui descend d’un pic de campagne continue à fonctionner avec les mêmes ressources allouées que celles dont il disposait pendant ce pic. L’infrastructure ne réaffecte pas les ressources lorsque le nombre de visiteurs diminue.
En effet, si les niveaux supérieurs de Kinsta accueillent plus de visites mensuelles, ils fonctionnent tous avec le même modèle de conteneur isolé et les mêmes garanties de ressources. Les plans déterminent plutôt les limites de capacité, telles que la bande passante mensuelle/les visites et les ressources disponibles. Cela influence également la façon dont Kinsta utilise les threads PHP pour améliorer les performances globales de votre site.
Pour WP-Cron en particulier, cela signifie que les tâches planifiées ont des ressources constantes disponibles pour s’exécuter de manière fiable. La dette technique qui s’accumule sur les environnements bridés (tels que les nettoyages manqués, les tâches d’arrière-plan ratées, les tables gonflées, et plus encore) ne s’accumule pas ici parce que les ressources nécessaires pour l’éviter restent disponibles en permanence.
La mise en cache multicouche fonctionne de manière identique lorsque le trafic est élevé ou faible
La pile de mise en cache de Kinsta fonctionne sur quatre couches, chacune indépendante de votre volume de trafic. Ensemble, elles réduisent le travail que votre conteneur doit effectuer et libèrent des ressources pour les opérations d’administration et les tâches d’arrière-plan :
- Le cache périphérique (Edge) sert votre site directement à partir du réseau mondial de Cloudflare avant qu’une requête n’atteigne votre serveur d’origine. Les taux de réussite de la mise en cache restent élevés aussi bien pendant les pics de trafic que pendant les périodes plus calmes. Les pages mises en cache n’expirent pas simplement parce que le trafic a chuté, de sorte qu’un site post-campagne continue à être servi depuis la périphérie comme il l’était lors de son pic de fréquentation.
- Le cache au niveau du serveur gère les requêtes dynamiques qui contournent la périphérie, réduisant ainsi la charge de la base de données à l’origine. Pour les sites où les utilisateurs connectés ou le contenu dynamique empêchent la mise en cache d’une page entière à la périphérie, cette couche permet de maintenir des temps de réponse prévisibles.
- Le CDN de Kinsta sert les ressources statiques (images, CSS, JavaScript et polices) à partir d’emplacements distribués en périphérie. Ils sont livrés à la même vitesse quel que soit le volume de requêtes, ce qui les empêche de se retrouver dans votre conteneur.
Ne négligez pas non plus la mise en cache d’objets Redis à faible latence de Kinsta. Cela permet de stocker les résultats des requêtes de la base de données en mémoire afin que WordPress ne répète pas les mêmes requêtes à chaque chargement de page. Pour les sites à fort contenu, les boutiques WooCommerce et les plateformes d’adhésion où les mêmes requêtes sont exécutées de manière répétée, cela signifie des réponses plus rapides et une charge de base de données plus légère.
Pourquoi l’hébergement premium a du sens pour un trafic stable
L’hypothèse selon laquelle la baisse du trafic justifie le déclassement de l’hébergement traite l’infrastructure comme un outil de mise à l’échelle que vous développez pour les pics et que vous contractez pendant les périodes calmes. Cependant, cela ne tient pas compte de ce que l’hébergement d’un site WordPress fait pendant les périodes entre les campagnes.
Alors que de nombreux plans d’hébergement basent leur tarification sur le volume de trafic, le volume de trafic et la qualité de l’infrastructure sont deux choses différentes. Un site recevant moins de visites pendant une période post-campagne a toujours besoin d’une infrastructure fiable pour assurer la maintenance, la réactivité des outils d’administration et le bon déroulement des tâches d’arrière-plan.
La complexité des applications WordPress ne diminue pas avec le trafic
Les tâches telles que le fonctionnement des extensions, la maintenance de la base de données, les analyses de sécurité et la publication programmée ne s’arrêtent pas pendant une période calme. Pensez aux besoins d’une agence qui gère le site d’un client entre deux campagnes :
- Des environnements de staging qui reflètent la production suffisamment fidèlement pour détecter les problèmes avant le déploiement.
- Un accès SSH et WP-CLI pour les opérations de base de données, la gestion des extensions et les scripts personnalisés.
- Des temps de réponse de l’administration qui tiennent la route pendant l’édition de contenu et le travail de gestion du site.
- Des sauvegardes planifiées et des analyses de sécurité qui se terminent à temps.
Si vous exécutez des flux de travail de développement, le transfert de modifications de la version de démonstration à la version en ligne, l’exécution de mises à jour de plugins et l’exécution de migrations de bases de données nécessitent des performances d’hébergement fiables. Travailler sur le site d’un client au cours d’un mois calme nécessite toujours la même performance des processus de déploiement et des environnements de staging.
Pour une agence gérant plusieurs sites clients à différents stades du cycle de trafic, une infrastructure partagée peut rendre les sites les plus calmes plus difficiles à gérer, car le serveur achemine les ressources vers les sites les plus actifs. Sur une infrastructure de conteneurs isolée, chaque site se comporte de la même manière, quelle que soit l’activité des autres.
Des performances constantes permettent une planification à long terme en toute confiance
En bref, une infrastructure prévisible change votre façon de travailler. Lorsque vous savez que les tâches de maintenance se terminent de manière fiable, que WP-Cron se déclenche à la date prévue et que les opérations d’administration répondent de manière cohérente, la planification devient plus facile. Il y a plusieurs avantages pratiques :
- Réduction des frais généraux de support, car les problèmes de performance liés à la contention des ressources ne génèrent pas les tickets de support qui doivent être examinés.
- Des cycles de planification plus fiables, car vous ne tenez pas compte du risque d’un environnement d’hébergement qui se comporte différemment pendant les mois calmes.
- Moins de conjectures sur l’infrastructure lorsque vous choisissez l’hébergement en fonction des modèles de trafic. La mise à niveau pour les campagnes et la rétrogradation par la suite introduisent des risques et des frais de gestion à chaque transition.
Ce dernier point mérite que l’on s’y attarde. Un hébergement qui nécessite une gestion active basée sur les tendances du trafic va à l’encontre de votre planification plutôt que de l’accompagner. Un site doit pouvoir entrer dans une période de calme sans rien changer à son mode d’hébergement et en ressortir dans le même état qu’à l’origine.
L’infrastructure d’hébergement doit soutenir la croissance de l’entreprise, et non les courbes de trafic
Le schéma qui endommage les sites WordPress lors des baisses de trafic n’est pas compliqué. Une infrastructure surdimensionnée prive de priorité les sites plus calmes, les tâches de fond prennent du retard et la dette technique cumulative s’accumule au fil du temps.
Un modèle d’hébergement qui considère les périodes de faible trafic comme une raison de réduire les ressources disponibles va finalement à l’encontre des sites qu’il est censé soutenir.
Si vous évaluez votre configuration d’hébergement actuelle, posez des questions. Par exemple, les tâches d’arrière-plan peuvent-elles s’exécuter de manière fiable pendant les périodes calmes ? Votre outil d’administration reste-t-il réactif lorsque votre trafic est en baisse ? De manière plus générale, demandez si le modèle de ressources de votre hébergeur traite une accalmie post-campagne de la même manière qu’un pic de trafic, ou si le niveau de votre plan détermine discrètement la part du serveur que vous pouvez utiliser.
L’hébergement WordPress infogéré de Kinsta est construit autour de conteneurs isolés, d’une pile de cache multicouche et de ressources dédiées qui ne fluctuent pas en fonction des niveaux de trafic. Cela signifie que votre site fonctionne de la même manière à la fin d’une campagne qu’à son apogée.
Vous souhaitez poser des questions ? Contactez notre équipe à tout moment.
Joel est un développeur d'interfaces publiques qui travaille chez Kinsta en tant que rédacteur technique. Il est un enseignant passionné par l'open source et a écrit plus de 200 articles techniques, principalement autour de JavaScript et de ses frameworks.
