Intégrer LiteSpeed Cache dans Laravel

Laravel peut utiliser LiteSpeed pour stocker les réponses HTTP des routes compatibles. C'est utile lorsqu'une page peut être réutilisée sans exécuter toute l'application. Cela ne remplace ni l'optimisation des requêtes ni le magasin de cache de Laravel, qui peut utiliser Redis ou un autre pilote.

Préparer l'intégration

Vérifiez la compatibilité de votre version de PHP et de Laravel avec litespeed/lscache-laravel. Faites vos essais en staging et conservez le code, le fichier de dépendances verrouillées et la configuration précédents.

Depuis la racine du projet :

composer require litespeed/lscache-laravel
php artisan vendor:publish --provider='Litespeed\LSCache\LSCacheServiceProvider'

N'exécutez chaque commande que si la précédente s'est terminée correctement. Vérifiez le fichier de configuration publié sans écraser à l'aveugle une configuration existante. Le paquet utilise la découverte automatique de Laravel ; ne copiez pas dans un projet actuel des instructions d'enregistrement de fournisseurs ou de Kernel.php venant d'une ancienne branche.

Pour que LiteSpeed recherche les réponses stockées, la documentation du paquet indique cette règle dans le .htaccess public de l'application, en conservant les règles de Laravel :

<IfModule LiteSpeed>
    CacheLookup on
</IfModule>

Choisir les routes et une politique de purge

Commencez par une route de lecture qui renvoie exactement le même contenu à tous les visiteurs. Le middleware du paquet permet de définir une durée et d'indiquer si la réponse est publique, privée ou non stockable. Gardez les valeurs globales sans cache pendant que vous déterminez quelles routes peuvent l'utiliser.

Ne mettez pas tout le groupe web ou l'administration en cache public. Une page qui semble informative peut inclure dans son modèle le nom d'utilisateur, le jeton CSRF, la devise, la langue ou des données de session. Ces éléments nécessitent des exclusions ou une conception spécifique.

Définissez aussi quand invalider les réponses : publier une actualité ou modifier un prix doit retirer les pages liées. Le paquet fournit des étiquettes et des fonctions de purge ; utilisez celles qui correspondent à votre version et au modèle de contenu du projet.

Vérifier avant le déploiement

Testez plusieurs fois une route publique et examinez ses en-têtes HTTP : envoyer un en-tête de contrôle ne prouve pas que le serveur a stocké la réponse. Cherchez un succès de cache sur une requête ultérieure.

Vérifiez deux sessions indépendantes, les langues et toute variante pertinente. Modifiez le contenu de test et vérifiez que la purge le rend visible. La connexion, la déconnexion, les formulaires et les opérations ayant des effets doivent conserver leur comportement.

Si du contenu d'une autre session apparaît, désactivez la politique de cache concernée et purgez immédiatement ses réponses. Pour retirer l'intégration, annulez le middleware et la configuration, purgez le cache, puis retirez la dépendance avec votre procédure de déploiement. Il ne suffit pas d'enlever le paquet tant que des réponses restent stockées.