Performances Magento 2 : Redis, Varnish et OPcache en pratique

Une boutique Magento lente, c’est des clients qui partent avant d’avoir commandé. Les études sont unanimes : au-delà de 3 secondes de chargement, plus de la moitié des visiteurs abandonnent. Et pourtant, la plupart des problèmes de performance sur Magento ont une solution connue, éprouvée et relativement simple à mettre en place : une stack cache correctement configurée.

Redis, Varnish, OPcache — ces trois outils forment le triptyque de performance de toute boutique Magento sérieuse. Voici comment ils fonctionnent, comment les configurer, et comment mesurer les gains.

Comment Magento gère le cache — vue d’ensemble

Avant de plonger dans la configuration, il faut comprendre qu’il existe plusieurs niveaux de cache dans Magento, chacun ayant un rôle différent. Les confondre, c’est souvent la source de configurations sous-optimales.

Les trois niveaux de cache sur Magento 2

Varnish

Cache Full-Page

Intercepte les requêtes HTTP avant PHP — pages servies en < 50ms sans toucher PHP

Impact : très fort

Redis

Cache applicatif

Config, layout, blocs, sessions clients — réduit les requêtes MySQL de 60 à 80%

Impact : fort

OPcache

Cache PHP bytecode

Compile les fichiers PHP une seule fois en mémoire — réduit le CPU PHP de 30 à 50%

Impact : fort

Les trois niveaux de cache Magento — chacun agit à un niveau différent de la stack

Varnish — le cache full-page qui fait la vraie différence

Varnish est un serveur de cache HTTP qui se place devant votre serveur web. Quand un visiteur arrive sur une page de votre boutique, Varnish vérifie si cette page est en cache. Si oui, il la renvoie directement — sans que PHP, Magento ou MySQL aient à faire quoi que ce soit. Le temps de réponse passe de plusieurs secondes à quelques dizaines de millisecondes.

C’est de loin la configuration qui a le plus d’impact sur la performance perçue par vos clients. Une boutique Magento sans Varnish en production, c’est comme rouler sur autoroute en première.

Pour activer Varnish sur Magento, la configuration se fait dans Stores → Configuration → Advanced → System → Full Page Cache. Sélectionnez « Varnish Cache » comme moteur, renseignez l’adresse et le port de votre serveur Varnish, et générez le fichier VCL depuis l’interface admin — Magento le génère automatiquement selon votre configuration.

# Vérifier que Varnish est actif et répond
varnishstat -1 | grep cache_hit
# Un ratio cache_hit / cache_miss > 80% est un bon indicateur

Un point important : Varnish ne cache que les pages accessibles sans authentification. Les pages de compte client, le panier et le checkout sont toujours servis par PHP — c’est le comportement normal et attendu.

Redis — le cache applicatif qui soulage votre base de données

Redis est une base de données en mémoire ultra-rapide. Sur Magento, il joue deux rôles distincts qu’il faut configurer séparément : le cache applicatif (configuration, blocs, layout) et le stockage des sessions clients.

Sans Redis, Magento stocke son cache dans des fichiers sur le disque — ce qui est lent et peu efficace sur un catalogue volumineux. Avec Redis, les données fréquemment accédées sont en RAM, réduisant drastiquement les requêtes vers MySQL.

La configuration se fait dans le fichier app/etc/env.php de votre installation Magento :

'cache' => [
    'frontend' => [
        'default' => [
            'backend' => 'Magento\Framework\Cache\Backend\Redis',
            'backend_options' => [
                'server' => '127.0.0.1',
                'port' => '6379',
                'database' => '0',
            ],
        ],
        'page_cache' => [
            'backend' => 'Magento\Framework\Cache\Backend\Redis',
            'backend_options' => [
                'server' => '127.0.0.1',
                'port' => '6379',
                'database' => '1',
            ],
        ],
    ],
],
'session' => [
    'save' => 'redis',
    'redis' => [
        'host' => '127.0.0.1',
        'port' => '6379',
        'database' => '2',
    ],
],

Notez l’utilisation de trois bases Redis différentes (database 0, 1 et 2) pour séparer le cache applicatif, le cache full-page et les sessions. C’est une bonne pratique qui évite les collisions et facilite le diagnostic.

OPcache — le booster PHP invisible

PHP compile vos fichiers source en bytecode à chaque exécution — ou du moins, c’est ce qu’il fait sans OPcache. OPcache garde ce bytecode en mémoire après la première compilation. Résultat : les requêtes suivantes sont servies sans recompilation, ce qui réduit significativement la charge CPU.

OPcache est intégré à PHP depuis la version 5.5 — pas besoin de l’installer. Il suffit de le configurer correctement dans votre php.ini ou dans le fichier de configuration de votre pool PHP-FPM :

opcache.enable=1
opcache.memory_consumption=512
opcache.interned_strings_buffer=64
opcache.max_accelerated_files=60000
opcache.revalidate_freq=0
opcache.save_comments=1
opcache.enable_cli=0

Le paramètre opcache.memory_consumption=512 alloue 512 Mo à OPcache — une valeur adaptée à une boutique Magento standard. Sur un catalogue très large avec de nombreuses extensions, 512 Mo peut ne pas suffire et mérite d’être augmenté. La valeur opcache.max_accelerated_files=60000 couvre la grande majorité des installations Magento.

Comment mesurer les gains ?

Avant de toucher quoi que ce soit, mesurez votre baseline. L’outil de référence est PageSpeed Insights (pagespeed.web.dev) — il vous donne les Core Web Vitals réels (LCP, INP, CLS) mesurés sur de vrais utilisateurs, et les métriques lab pour diagnostiquer les problèmes.

Gains typiques observés après optimisation cache

TTFB

-80%

Temps avant premier octet — 2s → 50-200ms avec Varnish actif

Charge MySQL

-70%

Requêtes en base avec Redis activé sur catalogue standard

CPU PHP

-40%

Consommation CPU avec OPcache bien dimensionné

Gains indicatifs — les résultats varient selon l’infrastructure et le catalogue

Les erreurs de configuration les plus fréquentes

Varnish configuré mais non utilisé

C’est plus courant qu’on ne le pense : Varnish est installé, Magento est configuré pour l’utiliser, mais le trafic ne passe pas réellement par Varnish. La cause la plus fréquente est une mauvaise configuration des headers X-Forwarded-Proto ou des trusted_proxies dans env.php — Magento ne reconnaît pas les requêtes comme venant de Varnish et génère un bypass. Résultat : performance dégradée et cache jamais utilisé.

Redis saturé faute de politique d’éviction

Redis stocke tout en RAM. Sans politique d’éviction configurée, il finit par saturer et commence à rejeter les écritures — ce qui se manifeste par des erreurs inexpliquées et un Magento qui ralentit brusquement. Configurez toujours maxmemory-policy allkeys-lru dans votre redis.conf pour que Redis supprime automatiquement les entrées les moins récentes quand il approche de sa limite.

OPcache vidé automatiquement trop souvent

Le paramètre opcache.revalidate_freq=0 désactive la revalidation automatique des fichiers en production — PHP ne vérifie plus si les fichiers source ont changé. C’est optimal en production (les fichiers ne changent pas entre deux déploiements), mais attention : il faudra vider manuellement l’OPcache après chaque déploiement, sinon PHP continue d’exécuter l’ancien code.

FAQ

Mon hébergeur mutualisé supporte-t-il ces configurations ?

Rarement. Varnish nécessite un serveur dédié ou un VPS avec accès root. Redis est parfois disponible en option sur certains hébergeurs managés. OPcache est généralement activé par défaut mais avec des paramètres peu adaptés à Magento. Si votre boutique génère un chiffre d’affaires significatif, un serveur dédié ou un VPS bien configuré est indispensable.

Faut-il tout configurer en même temps ?

Non — et c’est même déconseillé. Commencez par OPcache (le plus simple, souvent déjà actif), puis Redis, puis Varnish. Cette progression vous permet de mesurer l’impact de chaque composant séparément et de diagnostiquer plus facilement si quelque chose se passe mal.