LiteSpeed Cache fonctionne-t-il sur tous les hébergeurs ?

Non. LSCache nécessite LiteSpeed Web Server ou OpenLiteSpeed côté serveur. Sur Apache ou Nginx, le plugin reste installable mais ses fonctions de cache page sont désactivées — seul l'optimiseur CSS/JS reste actif. Les hébergeurs mutualisés sur Apache (la majorité du marché) ne bénéficient pas du cache serveur natif.

Faut-il activer le cache des utilisateurs connectés ?

Non par défaut. Les utilisateurs connectés voient des pages personnalisées : les mettre en cache risque d'exposer des données de session à d'autres utilisateurs. Exception possible sur les sites membres où les pages connectées sont identiques pour tous — à utiliser uniquement avec des exclusions strictes et ESI activé pour les blocs dynamiques.

LSCache est-il compatible avec Elementor, Divi et WooCommerce ?

Elementor et WooCommerce disposent de préréglages d'exclusion intégrés dans LSCache. Divi nécessite de désactiver la combinaison JS, et parfois la minification CSS si les animations se cassent. La méthode fiable : activer une option CSS/JS à la fois, tester visuellement, purger le cache entre chaque étape.

Comment vérifier que le cache LiteSpeed sert bien les pages ?

Via curl : `curl -sI https://votre-site.com/ | grep -i x-litespeed-cache`. Une réponse `x-litespeed-cache: hit` confirme que LiteSpeed a servi la page sans toucher PHP ni MySQL. `miss` indique que la page vient d'être générée et mise en cache pour les prochaines requêtes.

Quelle différence entre purger le cache page et vider le cache objet ?

La purge LSCache efface les pages HTML mises en cache côté serveur. Vider le cache objet (Redis ou Memcached) efface les résultats de requêtes PHP/MySQL stockés en mémoire vive. Les deux sont indépendants : une purge LSCache ne touche pas Redis, et inversement. Après une modification de contenu, seule la purge LSCache est nécessaire.

Configurer LiteSpeed Cache pour WordPress

LiteSpeed Cache (LSCache) est le seul plugin WordPress à communiquer directement avec LiteSpeed Web Server pour stocker les pages HTML côté serveur — sans proxy intermédiaire ni surcouche PHP. Chaque page mise en cache est servie par le moteur web avant que WordPress ne soit chargé : ni PHP ni MySQL ne sont sollicités.

Sur des sites WordPress identiques mesurés en production, le TTFB médian passe de 800-1 500 ms sans cache à 20-50 ms avec LSCache actif sur l'infrastructure LiteSpeed Enterprise de Tomco. Le plugin seul ne suffit pas : LiteSpeed Web Server natif est requis côté hébergeur, pas Apache ni Nginx avec un module tiers. Pour situer LSCache dans la hiérarchie complète des leviers d'optimisation (hébergement, cache, applicatif, CDN), le guide performance WordPress 2026 détaille la séquence d'application.

À retenir

LSCache communique directement avec LiteSpeed Web Server : la page est servie sans appeler PHP ni MySQL.

TTFB mesuré sur infrastructure LiteSpeed Tomco : 20-50 ms vs 800-1 500 ms sur Apache mutualisé.

Trois réglages déterminent 80 % du gain : Enable Cache ON, exclusions correctes (/cart, /checkout, /wp-admin), TTL adapté au type de site.

Sur Apache ou Nginx, le plugin reste installable mais le cache page est désactivé — seules les optimisations CSS/JS et la conversion WebP restent actives.

Vérification fiable en une ligne : curl -sI https://votre-site.com | grep -i x-litespeed-cache doit renvoyer hit après la première requête.

Prérequis

Hébergeur LiteSpeed Web Server ou OpenLiteSpeed ≥ 1.7.16 — l'hébergement WordPress Tomco inclut LiteSpeed natif sur toutes les formules, sans surcoût ni option payante
WordPress ≥ 6.0, PHP ≥ 8.1 (PHP 8.3-8.5 disponibles sur l'infrastructure Tomco)
Accès administrateur WordPress et FTP/SSH si possible (pour la vérification .htaccess)
Aucun autre plugin de cache actif (W3 Total Cache, WP Rocket, WP Super Cache, Cache Enabler) : désactiver et supprimer avant installation pour éviter les conflits de directives .htaccess et de cookies de session

Installation du plugin LiteSpeed Cache

Trois méthodes d'installation, classées par ordre de simplicité.

Via l'administration WordPress (recommandé) : Extensions > Ajouter une extension > rechercher "LiteSpeed Cache" > Installer > Activer.

Via WP-CLI (utile en CI/CD ou sur plusieurs sites) :

wp plugin install litespeed-cache --activate

Via upload ZIP depuis wordpress.org/plugins/litespeed-cache — fallback en cas de restrictions réseau ou de site hors ligne.

Tableau de bord du plugin LiteSpeed Cache dans l'administration WordPress, affichant le statut de connexion serveur et les statistiques de cache — Interface LSCache — statut LiteSpeed Web Server détecté et compteurs de cache actifs.

Après activation, le menu LiteSpeed Cache apparaît dans la barre latérale. Le tableau de bord affiche immédiatement le statut de détection serveur :

"LiteSpeed Web Server Detected" — le cache page complet est opérationnel.
"Server Not Detected" — le serveur tourne sur Apache, Nginx ou OpenLiteSpeed sans configuration LSCache. Seules les optimisations CSS/JS et la conversion WebP restent actives, sans cache full-page.

Sur Enhance Panel (panneau de contrôle Tomco), la configuration .htaccess requise par LSCache est régénérée automatiquement à chaque activation du plugin. Un bloc # BEGIN LSCACHE … # END LSCACHE est inséré en tête du fichier à la racine du site. Aucune intervention manuelle n'est nécessaire dans ce cas — la documentation officielle LiteSpeed décrit le contenu exact pour les environnements non gérés.

Réglages Cache — TTL et exclusions

Ouvrir LiteSpeed Cache > Cache > Cache. Trois paramètres à configurer en premier :

Enable LiteSpeed Cache : ON — à activer immédiatement.

Default Public Cache TTL : durée pendant laquelle une page mise en cache est servie sans re-génération.

Cas d'usage	TTL recommandé
Blog / site institutionnel peu modifié	86 400 s (24h)
Site e-commerce, actualités	3 600 s (1h)
Site avec contenu temps réel	600 s (10 min)

Separate Cache for Mobile : activer uniquement si le thème utilise un template mobile distinct (rare). Sur les thèmes responsive (Bootstrap, GeneratePress, Astra, etc.), laisser OFF — l'activation crée des entrées de cache doublonnées sans bénéfice.

Exclusions à configurer (onglet Exclude)

Ces URI ne doivent jamais être mis en cache :

/wp-admin
/wp-login.php
/cart
/checkout
/my-account
/thank-you
/order-received

LSCache détecte WooCommerce automatiquement et ajoute /cart et /checkout à la liste d'exclusion lors de l'activation. Vérifier que ces entrées sont bien présentes avant de mettre le site en production.

Réglages à ne pas activer par défaut :

Cache Logged-In Users : OFF — risque de fuite de données entre sessions (voir section ESI).
Cache Login Page : OFF — la page de connexion doit rester hors cache pour le rate limiting et le CSRF.
Cache REST API : ON — accélère les appels WP REST API (blocs Gutenberg, headless).

Configurer via WP-CLI

Pour scripter le déploiement sur plusieurs sites (staging → production, parc client), LSCache expose chaque réglage via WP-CLI. Les noms d'options sont identiques à ceux de l'interface, en kebab-case.

# Activer le cache et fixer le TTL public à 24h
wp litespeed-option set cache true
wp litespeed-option set cache-ttl_pub 86400

# Exclure les routes WooCommerce sensibles
wp litespeed-option set cache-exc "/cart\n/checkout\n/my-account"

# Activer la minification CSS/JS sans combinaison (sécurité maximale)
wp litespeed-option set optm-css_min true
wp litespeed-option set optm-js_min true

# Purger l'intégralité du cache après changement
wp litespeed-purge all

Liste complète des clés disponibles : wp litespeed-option list. Cette approche élimine les erreurs manuelles lors d'un déploiement multi-environnements et permet de versionner la configuration cache dans un script d'init.

Optimisation CSS et JavaScript

Ouvrir LiteSpeed Cache > Page Optimization. Activer les options dans cet ordre précis, une par une, en testant et en purgeant le cache entre chaque étape.

Option	Impact	Risque	Recommandation
Minify CSS	-5 à -15 % taille CSS	Faible	Activer par défaut
Minify JS	-5 à -15 % taille JS	Faible	Activer par défaut
Combine CSS	1 requête HTTP au lieu de N	Moyen	Tester — conflits possibles sur Elementor, Avada
Combine JS	Idem JS	Élevé	Tester avec attention — formulaires, sliders, maps
Load CSS Asynchronously	LCP réduit de 200-500 ms	Moyen	Activer et valider visuellement le rendu initial
Defer JS	TBT réduit, TTI amélioré	Moyen	Désactiver si des scripts utilisent `document.write`

Cas Divi : désactiver Combine JS. Divi génère son CSS dynamiquement — la combinaison JS casse les animations et les builders en mode édition. Tester Combine CSS en production uniquement après validation complète du thème.

Cas Elementor : Combine JS peut rompre les widgets de formulaire et de popup. Utiliser l'option "Load JS Deferred" d'Elementor plutôt que celle de LSCache pour éviter les conflits.

La minification seule est sans risque sur l'ensemble des thèmes testés. La combinaison est le paramètre le plus susceptible de causer des régressions visuelles — ne jamais l'activer en masse sans parcours de test.

Image Optimization et WebP

Ouvrir LiteSpeed Cache > Image Optimization.

Onglet Image Optimization du plugin LiteSpeed Cache avec les options WebP, lazy load et dimensions explicites — Onglet Image Optimization — activation WebP, lazy load et correction des dimensions manquantes.

WebP Replacement : LSCache peut convertir les images JPEG et PNG en WebP et les servir automatiquement via une directive .htaccess, sans traitement PHP à la requête. Deux modes disponibles :

Via OptimGuru (service LiteSpeed) : conversion sur les serveurs LiteSpeed, crédits gratuits puis payants. Paramètre Pull dans l'interface.
Local : requiert cwebp installé sur le serveur. Disponible sur l'infrastructure Tomco — conversion déclenchée via la file d'attente du plugin ou en CLI :

# Pousser toutes les images vers la file de conversion WebP
wp litespeed-image push

# Récupérer les images converties
wp litespeed-image pull

Lazy Load Images : ON. Les images hors viewport ne sont chargées qu'au scroll. Impact direct sur le LCP si bien configuré : l'image hero (visible immédiatement) doit être exclue du lazy load.

Pour exclure le hero : ajouter son nom de classe CSS ou son URL partielle dans le champ "Lazy Load Excludes" (exemple : .hero-image, -hero-). Sans cette exclusion, le LCP est dégradé car l'image la plus impactante est chargée en différé.

Add Missing Dimensions : ON. Injecte les attributs width et height manquants sur les balises <img>. Sans dimensions explicites, le navigateur ne réserve pas d'espace avant le chargement, ce qui provoque du CLS (Cumulative Layout Shift). Cette option seule peut faire passer un CLS de 0,15 à 0.

Pour une analyse complète des métriques Core Web Vitals, référez-vous aux critères de mesure Google.

ESI et utilisateurs connectés

Edge Side Includes (ESI) permet de mettre en cache une page entière tout en maintenant des blocs spécifiques dynamiques. Sur WooCommerce, la page produit est cachée globalement mais le widget panier est chargé individuellement par requête — chaque utilisateur voit son propre panier sans que LSCache serve une version erronée.

Pour activer ESI : LiteSpeed Cache > Cache > Advanced > Enable ESI : ON.

Prérequis : LiteSpeed Web Server supporte ESI nativement. OpenLiteSpeed requiert une version récente (1.7.16+) — vérifier avec l'hébergeur.

Cache Logged-In Users : maintenir OFF dans la grande majorité des cas. Les utilisateurs connectés voient des pages personnalisées (barre d'administration, contenus conditionnels, données de profil). Mettre ces pages en cache crée un risque réel d'exposition de données entre sessions si les exclusions sont mal configurées.

Exception justifiée : site de documentation ou d'e-learning où les pages connectées sont identiques pour l'ensemble des membres, sans aucun contenu personnalisé. Dans ce cas, activer uniquement avec ESI pour isoler les widgets de session (nom utilisateur, tableau de bord compte).

Pour WooCommerce avec ESI actif, le flux typique est :

Requête /boutique/produit-x → LSCache sert la page mise en cache
Le widget panier dans la page contient une balise ESI → requête séparée vers /cart-fragment
LSCache sert le fragment panier individuellement mis en cache par session

Vérification et mesure

Schéma du flux requête HTTP avec LiteSpeed Cache : chemin HIT direct depuis le serveur versus chemin MISS passant par PHP et MySQL — Flux d'une requête HTTP — cache HIT servi directement par LiteSpeed vs cache MISS avec exécution PHP et requête base de données.

Vérifier l'état du cache via HTTP

Après configuration et purge complète, effectuer cette vérification sur la page d'accueil :

curl -sI https://votre-site.com/ | grep -i "x-litespeed-cache"

Réponses attendues :

Valeur	Signification
`x-litespeed-cache: hit`	Page servie depuis le cache — PHP non exécuté
`x-litespeed-cache: miss`	Première requête après purge — page mise en cache pour les suivantes
`x-litespeed-cache: no-cache`	URI exclu ou utilisateur connecté — comportement attendu
Absence de l'en-tête	LSCache non actif ou serveur non LiteSpeed

La première requête après une purge renvoie toujours miss. La deuxième doit renvoyer hit.

Purge du cache

Purger le cache après chaque changement de configuration via la barre d'administration WordPress : LiteSpeed Cache > Purge All. Une purge partielle par URL est disponible pour les articles individuels (utile après correction typographique).

En CLI pour intégrer la purge dans un pipeline de déploiement :

wp litespeed-purge all          # purge totale
wp litespeed-purge url https://votre-site.com/page-modifiee/

Mesure PageSpeed avant/après

Utiliser PageSpeed Insights en mode mobile. Effectuer au minimum trois mesures consécutives et retenir la médiane (la charge serveur fluctue).

Gains attendus sur un site WordPress standard après configuration complète de LSCache sur infrastructure LiteSpeed :

Métrique	Sans cache (Apache mutualisé)	Avec LSCache (LiteSpeed Tomco)
TTFB	800-1 500 ms	20-50 ms
LCP	3-6 s	0,8-2,5 s
TBT	300-800 ms	50-200 ms

Ces mesures correspondent à un site WordPress avec thème classique, 20-30 plugins et sans CDN. Les gains varient selon la complexité du thème et le volume de plugins actifs.

Dépannage des cas fréquents

Cache désactivé après réinstallation du plugin

Si l'en-tête x-litespeed-cache n'apparaît pas après une réactivation, vérifier la présence du bloc de réécriture dans le .htaccess à la racine du site :

grep -A2 "BEGIN LSCACHE" .htaccess

Sur Enhance Panel (Tomco), cette directive est régénérée automatiquement à chaque activation. En cas d'absence persistante, désactiver puis réactiver le plugin force la regénération. Si le bloc reste manquant, le fichier .htaccess est probablement en lecture seule — corriger les permissions à 644 et redémarrer l'activation.

Pages dynamiques mises en cache par erreur

Symptôme : un utilisateur connecté voit le compte d'un autre, ou un formulaire affiche d'anciennes données. Cause typique : exclusions mal configurées ou cookies de session non détectés.

Vérifier que les cookies WordPress et WooCommerce sont listés dans LiteSpeed Cache > Cache > Excludes > Do Not Cache Cookies :

wordpress_logged_in_
wp-postpass_
woocommerce_items_in_cart
woocommerce_cart_hash

LSCache ajoute la première ligne automatiquement. Les cookies WooCommerce nécessitent une vérification manuelle si une mise à jour récente du plugin a remplacé l'ancienne configuration.

Conflit avec un plugin tiers (formulaires, sliders, popups)

Symptôme : un formulaire de contact ne s'envoie plus, un slider ne se charge pas, un popup reste invisible après mise en cache. Cause habituelle : option Combine JS active.

Procédure de diagnostic, du moins au plus radical :

Désactiver Combine JS uniquement → tester. Si résolu : exclure le script précis via Page Optimization > JS Excludes.
Sinon désactiver Defer JS → tester.
En dernier recours, désactiver Minify JS sur la page concernée via le shortcode [litespeed_no_minify_js] inséré dans le contenu.

Toujours purger le cache entre chaque essai (wp litespeed-purge all) pour éviter de diagnostiquer une version mise en cache.

Hit rate inférieur à 60 %

Indicateur : LiteSpeed Cache > Toolbox > Heartbeat. Un hit rate bas (< 60 %) signale un cache fragmenté. Causes principales : TTL trop court, purge automatique trop agressive (publication de commentaires, mises à jour de plugin), Vary mal configuré (mobile + connecté combinés).

Activer le Crawler (LiteSpeed Cache > Crawler) pour précharger le cache après chaque purge sur les URLs prioritaires (homepage, articles top, catégories WooCommerce). Sur un site de 500 articles, le crawler met typiquement 8-15 minutes pour reconstituer un cache complet sur l'infrastructure NVMe Gen4 — à comparer aux 30-60 minutes nécessaires sur du SATA classique.

Stack sous-jacente et limites du plugin

La stack LiteSpeed Enterprise de Tomco — AMD EPYC / Ryzen 9, SSD NVMe Gen4 (~1 M IOPS lecture aléatoire), PHP 8.3 à 8.5, HTTP/3 actif, datacenter France — constitue la couche sous-jacente sur laquelle LSCache délivre les chiffres mesurés plus haut. Le plugin seul sur un hébergeur Apache mutualisé ne produit pas les mêmes résultats : le cache page est désactivé et seules les optimisations applicatives (CSS/JS, WebP) restent disponibles.

Pour aller plus loin sur les couches complémentaires de cache (Redis object cache, OPcache PHP) et leur articulation avec LSCache, voir le guide performance WordPress 2026 et la grille tarifaire des offres d'hébergement Tomco — toutes incluent LiteSpeed Enterprise sans surcoût.