Laravel Cache : guide pratique pour la performance

Une bonne stratégie de Laravel cache est souvent le gain de performance le plus rapide que vous puissiez offrir à une application. Chaque aller-retour vers la base de données, chaque appel d'API externe et chaque rendu de page lourd coûte du temps ; calculer ces résultats une seule fois et les stocker au lieu de les recalculer à chaque requête peut faire tomber les temps de réponse à quelques millisecondes. Dans ce guide, j'aborde les drivers de cache, la mise en cache des requêtes et des pages, et le sujet le plus critique de tous — invalider le cache en toute sécurité — avec des exemples concrets.

Quand le cache est-il vraiment utile ?

Le cache brille pour les données coûteuses à produire mais qui changent rarement. Les candidats typiques sont :

les requêtes de reporting avec de lourds JOIN ou de l'agrégation,
les menus, réglages ou listes de catégories affichés sur chaque page,
les réponses d'API externes lentes ou limitées (taux de change, météo),
les sorties HTML de page complète qui changent peu souvent.

À l'inverse, les données propres à un utilisateur qui doivent être exactes en temps réel (solde du panier, statut de paiement) ne sont généralement pas à mettre en cache. Première règle : mesurez d'abord. Mettez en cache l'endroit que vous avez prouvé lent.

Choisir le bon driver

La couche de cache de Laravel est indépendante du driver ; la configuration se trouve dans config/cache.php, et le store par défaut est défini par la variable CACHE_STORE de votre fichier .env. Les principales options sont :

file — aucune installation, suffisant pour de petits projets mono-serveur.
database — persistance sans service supplémentaire ; bon pour une charge modérée.
redis / memcached — le choix recommandé pour le trafic élevé, plusieurs serveurs et le support des tags.
array — ne vit que le temps d'une requête ; pratique pour les tests.

Si vous attendez un trafic important en production, Redis est presque toujours la bonne réponse. La configuration ressemble à ceci :

# .env
CACHE_STORE=redis
REDIS_HOST=127.0.0.1
REDIS_PORT=6379

Mise en cache des requêtes : le motif remember

L'API la plus utilisée est Cache::remember() : elle renvoie la valeur si la clé existe, sinon elle exécute la closure, stocke le résultat et le renvoie. Cela condense la logique « renvoie si présent, sinon calcule et stocke » en une seule ligne.

use Illuminate\Support\Facades\Cache;

$populaire = Cache::remember('projects:populaire', now()->addHour(), function () {
    return Project::where('is_published', true)
        ->orderByDesc('views')
        ->take(10)
        ->get();
});

La durée peut être un DateTime (now()->addHour()) ou un nombre de secondes. Si vous ne voulez jamais d'expiration, utilisez Cache::rememberForever() — mais l'invalidation devient alors entièrement votre responsabilité.

Des helpers de plus bas niveau sont aussi disponibles :

Cache::put('cle', $valeur, now()->addMinutes(10));
$valeur = Cache::get('cle', 'defaut');
Cache::has('cle');
Cache::forget('cle');
Cache::increment('compteur_visites');

Mise en cache de page complète et de fragment

Quand le cache de requêtes ne suffit pas, vous pouvez aussi stocker le HTML rendu. Un motif simple au niveau du contrôleur :

public function index()
{
    $html = Cache::remember('home:html', now()->addMinutes(15), function () {
        return view('site.index', $this->chargerDonnees())->render();
    });

    return response($html);
}

Si vous voulez mettre en cache toute la réponse au niveau HTTP, le faire dans un middleware est plus propre : utilisez l'URL de la requête comme clé, vérifiez-la avec Cache::has(), et si elle manque, générez et stockez la réponse. Sur des pages vitrines statiques, cette approche réduit la charge de la base de données à presque zéro.

Tags et invalidation sûre

La partie difficile du cache n'est pas de stocker, c'est d'invalider au bon moment. Lorsqu'un projet est mis à jour, vous devez supprimer toutes les clés de cache associées. Avec Redis ou Memcached, les tags rendent cela élégant :

Cache::tags(['projects'])->put('projects:populaire', $donnees, 3600);

// Quand un projet change :
Cache::tags(['projects'])->flush();

Les tags ne sont pas pris en charge par les drivers file et database ; dans ce cas, supprimez les clés manuellement. La méthode la plus robuste consiste à se brancher sur les événements du modèle :

// Dans le modèle Project
protected static function booted(): void
{
    static::saved(fn () => Cache::forget('projects:populaire'));
    static::deleted(fn () => Cache::forget('projects:populaire'));
}

En ligne de commande, pour vider tout le cache applicatif :

php artisan cache:clear

Caches de config, de routes et de vues

Il existe une couche distincte à ne pas confondre avec le cache de données applicatives : les caches propres au framework. Sur un serveur de production, exécuter ceci après le déploiement apporte un vrai gain de vitesse :

php artisan config:cache
php artisan route:cache
php artisan view:cache
# tout d'un coup :
php artisan optimize

Mise en garde importante : quand config:cache est actif, les appels à env() ne fonctionnent de façon fiable que dans les fichiers de configuration. N'appelez pas env() directement dans votre code — lisez les valeurs via config(). Lorsque vous changez la configuration, reconstruisez-la avec php artisan config:clear.

Questions fréquentes

Pourquoi mes modifications n'apparaissent-elles pas pendant le développement ?

On vous sert très probablement un cache obsolète. La commande php artisan optimize:clear vide les caches de config, de routes, de vues et applicatif d'un seul coup ; c'est la première chose à essayer quand quelque chose semble anormal en local.

Dois-je utiliser file ou Redis ?

Pour un petit site mono-serveur, le driver file est largement suffisant. Passez à Redis si vous avez besoin d'un trafic élevé, de plusieurs serveurs, de compteurs atomiques ou d'une invalidation par tags.

Quelle durée de cache (TTL) choisir ?

Cela dépend de la fraîcheur tolérée des données. Pour des listes qui changent toutes les heures, 15 à 60 minutes est raisonnable ; pour des données qui ne changent presque jamais, rememberForever() plus une invalidation par événements est le plus efficace.

Envie de faire décoller les performances avec un cache bien conçu ? Mesurons ensemble les points lents de votre application Laravel et bâtissons la bonne stratégie de cache — contactez-moi.