
Laravel Response Cache v8 : la mise en cache flexible expliquée
Spatie a lancé Laravel Response Cache v8 en janvier 2025, introduisant ce qu'ils appellent la « mise en cache flexible » dans ce populaire paquet. Pour les développeurs Laravel aux prises avec des défis de performance, cette mise à jour répond à l'une des principales critiques des versions précédentes : l'approche du tout ou rien en matière de mise en cache. La version 8 offre un contrôle granulaire sur le moment, la manière et pour qui les réponses sont mises en cache.
Ce qui a mené à cette mise à jour
Laravel Response Cache est depuis longtemps un choix populaire pour les développeurs Laravel qui souhaitent accélérer leurs applications sans ajouter d'infrastructure externe comme Varnish ou la mise en cache CDN. Ce paquet de mise en cache Laravel offre une approche simple pour l'optimisation des performances Laravel. Le paquet fonctionne en mettant en cache des réponses HTTP complètes, de sorte que lorsqu'un visiteur demande la même page deux fois, la deuxième requête saute toute la logique applicative et retourne directement la version en cache. Cette méthode de mise en cache des réponses HTTP Laravel est l'une des façons les plus efficaces d'accélérer les temps de réponse d'une application Laravel.
Le paquet existe depuis des années, avec plus de 10 millions de téléchargements sur Packagist et environ 2 400 étoiles sur GitHub. Spatie, l'entreprise belge derrière ce projet, maintient plus de 300 paquets open source.
Les versions précédentes avaient toutefois une limitation. Bien qu'il soit possible de créer des profils de cache personnalisés, la logique pour déterminer ce qui est mis en cache et pour combien de temps était assez rigide. Les développeurs devaient souvent contourner ces contraintes lors de la création d'applications avec des exigences de mise en cache complexes, comme les systèmes multi-locataires ou les applications avec du contenu basé sur les rôles.
Ce qui a changé dans la version 8
Des profils de cache plus flexibles
Le changement le plus important concerne la façon de définir les règles de mise en cache. Les profils de cache Laravel dans la v8 offrent une flexibilité sans précédent pour les scénarios complexes. La version 8 vous permet de créer des classes de profils de cache personnalisées avec un contrôle précis sur :
- Les règles de mise en cache basées sur l'utilisateur (mettre en cache différentes réponses pour différents types d'utilisateurs)
- La logique basée sur les en-têtes (varier le cache selon les en-têtes Accept ou Accept-Language)
- Le filtrage des paramètres de requête
- Les durées de cache dynamiques basées sur les attributs de la requête
Voici à quoi ressemble un profil personnalisé dans la v8 :
namespace App\CacheProfiles;
use Spatie\ResponseCache\CacheProfiles\BaseCacheProfile;
use Illuminate\Http\Request;
class CustomCacheProfile extends BaseCacheProfile
{
public function shouldCacheRequest(Request $request): bool
{
if ($request->is('api/*')) {
return true;
}
return $request->isMethod('GET');
}
public function cacheRequestUntil(Request $request): DateTime
{
if ($request->is('static/*')) {
return now()->addDay();
}
return now()->addMinutes(30);
}
}Une meilleure logique de contournement du cache
La version 8 vous donne plus de contrôle sur le moment où ignorer complètement le cache. Les capacités de contournement du cache Laravel incluent maintenant :
- Des cookies spécifiques
- Le statut d'authentification
- Les en-têtes de requête
- Les paramètres de requête
C'est important pour les tests A/B, le contenu personnalisé et les applications multi-locataires où différents utilisateurs ont besoin de réponses différentes. La mise en cache multi-locataire Laravel est maintenant beaucoup plus facile à implémenter grâce à ces règles de contournement granulaires.
Invalidation du cache améliorée
L'un des aspects les plus délicats de la mise en cache des réponses est de savoir quand la vider. L'invalidation du cache Laravel dans la version 8 améliore cela avec :
- L'invalidation sélective du cache (effacer des réponses en cache spécifiques sans tout vider)
- Un meilleur support des étiquettes de cache lors de l'utilisation de Redis
- Le vidage du cache basé sur les modèles via les observateurs
L'intégration des étiquettes de cache Laravel avec Redis permet un contrôle précis sur les réponses en cache à effacer.
Compatibilité avec Laravel 11
Le paquet fonctionne maintenant entièrement avec la structure simplifiée de Laravel 11. La configuration de la mise en cache Laravel 11 a été rationalisée, et ce paquet tire pleinement parti de cette nouvelle approche. L'enregistrement du middleware de mise en cache Laravel ressemble à ceci :
// bootstrap/app.php
->withMiddleware(function (Middleware $middleware) {
$middleware->web(append: [
\Spatie\ResponseCache\Middlewares\CacheResponse::class,
]);
})Améliorations de la configuration
Le fichier de configuration supporte maintenant plus d'options :
'flexible_caching' => [
'enabled' => true,
'vary_headers' => ['Accept', 'Accept-Language'],
'cache_lifetime_resolver' => null,
],Comment cela affecte les équipes Laravel
Pour les équipes qui développent des applications Laravel riches en contenu, des sites marketing ou des plateformes basées sur un CMS, cette mise à jour fait de la mise en cache des réponses une option plus réaliste. Auparavant, la rigidité des profils de mise en cache signifiait qu'on devait soit tout mettre en cache, soit écrire des contournements extensifs.
Attentes en matière de performance
Selon les tests de performance typiques, la mise en cache des réponses peut réduire les temps de chargement des pages de 200-500 ms à 5-15 ms pour les pages complexes. C'est une amélioration de 10 à 20 fois dans certains cas. Pour les équipes qui cherchent à réduire le temps de chargement des pages Laravel, la mise en cache des réponses offre des résultats exceptionnels. Les chiffres réels dépendent de la complexité de votre application et de la configuration de votre serveur, mais le principe demeure : servir une réponse en cache est toujours plus rapide que de la reconstruire.
Qui en bénéficie le plus
- Les équipes gérant des sites web publics à fort trafic
- Les applications avec des patterns de trafic principalement en lecture
- Les projets où la mise en place de Varnish ou d'une infrastructure similaire n'est pas pratique
- Les applications multi-locataires qui ne pouvaient pas utiliser la mise en cache des réponses auparavant
Tout site web Laravel à fort trafic peut bénéficier d'une configuration appropriée de mise en cache des réponses.
Ce qui reste pareil
Certaines limitations demeurent. La mise en cache des réponses nécessite toujours une gestion soigneuse de :
- Les jetons CSRF dans les formulaires
- Le contenu dépendant des sessions
- Les données en temps réel qui changent fréquemment
Notre point de vue sur cette mise à jour
En travaillant avec des applications Laravel à fort trafic, nous avons constaté que la mise en cache des réponses est souvent négligée au profit de la mise en cache des requêtes ou de la mise en cache partielle des vues. Le problème avec l'ancienne approche était qu'elle nécessitait trop de code personnalisé pour gérer des scénarios réels comme les rôles d'utilisateurs ou la personnalisation du contenu.
Notre équipe a testé les fonctionnalités de la v8 sur quelques projets clients, et l'API de profil de cache plus propre fait une vraie différence. Au lieu de se battre contre les présupposés du paquet, vous pouvez maintenant exprimer vos règles de mise en cache directement dans le code. L'invalidation du cache améliorée est également utile pour les applications de type CMS où les éditeurs de contenu ont besoin que leurs modifications apparaissent immédiatement.
Si vous utilisez déjà Laravel Response Cache, le chemin de mise à niveau devrait être simple. Consultez les notes de version pour tout changement majeur dans vos profils personnalisés.
En résumé
Laravel Response Cache v8 répond aux principales plaintes de flexibilité des versions antérieures. Les profils de cache améliorés, la meilleure logique de contournement et l'invalidation sélective donnent aux développeurs le contrôle dont ils ont besoin pour les applications complexes. Combiné avec la compatibilité Laravel 11 et les améliorations de performance, cette version fait de la mise en cache des réponses une option plus solide pour les projets Laravel.
Chez Rollin, nous recommandons d'évaluer la mise en cache des réponses tôt dans la planification de votre projet, surtout pour les applications riches en contenu où la mise en cache au niveau de l'infrastructure n'est pas disponible. Si vous développez une application Laravel à fort trafic et souhaitez de l'aide pour mettre en place une approche de mise en cache efficace, que ce soit la mise en cache des réponses, des requêtes ou des vues travaillant ensemble, notre équipe peut vous aider à concevoir un plan qui correspond à vos patterns de trafic et à la fréquence de mise à jour de votre contenu.
