Hébergement et performances
Comment nous accélérons WordPress : LiteSpeed Enterprise, LSCache et Redis par site
La requête WordPress la plus rapide est celle qui ne s'exécute jamais — voici comment notre pile 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 WordPress standard est coûteuse. Le serveur web délègue à PHP, PHP lance WordPress, exécute les extensions, interroge MySQL à quelques dizaines reprises, assemble le HTML, et ce n'est qu'alors qu'il renvoie les octets. Sur un site fréquenté, toute cette danse a lieu pour chaque visiteur, et c'est là que s'envole la quasi-totalité de votre temps jusqu'au premier octet.
Notre réponse consiste à faire en sorte 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 sites WordPress gérés grand public —, la grande majorité des pages vues front-end sont servies sous forme de page complète pré-rendue directement depuis le cache, sans appeler PHP ni toucher à la base de données. Le reste de cet article explique comment s'articulent les couches qui rendent cela possible, et où chacune trouve sa raison d'être.
La nuance importante est qu'il ne s'agit pas de caches concurrents entre lesquels il faudrait choisir. Le cache de page complète, le cache d'objets et la périphérie CDN gèrent 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 y appose des en-têtes de contrôle du cache et de balises LiteSpeed, et LiteSpeed sert la page complète directement lors de la requête suivante : aucun processus PHP n'est lancé, aucune requête MySQL n'est émise. C'est le tout premier levier d'action sur le TTFB de WordPress, car il supprime l'intégralité du démarrage de l'application du parcours critique.
Parce que LSCache réside au sein du serveur Web plutôt que dans un plugin PHP, il commence à fonctionner plus tôt dans le cycle de vie de la requête et conserve les pages sous une forme que le serveur peut purger instantanément. Un robot d'exploration du cache maintient les pages populaires au chaud, de sorte que le premier visiteur après une purge n'est pas celui qui supporte le coût de la régénération de la page. Le résultat est un TTFB sensiblement plus bas et plus constant que celui d'un cache purement logiciel greffé sur une pile générique, où le cache se trouve toujours derrière PHP.
Notre propre plugin de cache de niveau dépôt est préinstallé et mis à jour automatiquement sur chaque site, connectant WordPress à LSCache correctement dès son installation. Sur une origine autre que LiteSpeed, il 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 faire leur travail — ainsi, un site migré n'est jamais laissé dans un état partiellement configuré et cassé.
Rester rapide sans servir 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 d'une autre personne, et servir à n'importe qui une page qui aurait dû changer. Tous deux sont résolus au niveau de la couche de cache plutôt qu'en mettant moins en cache.
L'ESI (Edge Side Includes) nous permet de mettre la page en cache tout en perçant des brèches pour les parties qui doivent rester dynamiques. Sur une boutique WooCommerce, le catalogue, les pages de produits et de catégories sont servis sous forme de cache de page complète pour un TTFB le plus rapide possible, tandis que l'ESI rend le fragment du panier, les totaux du mini-panier et l'état du compte par requête. Le panier, la commande, mon compte et toutes les pages de jetons (nonce) ou de session sont exclus par défaut. Les acheteurs voient toujours leur propre panier et un tunnel de commande fonctionnel, tout en profitant de la vitrine depuis le cache.
La fraîcheur est gérée par un système de purge automatique intelligent. 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 se rafraîchissent immédiatement plutôt que selon un compte à rebours, et vous pouvez également effectuer une purge à la demande depuis le tableau de bord ou depuis WordPress. La purge basée sur les balises signifie que la modification d'un article efface cet article et ses archives — et non l'ensemble du cache —, de sorte qu'une simple modification ne réinitialise pas tout le site à froid.
Cache d'objets Redis par site : pour ce qui ne peut pas être une page entière
Toutes les requêtes ne peuvent pas être des pages statiques complètes. Les sessions connectées, l'administration WordPress, les paniers WooCommerce, la recherche et les fragments dynamiques laissés par ESI doivent tous exécuter PHP. Pour ceux-ci, l'objectif passe de « contourner l'application » à « contourner la base de données ».
Chaque site bénéficie de son propre cache d'objets Redis dédié. WordPress met en cache les résultats des lectures répétées de la base de données (options, transients, recherches de publications et de termes, ainsi que les données de produits et de sessions WooCommerce) en mémoire, afin que la même requête ne soit pas exécutée sur MySQL à chaque accès. L'effet est particulièrement visible là où le cache de page complète ne peut pas intervenir : des tableaux de bord plus rapides, des paniers plus rapides et une charge de base de données considérablement réduite en cas de trafic.
Le cache d'objets est spécifique à chaque site et n'est pas partagé, ce qui importe tant pour les performances que pour l'isolement. Combiné à la limitation des requêtes de la base de données par site, les requêtes lourdes ou mal conçues d'un site ne peuvent pas priver la base de données de ses voisins. Vous pouvez en lire plus sur la façon dont l'ensemble de la configuration multicouche s'articule sur notre page de fonctionnalités de mise en cache, et sur les frontières entre les locataires dans le cadre de l'isolement.
Le réseau de périphérie et le transport sous-jacent
Le cache présent sur l'origine doit tout de même traverser le réseau. Devant le serveur se trouve la périphérie du CDN, de sorte que les actifs statiques et les pages mises en cache sont servis à partir d'un point de présence proche du visiteur, et l'origine reste calme même sous charge. Pour notre gamme d'hébergement sans footprint-free, cette même périphérie est un pool multi-CDN réparti sur plusieurs fournisseurs, qui sert un objectif de footprint ainsi qu'un objectif de performance ; sur WordPress standard, il s'agit simplement d'une couche rapide et bienveillante qui maintient les origines inactives.
Sous le capot, les fondamentaux ne sont pas négligés. Les sites s'exécutent sur un stockage NVMe avec HTTP/3, de sorte que les octets envoyés par le cache transitent par un protocole moderne et multiplexé, adossé à un stockage ultra-rapide en cas de cache miss. Aucune de ces couches n'est une option : LiteSpeed, LSCache, Redis par site, NVMe et HTTP/3 constituent la base de chaque formule, et non un niveau supérieur payant.
Ce qui fait vraiment bouger les Core Web Vitals
Il vaut la peine d'être précis, car l'hébergement est souvent survendu sur les Core Web Vitals. Le TTFB est la partie de l'équation qui relève du serveur, et la pile de mise en cache située au-dessus est ce qui le fait baisser : une page complète mise en cache et servie via HTTP/3 depuis la périphérie atteint un niveau de TTFB difficilement compressible. Le TTFB constituant le point de départ du Largest Contentful Paint, une origine rapide donne à chaque métrique en aval une longueur d'avance qu'elle ne peut pas obtenir autrement.
Mais le LCP, le CLS et l'INP se décident principalement dans le navigateur, par la page elle-même : une image principale non optimisée, du CSS et du JavaScript qui bloquent le rendu, une mise en page qui décale le contenu lors du chargement des polices et des publicités, ainsi qu'une lourde charge sur le thread principal par les extensions. Aucun cache serveur ne peut réparer une image principale de 2 Mo ou un thème qui intègre des mégaoctets de JavaScript. Un hébergement honnête rend la contribution du serveur pratiquement gratuite et constante, c'est ensuite au site de veiller à alléger son front-end.
Cette division du travail est un modèle mental utile. Nous garantissons que la requête parvient rapidement au navigateur et le reste malgré le trafic ; vous veillez à ce que la charge utile reste légère et stable. C'est précisément là où ces deux aspects se rejoignent — préchauffage du cache, diffusion en périphérie et réactivité de la base de données pour éviter le ralentissement des pages dynamiques — que notre infrastructure est optimisée, et c'est ce qui rend l'offre WordPress gérée 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'un plugin de mise en cache comme WP Rocket ?
Non. La mise en cache de pages complètes est gérée au niveau du serveur Web par LSCache de LiteSpeed, et notre propre extension de cache — préinstallée et mise à jour automatiquement — relie correctement WordPress à celui-ci, avec un cache d'objets Redis par site en arrière-plan. L'ajout d'une seconde extension de mise en cache de pages complètes entre en conflit avec le cache au niveau du serveur plutôt que de l'aider, elle n'est donc ni nécessaire ni recommandée.
Le cache risque-t-il de perturber mon panier WooCommerce ou mes pages de connexion ?
Non. Le panier, la commande, mon-compte et toutes les pages de nonce ou de session sont exclus du cache par défaut, et l'ESI maintient le fragment de panier et les totaux actifs sur les pages par ailleurs mises en cache. Les acheteurs voient toujours leur propre panier et une page de commande fonctionnelle tandis que la vitrine se charge toujours depuis le cache.
Comment le cache reste-t-il à jour lorsque je publie ou modifie du contenu ?
Le nettoyage automatique intelligent s'active sur les hooks WordPress pertinents. Ainsi, la publication, la modification de contenu ou le changement d'un produit, d'un prix ou d'une commande ne nettoie que les pages concernées et leurs archives — et non l'ensemble du cache — et un robot d'indexation les réchauffe à nouveau. Vous pouvez également effectuer un nettoyage à la demande depuis le tableau de bord ou depuis WordPress.
Un hébergement à lui seul peut-il me garantir des Core Web Vitals parfaits ?
Il vous offre le meilleur TTFB possible, ce qui correspond à la part du serveur et donne une longueur d'avance au Largest Contentful Paint. Mais le LCP, le CLS et l'INP dépendent largement de la page elle-même : dimensions des images, ressources bloquant le rendu, stabilité de la mise en page et JavaScript du thread principal. Notre pile technologique garantit une contribution du serveur rapide et constante ; c'est l'allègement de la charge utile front-end qui permet de combler le reste de l'écart.
Associé
Essayez-le gratuitement pendant 14 jours
Créez vos premiers sites gratuitement pendant 14 jours — sans carte bancaire. Vous déplacez un réseau existant ? Votre première migration est offerte.
Commencer gratuitement