Performance de Shopware 6 : cache HTTP, CDN et pièges courants

Une boutique Shopware 6 lente est rarement un mystère. Dans la plupart des cas, le cache HTTP est désactivé ou invalidé en permanence, les tâches de fond s’exécutent au mauvais endroit, ou le serveur refait à chaque requête un travail coûteux qu’il pourrait éviter. Ce guide explique comment fonctionne le cache HTTP de Shopware 6, comment le vérifier, où un CDN aide et quelles erreurs de configuration reviennent le plus souvent.

Comment fonctionne le cache HTTP de Shopware 6

Shopware 6 intègre un cache de pages complètes pour la vitrine (storefront). Lorsqu’il est activé, la première requête vers une page (par exemple une catégorie ou une fiche produit) est générée par PHP puis stockée, et les requêtes suivantes pour la même page reçoivent la copie stockée sans relancer toute l’application. C’est de loin le levier le plus puissant pour la vitesse de la boutique.

Plusieurs points déterminent son efficacité :

• Il doit être activé. Le cache est piloté par la variable d’environnement SHOPWARE_HTTP_CACHE_ENABLED=1, généralement définie dans .env.local.
• Stockage. Par défaut, le cache se trouve sur le système de fichiers, sous var/cache. Cela suffit pour un seul serveur. Avec plusieurs serveurs d’application, la documentation Shopware sur les caches (en anglais) recommande un cache partagé comme Redis.
• Variantes par contexte. Une page peut changer selon que le visiteur est connecté ou non, selon la devise, le régime de taxe ou les règles de prix qui s’appliquent. Shopware résume tout cela dans le cookie sw-cache-hash et stocke une variante distincte par valeur de hash, pour qu’un client ne voie jamais les prix d’un autre. Les visiteurs dans l’état par défaut (non connectés, devise par défaut, panier vide) partagent les mêmes pages en cache.
• Invalidation par tags. Les réponses en cache portent des tags correspondant aux données qui ont servi à les construire. Quand vous modifiez un produit, Shopware supprime les pages en cache portant son tag au lieu de tout effacer. Les routes de type liste, comme les listes de produits, les listes de catégories et les résultats de recherche, ne sont pas taguées avec chaque entité qu’elles renvoient et dépendent plutôt de leur durée de cache : une modification peut donc mettre un moment à y apparaître.

Cache intégré ou reverse proxy

Pour les boutiques plus importantes, Shopware prend en charge un reverse proxy externe, à savoir Varnish avec le module XKey ou Fastly. Le proxy stocke les pages et Shopware lui envoie des requêtes d’invalidation avec les tags concernés. Depuis Shopware 6.6, cela se configure sous shopware.http_cache.reverse_proxy (les versions plus anciennes utilisent storefront.reverse_proxy), et vous définissez SYMFONY_TRUSTED_PROXIES pour que l’application voie les vraies adresses IP des clients. La documentation sur le reverse HTTP cache (en anglais) décrit la configuration complète.

Un reverse proxy décharge totalement PHP pour les hits en cache, ce qui compte aux heures de pointe. C’est aussi un composant de plus à exploiter et à surveiller. Pour beaucoup de petites et moyennes boutiques, le cache intégré avec Redis suffit.

Vérifier que le cache fonctionne

Avant de modifier quoi que ce soit, regardez ce qui se passe réellement. Ouvrez deux fois une page de catégorie dans une fenêtre privée et comparez les temps de réponse dans l’onglet Réseau de votre navigateur. Un cache fonctionnel montre une nette baisse à la deuxième requête. En ligne de commande :

curl -s -o /dev/null -w "TTFB: %{time_starttransfer}s\n" https://shop.example.com/some-category/
curl -s -o /dev/null -w "TTFB: %{time_starttransfer}s\n" https://shop.example.com/some-category/
curl -sI https://shop.example.com/some-category/ | grep -i cache-control

Si les deux requêtes sont aussi lentes l’une que l’autre, le cache est soit désactivé, soit contourné par un cookie, soit invalidé entre les deux requêtes. Vérifiez aussi l’en-tête Cache-Control. Il indique à tout proxy ou CDN placé devant Shopware s’il a le droit de stocker la page.

Pour une comparaison avant/après structurée, le TTFB (en anglais) est la métrique à suivre côté serveur. Notre guide pour réduire le TTFB approfondit les aspects serveur et application.

Les pièges de configuration courants

Voici les problèmes qui expliquent le plus souvent une boutique Shopware 6 poussive.

Mode dev ou débogage activé

APP_ENV=dev active le profiler et des fonctions de débogage qui ralentissent chaque requête. Une boutique en production a besoin de APP_ENV=prod. Réglez aussi le niveau de journalisation sur error ou équivalent en production, car une journalisation verbeuse écrit à chaque requête.

L’admin worker traite les tâches de fond

Par défaut, Shopware peut traiter les messages en file d’attente (indexation, e-mails, imports) via l’administration tant qu’un utilisateur a le back-office ouvert. C’est pratique en développement, mais en production cela rend les tâches de fond imprévisibles et charge le serveur web. La documentation sur la file de messages (en anglais) est claire : en production, traitez la file via la CLI. Définissez shopware.admin_worker.enable_admin_worker: false dans config/packages/shopware.yaml et lancez bin/console messenger:consume async comme processus d’arrière-plan maintenu actif par systemd ou supervisor, ainsi que bin/console scheduled-task:run pour les tâches planifiées.

Tempêtes d’invalidation du cache

Les synchronisations ERP, les mises à jour de stock et les imports de prix touchent de nombreux produits à la fois. Chaque modification invalide des pages en cache, si bien qu’un import qui tourne toutes les quelques minutes peut garder votre cache presque constamment vide. Les solutions : regrouper les imports en moins d’exécutions, n’écrire que les champs qui ont réellement changé et utiliser l’invalidation différée. Shopware collecte alors les tags à invalider et les traite plus tard dans une tâche de fond. Par défaut, cette liste est stockée dans la base de données ; la documentation sur les optimisations de performance (en anglais) recommande Redis comme stockage partout où c’est possible.

Des extensions qui cassent le cache

Les plugins peuvent poser des cookies, ajouter des blocs personnalisés ou modifier le contexte à chaque requête. Chacun de ces comportements peut produire une variante de cache distincte par visiteur, ce qui revient à ne plus avoir de cache du tout. Si votre taux de hits s’est effondré après l’installation d’une extension, testez sans elle sur une copie de préproduction.

Recherche MySQL sur un gros catalogue

Sur les catalogues volumineux, la recherche de produits et les listes filtrées coûtent cher à MySQL. Shopware prend en charge Elasticsearch ou OpenSearch pour la recherche et les listes de la vitrine. Les résultats de recherche ne sont généralement pas mis en cache en page complète, ce qui touche directement les pages où les utilisateurs saisissent et filtrent.

PHP et OPcache

Assurez-vous qu’OPcache est activé et dimensionné pour la base de code de Shopware. En production, opcache.validate_timestamps=0 évite les vérifications de fichiers à chaque requête (vous devez alors réinitialiser OPcache à chaque déploiement). Utilisez une version récente de PHP prise en charge par votre version de Shopware.

Images et ressources du thème trop lourdes

Des images produits sorties directement de l’appareil photo, des miniatures manquantes ou d’immenses bannières d’accueil pénalisent le Largest Contentful Paint (en anglais). Laissez Shopware générer les miniatures, importez des images aux dimensions raisonnables et envisagez des formats modernes. Notre guide pour optimiser les images pour le web entre dans les détails.

Où un CDN aide, et où il n’aide pas

Un CDN se place entre vos visiteurs et votre serveur Shopware et sert le contenu depuis des emplacements plus proches d’eux.

Ce qu’un CDN ne corrige pas : les requêtes lentes non mises en cache. Si la commande prend plusieurs secondes à cause d’un plugin de paiement lent ou d’une base de données surchargée, le CDN transmet ce délai tel quel. Corrigez d’abord l’origine, puis ajoutez la couche edge.

Un ordre de travail raisonnable

1. Passez en APP_ENV=prod, réduisez la journalisation, vérifiez OPcache.
2. Activez le cache HTTP et confirmez qu’il fonctionne pour les invités.
3. Déplacez les tâches de fond vers des workers CLI et désactivez l’admin worker.
4. Maîtrisez les imports pour qu’ils ne vident pas le cache en permanence.
5. Ajoutez Redis (et, pour les grosses boutiques, OpenSearch) là où la charge l’exige.
6. Optimisez les images et les ressources du thème.
7. Placez une couche edge devant pour les ressources statiques, les pages invités et la protection.

Mesurez après chaque étape, idéalement avec les mêmes pages et les mêmes outils, pour savoir ce qui a réellement fait la différence. Si vous gérez aussi une boutique WooCommerce, les principes sont proches : voyez comment accélérer WooCommerce sans casser la commande.

Comment fast.site vous aide

fast.site se place devant votre hébergement Shopware existant. Vous gardez votre hébergeur et votre installation Shopware, vous ajoutez le domaine dans le tableau de bord et vous faites pointer les serveurs de noms de votre domaine vers fast.site.

Fast Edge Cache™ stocke les réponses publiques en edge. L’expiration suit les en-têtes Cache-Control envoyés par votre boutique ou les règles que vous définissez vous-même, et vous pouvez contrôler chaque réponse via l’en-tête fs-cache (HIT, MISS ou BYPASS). Le panier, la commande, le compte et les autres pages liées à une session contournent le cache, les commandes fonctionnent donc comme d’habitude. Après des modifications importantes du catalogue, vous pouvez purger des URL dans le tableau de bord ou via l’API, et le préchauffage du cache garde les pages importantes prêtes.

En plus, les images sont converties à la volée en WebP pour les navigateurs compatibles (AVIF selon votre offre), les ressources texte sont compressées avec Brotli, et la détection DDoS de couche 7, la limitation de débit et les règles anti-bots filtrent le trafic avant qu’il n’atteigne votre serveur. La page Shopware et l’article sur l’intégration Shopware détaillent la mise en place.

Le seul test honnête, c’est votre propre boutique : comparez le TTFB et les Core Web Vitals avant et après. Vous pouvez démarrer avec un essai gratuit de 7 jours, sans carte bancaire.

Questions fréquentes

Comment activer le cache HTTP dans Shopware 6 ?

Définissez SHOPWARE_HTTP_CACHE_ENABLED=1 dans votre .env.local, puis videz le cache. Vérifiez que la boutique tourne avec APP_ENV=prod. Ouvrez ensuite deux fois une page de catégorie en tant qu’invité et confirmez que la deuxième requête est nettement plus rapide.

Pourquoi ma boutique Shopware est-elle lente alors que le cache HTTP est activé ?

Les raisons courantes sont des invalidations fréquentes dues aux imports, des extensions qui posent des cookies ou personnalisent les pages, et des pages lentes non mises en cache comme la recherche, le panier et la commande. Vérifiez que les pages invités sont vraiment servies depuis le cache, puis examinez ce qui s’exécute sur les requêtes non mises en cache.

Faut-il Varnish pour Shopware 6 ?

Pas forcément. Le cache intégré suffit pour beaucoup de boutiques, surtout avec Redis comme stockage. Varnish ou un autre reverse proxy devient rentable avec plusieurs serveurs d’application ou beaucoup de trafic, mais il ajoute une infrastructure à exploiter.

Peut-on utiliser un CDN avec Shopware 6 ?

Oui. Les ressources statiques et les images se servent facilement depuis un CDN. Les pages HTML pour invités peuvent aussi être mises en cache, à condition que le CDN respecte les en-têtes de cache de Shopware, contourne le panier, la commande et le compte, et que vous disposiez d’un moyen de purger après les modifications.

Comment vider le cache de Shopware ?

Dans une boutique auto-hébergée, ouvrez Settings > System > Caches & Indexes dans l’administration (libellés de l’interface anglaise) et utilisez Clear cache, ou lancez bin/console cache:clear en ligne de commande. Si vous utilisez un reverse proxy, bin/console cache:clear:http (disponible depuis Shopware 6.6.10) vide ce cache. Tout vider signifie souvent que les visiteurs suivants tombent sur un cache froid, faites-le donc en dehors des heures de pointe.