Hébergement et performances
Comment nous rendons WordPress rapide : LiteSpeed Enterprise, LSCache et Redis par site
La requête WordPress la plus rapide est celle qui ne s’exécute jamais — découvrez comment notre infrastructure répond à la plupart des visites depuis le cache avant même que PHP ou MySQL ne soient sollicités, et ce que cela implique pour les Core Web Vitals.
La requête la plus rapide est celle qui ne s’exécute jamais
Une requête standard WordPress est coûteuse en ressources. Le serveur web passe la main à PHP, PHP démarre WordPress, exécute les extensions, interroge MySQL quelques dizaines de fois, assemble le code HTML et c’est seulement ensuite qu’il renvoie des octets. Sur un site à fort trafic, tout cet enchaînement se produit pour chaque visiteur, et c’est là que passe la quasi-totalité de votre temps jusqu’au premier octet.
Notre réponse consiste à nous assurer que, pour la plupart des visites, rien de tout cela ne se produise. Sur l’ensemble des sites que nous hébergeons — plus de 100 000 sites PBN ainsi que des WordPress gérés traditionnels —, la grande majorité des pages vues sur l’interface publique sont servies sous la forme d’une page complète pré-rendue directement depuis le cache, sans solliciter PHP ni toucher à la base de données. La suite de cet article explique comment s’articulent les couches qui rendent cela possible, et la place que chacune d’elles occupe.
L’élément fondamental à comprendre est qu’il ne s’agit pas de caches concurrents entre lesquels vous devez choisir. Le cache de page entière, le cache d’objets et la périphérie du CDN traitent chacun une catégorie différente de requêtes, et toute la valeur réside dans la manière dont ils se relaient.
LiteSpeed Enterprise + LSCache : la couche pleine page
Chaque site fonctionne sur LiteSpeed Enterprise avec LSCache au niveau du serveur. Lorsqu’une réponse front-end peut être mise en cache, le serveur web lui attribue des en-têtes LiteSpeed cache-control et d’étiquettes, et LiteSpeed sert la page complète directement lors de la requête suivante — aucun processus PHP n’est généré, aucune requête MySQL n’est émise. Il s’agit du principal levier d’optimisation du TTFB sur WordPress, car il supprime l’intégralité de l’amorçage de l’application du chemin critique.
Puisque LSCache réside directement au sein du serveur web et non dans un plugin PHP, il intervient plus tôt dans le cycle de vie de la requête et conserve les pages sous une forme que le serveur peut vider instantanément. Un robot d’exploration du cache maintient les pages populaires prêtes, de sorte que le premier visiteur suivant une purge ne subit pas le temps de régénération de la page. Il en résulte un TTFB nettement plus bas et plus régulier qu’avec un cache reposant uniquement sur un plugin greffé sur un environnement générique, où le cache se situe toujours derrière PHP.
Notre propre extension de cache de niveau dépôt est livrée préinstallée et mise à jour automatiquement sur chaque site, reliant correctement WordPress à LSCache dès le départ. Sur une source qui n’est pas LiteSpeed, elle n’émet simplement aucun en-tête de page complète et s’efface, tandis que le cache d’objets et les règles d’exclusion continuent de fonctionner — ainsi, un site migré n’est jamais laissé dans un état défaillant ou à moitié configuré.
Rester rapide sans diffuser de contenu obsolète : ESI et purge automatique intelligente
La mise en cache agressive de pages entières présente deux modes de défaillance classiques : servir à un utilisateur connecté la page de quelqu’un d’autre, et servir à quiconque une page qui aurait dû être modifiée. Ces deux problèmes se résolvent au niveau de la couche de mise en cache plutôt qu’en réduisant la mise en cache.
ESI (Edge Side Includes) nous permet de mettre la page en cache tout en ménageant des zones dynamiques pour les éléments qui doivent rester actualisés. Sur une boutique WooCommerce, les pages de catalogue, de produits et de catégories sont servies sous forme de cache de page intégrale afin d’offrir le TTFB le plus rapide possible, tandis qu’ESI génère le fragment du panier, les totaux du mini-panier et l’état du compte pour chaque requête. Le panier, la commande, « mon compte » ainsi que toutes les pages de nonce ou de session sont exclus par défaut. Les acheteurs voient systématiquement leur propre panier et un processus de commande opérationnel ; tout le monde continue de bénéficier de la vitrine issue du cache.
La fraîcheur du contenu est assurée par une purge automatique intelligente. Les déclencheurs de purge s’activent automatiquement lorsque le contenu, les produits, les prix ou les commandes changent, de sorte que les pages en cache concernées s’actualisent immédiatement plutôt que selon une minuterie, et vous pouvez également purger à la demande depuis le tableau de bord ou depuis WordPress. La purge basée sur les étiquettes signifie que la modification d’un article efface uniquement cet article et ses archives — et non l’intégralité du cache —, de sorte qu’une seule modification ne provoque pas de démarrage à froid de l’ensemble du site.
Cache d’objets Redis par site : pour ce qui ne peut pas être une page complète
Toutes les requêtes ne peuvent pas être une page entière statique. Les sessions connectées, l’administration de WordPress, les paniers WooCommerce, la recherche et les fragments dynamiques qu’ESI laisse actifs doivent tous exécuter PHP. Pour ceux-ci, l’objectif passe de « sauter l’application » à « sauter la base de données ».
Chaque site bénéficie de son propre cache d’objets Redis dédié. WordPress met en mémoire cache les résultats des lectures répétées de la base de données — options, données temporaires (transients), recherches d’articles et de termes, données de produits et de sessions WooCommerce — afin que la même requête ne soit pas exécutée sur MySQL à chaque visite. L’effet est particulièrement visible là où le cache de page entière ne peut intervenir : des tableaux de bord plus rapides, des paniers plus fluides et une charge de base de données nettement réduite lors des pics de trafic.
Le cache d’objets est propre à chaque site et non partagé, ce qui est essentiel tant pour les performances que pour l’isolation. Associé à la régulation de la base de données par site, les requêtes lourdes ou mal conçues d’un site ne peuvent pas priver ses voisins de ressources de base de données. Vous pouvez en savoir plus sur l’agencement de cette configuration multicouche sur notre page dédiée aux fonctionnalités de mise en cache, ainsi que sur les limites entre locataires dans la section consacrée à l’isolation.
L’edge et le transport sous-jacent
Le cache qui réside sur le serveur d’origine doit toujours traverser le réseau. En amont du serveur se trouve la bordure du CDN, de sorte que les ressources statiques et les pages pouvant être mises en cache sont servies depuis un point de présence proche du visiteur, et le serveur d’origine reste peu sollicité même sous forte charge. Pour notre gamme d’hébergement sans empreinte (footprint-free), cette même bordure est un ensemble multi-CDN réparti entre plusieurs fournisseurs, ce qui répond à un objectif lié à l’empreinte SEO tout autant qu’à la performance ; sur le WordPress standard, il s’agit simplement d’une couche rapide et bien optimisée qui maintient les serveurs d’origine au repos.
En arrière-plan, rien n’a été négligé sur les fondamentaux. Les sites fonctionnent sur un stockage NVMe avec HTTP/3, de sorte que les octets envoyés par le cache arrivent via un transport moderne et multiplexé, avec un stockage rapide derrière chaque échec de cache (cache miss). Aucune de ces couches n’est un module complémentaire : LiteSpeed, LSCache, Redis par site, NVMe et HTTP/3 constituent la base de chaque offre, et non un niveau de vente incitative.
Ce qui a un réel impact sur Core Web Vitals
Il convient d’être précis, car l’hébergement est souvent surfait en ce qui concerne les Core Web Vitals. Le TTFB est la partie de l’équation qui dépend du serveur, et la pile de mise en cache ci-dessus est ce qui permet de le réduire — une page complète mise en cache et diffusée via HTTP/3 depuis l’edge correspond à peu près au niveau le plus bas possible pour le TTFB. Dans la mesure où le TTFB constitue le front de tête du Largest Contentful Paint, une origine rapide confère à chaque métrique en aval une avance qu’elle ne pourrait pas obtenir autrement.
Cependant, le LCP, le CLS et l’INP se décident principalement dans le navigateur, au niveau de la page elle-même : une image principale non optimisée, des ressources CSS et JavaScript qui bloquent le rendu, une mise en page qui se décale au chargement des polices et des publicités, ainsi qu’une lourde charge sur le thread principal causée par les extensions. Aucune mise en cache sur le serveur ne peut compenser une image principale de 2 Mo ou un thème qui charge des mégaoctets de JavaScript. Un hébergement de qualité rend l’impact du serveur pratiquement transparent et constant ; il incombe ensuite au site de veiller à la légèreté du front-end.
Cette division du travail constitue le modèle mental idéal. Nous garantissons que la requête parvienne rapidement au navigateur et reste rapide sous une forte charge de trafic ; vous veillez à ce que la charge utile demeure réduite et stable. C’est précisément là où les deux se rencontrent — le préchauffage du cache, la distribution à la périphérie (edge delivery) et le maintien de la réactivité de la base de données pour que les pages dynamiques ne ralentissent pas — que notre infrastructure est optimisée, et c’est ce qui rend le WordPress infogéré sur cette plateforme plus rapide que le même site sur un hébergement générique.
Foire aux questions
Ai-je encore besoin d’une extension de mise en cache comme WP Rocket ?
Non. La mise en cache de page entière est gérée au niveau du serveur web par le LSCache de LiteSpeed, et notre propre extension de cache — préinstallée et mise à jour automatiquement — y associe correctement WordPress, avec un cache d’objets Redis par site en arrière-plan. L’ajout d’une seconde extension de mise en cache de page entière entre généralement en conflit avec le cache au niveau du serveur plutôt que de l’aider ; cela n’est donc ni nécessaire ni recommandé.
La mise en cache risque-t-elle de perturber mon panier WooCommerce ou les pages destinées aux utilisateurs connectés ?
Non. Le panier, la commande, my-account et toutes les pages de nonce ou de session sont exclus du cache par défaut, et ESI maintient le fragment de panier et les totaux à jour sur les pages par ailleurs mises en cache. Les acheteurs voient toujours leur propre panier et un processus de paiement fonctionnel pendant que la vitrine se charge toujours depuis le cache.
Comment le cache reste-t-il à jour lorsque je publie ou modifie du contenu ?
La purge automatique intelligente se déclenche sur les hooks WordPress pertinents, de sorte que la publication, la modification de contenu ou le changement d’un produit, d’un prix ou d’une commande ne vide que les pages concernées et leurs archives — et non l’intégralité du cache — puis un crawler les précharge à nouveau. Vous pouvez également purger à la demande depuis le tableau de bord ou depuis l’intérieur de WordPress.
L’hébergement seul peut-il me donner de parfaits Core Web Vitals ?
Cela vous offre le meilleur TTFB possible, ce qui correspond à la part du serveur et à une avance pour le Largest Contentful Paint. Cependant, le LCP, le CLS et l’INP sont en grande partie déterminés par la page elle-même — la taille des images, les ressources bloquant le rendu, la stabilité de la mise en page et le JavaScript du thread principal. Notre infrastructure rend la contribution du serveur rapide et constante ; c’est en maintenant une charge front-end légère que vous comblerez le reste de l’écart.
Connexe
Essayez-le gratuitement pendant 14 jours
Lancez vos premiers sites gratuitement pendant 14 jours — sans carte bancaire. Vous transférez un réseau existant ? Les migrations sont gratuites et sans limite.
Commencer gratuitement