Stratégies de Cache Magento 2 : Guide Complet (2026)

Le cache est le levier de performance le plus important dans Magento 2. Une pile de cache correctement configurée livre les pages en quelques millisecondes, réduit la charge serveur de 90%+ et améliore considérablement les scores Core Web Vitals. Ce guide couvre l’architecture complète du cache — cache intégré Magento, cache de page complète (FPC), Varnish, Redis, étiquetage de cache, contenu privé et hole punching — avec des configurations de production et des conseils de réglage.

En résumé : Magento 2 possède une architecture de cache en couches : cache de configuration (fichiers ou Redis), cache de page complète (intégré ou Varnish), et caches au niveau application (HTML de bloc, layout, traductions, etc.). Chaque couche sert un objectif différent et nécessite une configuration spécifique pour fonctionner efficacement en production.

Table des matières

1. Aperçu de l’architecture de cache Magento 2
2. Caches de configuration et d’application (cache.xml)
3. Cache de page complète : Intégré vs Varnish
4. Configuration Varnish pour Magento 2
5. Redis comme backend de session et de cache
6. Étiquetage et invalidation du cache
7. Contenu privé et hole punching
8. Indexeurs liés au cache et leur impact
9. Pièges courants du cache en production
10. FAQ

Aperçu de l’architecture de cache Magento 2

Magento 2 utilise un système de cache multicouche :

                     ┌─────────────────────────┐
                     │  Varnish (ou FPC intégré)│
                     │  Cache HTML page complète │
                     └─────────────────────────┘
                                │
                     ┌─────────────────────────┐
                     │  Redis (config/default)  │
                     │  Sessions, données cache │
                     └─────────────────────────┘
                                │
                     ┌─────────────────────────┐
                     │  Cache Système de Fichiers│
                     │  Fichiers générés, statics│
                     └─────────────────────────┘

Chaque couche a sa propre stratégie de cache, son TTL et son mécanisme d’invalidation. Une requête de page vérifie généralement Varnish en premier (qui sert le HTML en microsecondes), puis passe à Magento (qui vérifie les caches Redis), et enfin à la base de données en dernier recours.

Caches de configuration et d’application (cache.xml)

Magento définit les types de cache dans app/etc/di.xml et les modules peuvent déclarer des caches personnalisés via etc/cache.xml :

<config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:noNamespaceSchemaLocation="urn:magento:framework:Cache/etc/cache.xsd">
    <type name="my_custom_cache" translate="label,description">
        <label>Mon Cache Personnalisé</label>
        <description>Stocke les données précalculées pour les fonctionnalités personnalisées</description>
    </type>
</config>

Vous pouvez gérer tous les types de cache depuis la CLI :

# Lister tous les types de cache et leur statut
bin/magento cache:status

# Activer/désactiver des types spécifiques
bin/magento cache:enable block_html layout
bin/magento cache:disable full_page

# Nettoyer (vider) des types de cache spécifiques
bin/magento cache:clean config layout block_html

# Vider tout le stockage de cache (Redis + système de fichiers)
bin/magento cache:flush

Les types de cache les plus importants pour les performances :

Cache de page complète : Intégré vs Varnish

Magento 2 est livré avec deux implémentations FPC.

FPC intégré (Magento_PageCache) : Stocke le HTML mis en cache dans le backend de cache par défaut (généralement Redis). Bon pour les configurations mono-serveur ou les environnements où Varnish n’est pas disponible (hébergement mutualisé, certaines plateformes PaaS). Les performances sont correctes mais pas optimales.

Varnish : Un accélérateur HTTP qui sert les pages mises en cache avant qu’elles n’atteignent Magento. Il est plus rapide car il opère au niveau HTTP — aucune exécution PHP, aucun bootstrap de framework. Adobe recommande officiellement Varnish pour la production.

Basculez entre eux dans app/etc/env.php :

'http_cache_hosts' => [
    [
        'host' => '127.0.0.1',
        'port' => '80',
    ]
],

Lorsque des hôtes Varnish sont configurés, Magento désactive son FPC intégré et envoie des en-têtes Cache-Control pour que Varnish les interprète.

Configuration Varnish pour Magento 2

Magento génère un VCL Varnish pour vous :

bin/magento varnish:vcl:generate --export-version=7 > default.vcl

Paramètres Varnish clés pour Magento :

vcl 4.1;

backend default {
    .host = "127.0.0.1";
    .port = "8080";
}

sub vcl_recv {
    # Ne jamais mettre en cache les pages admin, checkout ou client
    if (req.url ~ "^/(admin|customer|checkout|sales)") {
        return (pass);
    }

    # Purge lors du nettoyage du cache
    if (req.method == "PURGE") {
        if (client.ip ~ purge_acl) {
            return (purge);
        }
        return (synth(405));
    }

    # Supprimer les cookies pour le contenu statique
    if (req.url ~ "^/(pub/)?(media|static)/") {
        unset req.http.cookie;
        return (hash);
    }

    # Supprimer les cookies GA avant la recherche dans le cache
    if (req.http.cookie) {
        set req.http.cookie = regsuball(req.http.cookie, "__utm[^=]+=[^;]+(; )?", "");
        if (req.http.cookie == "") {
            unset req.http.cookie;
        }
    }

    return (hash);
}

Surveillez le taux de hit du cache avec varnishstat. Une boutique Magento 2 bien réglée devrait atteindre un taux de hit de cache de 90–95%.

Redis comme backend de session et de cache

Redis est le backend de cache et de session recommandé pour les boutiques Magento 2 en production. Configurez-le dans app/etc/env.php :

'session' => [
    'save' => 'redis',
    'redis' => [
        'host' => '127.0.0.1',
        'port' => '6379',
        'database' => 0
    ]
],
'cache' => [
    'frontend' => [
        'default' => [
            'backend' => 'Cm_Cache_Backend_Redis',
            'backend_options' => [
                'server' => '127.0.0.1',
                'port' => '6379',
                'database' => 1
            ]
        ],
        'page_cache' => [
            'backend' => 'Cm_Cache_Backend_Redis',
            'backend_options' => [
                'server' => '127.0.0.1',
                'port' => '6379',
                'database' => 2,
                'compress_data' => '1'
            ]
        ]
    ]
]

La séparation des bases de données est essentielle — les sessions (0), le cache par défaut (1) et le cache de page (2) ne doivent jamais partager la même base de données Redis. Le backend de cache de page bénéficie de la compression (compress_data: 1) car il stocke des blocs HTML complets.

Étiquetage et invalidation du cache

Magento 2 utilise un système d’étiquetage de cache sophistiqué. Chaque élément de contenu mis en cache — HTML de bloc, page complète, sortie de layout — est étiqueté avec des identifiants décrivant ce dont il dépend :

• Une page catégorie est étiquetée avec cat_c_{category_id}
• Une page produit est étiquetée avec cat_p_{product_id}
• Le HTML de bloc est étiqueté avec sa classe de bloc et son template

Lorsque vous sauvegardez un produit ou une catégorie, Magento vide uniquement les caches étiquetés avec l’ID de cette entité — pas tout le stockage de cache. C’est pourquoi cache:clean limité par étiquette est plus rapide que cache:flush.

Vous pouvez étendre l’étiquetage de cache dans les modules personnalisés :

$cacheKey = 'my_module_data_' . $id;
$tags = ['my_module', 'my_module_' . $id];
$this->cache->save($data, $cacheKey, $tags);

Puis invalider par étiquette :

$this->cache->clean(\Zend_Cache::CLEANING_MODE_MATCHING_ANY_TAG, ['my_module_42']);

Contenu privé et hole punching

Les pages servies depuis le FPC ne peuvent pas contenir de contenu spécifique au client — le même HTML mis en cache doit convenir à tous les visiteurs. Magento résout ce problème avec le contenu privé et le hole punching.

Le contenu privé est chargé de manière asynchrone via AJAX après le chargement de la page. Les données client (panier, liste de souhaits, produits à comparer) sont récupérées depuis /customer/section/load et injectées dans le DOM par Magento_Customer/js/section-config et Magento_Customer/js/customer-data.

Le hole punching est géré automatiquement par le drapeau $_isScopePrivate de Magento. Les blocs marqués comme privés sont exclus du FPC et rendus dynamiquement :

protected $_isScopePrivate = true;

Sections client dans etc/sections.xml :

<config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:noNamespaceSchemaLocation="urn:magento:module:Magento_Customer:etc/sections.xsd">
    <action name="checkout/cart/add">
        <section name="cart"/>
    </action>
</config>

Cela indique à Magento d’actualiser la section client cart après l’ajout d’un produit — garantissant que le mini-panier se met à jour sans invalider le cache de page complète.

Indexeurs liés au cache et leur impact

Les indexeurs et les caches sont étroitement liés. Les indexeurs précalculent les données que la couche de cache stocke ensuite pour une récupération rapide :

Lorsqu’un indexeur s’exécute (via bin/magento indexer:reindex), les étiquettes de cache associées sont automatiquement invalidées. C’est pourquoi la réindexation déclenche un nettoyage du cache — mais uniquement pour les entités concernées, pas tout le pool de cache.

Pièges courants du cache en production

1. Ne pas séparer les bases de données Redis. Sessions, cache par défaut et cache de page sur la même base de données Redis provoque une pression d’éviction et un mélange de données.

2. Varnish sans vérifications de santé appropriées. Si le backend Magento tombe, Varnish devrait servir du contenu obsolète au lieu de renvoyer des erreurs. Configurez le mode grace dans VCL.

3. Sur-invalidation. Les modules qui vident tous les caches au lieu d’utiliser un nettoyage ciblé par étiquette dégradent considérablement les taux de hit du cache.

4. Désactiver le cache pendant le développement et oublier de le réactiver. Une boutique fonctionnant avec les caches désactivés en production sera 10 à 50 fois plus lente.

5. Servir des données client depuis le FPC. Ne marquez jamais les blocs comme non privés s’ils contiennent des données spécifiques à l’utilisateur — cela met en cache les données d’un client et les sert à d’autres.

6. Ignorer l’éviction du backend de cache. Surveillez maxmemory et evicted_keys de Redis. Si Redis manque de mémoire, il évince les entrées de cache (y compris les sessions actives).

FAQ

Q : Quelle est la configuration de cache la plus rapide pour Magento 2 ?
Varnish comme FPC avec Redis pour les sessions, le cache par défaut et le stockage du cache de page. Bases de données Redis séparées pour chacun. Base de données 0 pour les sessions, 1 pour le cache par défaut, 2 pour le cache de page.

Q : Comment vérifier le taux de hit du cache Varnish en production ?
Exécutez varnishstat -1 -f MAIN.cache_hit,MAIN.cache_miss. Un taux de hit inférieur à 85% indique une mauvaise configuration.

Q : Redis persiste-t-il les données de cache entre les redémarrages ?
Uniquement si configuré avec des directives save (instantanés RDB) ou une persistance AOF. Par défaut, les données de cache Redis sont éphémères et ne survivent aux redémarrages que si la persistance est activée.

Q : Dois-je utiliser cache:clean ou cache:flush lors du déploiement ?
cache:clean est plus sûr — il ne vide que les entrées de cache invalidées. cache:flush supprime tout, y compris les entrées valides, provoquant un cache froid et des requêtes initiales lentes après le déploiement.

Q : Comment déboguer quelle étiquette de cache est invalidée ?
Activez la journalisation de débogage du cache dans app/etc/di.xml ou utilisez un outil de surveillance comme New Relic pour suivre les modèles d’invalidation du cache.

Besoin d’aide pour régler votre pile de cache Magento 2 ? Découvrez mon service d’optimisation des performances et mon service d’optimisation VPS . Lisez aussi à propos des indexeurs Magento 2 et des Core Web Vitals pour une vision complète des performances.