CDN pour Shopware 6 : quoi mettre en cache, quoi exclure

Un CDN devant Shopware 6 est rentable à deux endroits : les fichiers statiques comme le CSS du thème, le JavaScript et les images produits, qui peuvent rester longtemps en edge, et les pages HTML des invités dans l’état par défaut de Shopware, qui exigent des durées de vie courtes et un plan de purge. Tout ce qui est personnel, du panier et de la commande aux pages de compte, en passant par les clients connectés et les invités qui ont changé de devise, doit aller directement à votre serveur Shopware. Ce guide montre où tracer cette limite, comment purger et comment tester.

L’optimisation de la boutique elle-même (cache HTTP, workers, OPcache, imports) est traitée dans notre guide de performance Shopware 6. Ici, nous nous concentrons sur la couche placée devant.

CDN de ressources ou CDN de site complet

CDN de ressources. Shopware peut générer les URL des fichiers publics sur un nom d’hôte séparé. Dans la configuration du système de fichiers (en anglais), vous définissez une url pour le système de fichiers public, et les systèmes de fichiers du thème, des ressources et du sitemap en héritent par défaut. Cela ne change que les URL dans la page. Le CDN continue de récupérer les fichiers sur votre serveur ou votre bucket, et chaque requête HTML atteint toujours Shopware.

CDN de site complet. Tout le domaine passe par le CDN, mis en place via les serveurs de noms ou le DNS selon le fournisseur. L’edge voit chaque requête, HTML compris, et peut filtrer le trafic malveillant avant qu’il n’atteigne votre serveur. Le gain est plus important, la responsabilité aussi : le CDN doit savoir exactement quelles réponses il a le droit de stocker.

Les fichiers statiques sont la partie facile

Les fichiers de thème compilés se prêtent à de longues durées de vie en edge : à chaque compilation, Shopware écrit le CSS et le JavaScript dans un nouveau dossier sous theme/, nommé avec un nouveau hash, donc les URL changent. Les images produits et les miniatures changent rarement et représentent souvent l’essentiel des octets d’une page. Notre guide pour optimiser les images pour le web traite des formats et des dimensions.

L’exception, c’est un fichier remplacé sous la même URL, comme une image CMS dont le nom de fichier ne change pas. Purgez cette URL quand vous la remplacez.

Quelles pages Shopware peuvent être mises en cache sans risque

Shopware ne met pas en cache une seule et même page pour tout le monde. Selon la documentation sur le cache HTTP (en anglais), il pose un cookie sw-cache-hash dès que l’état d’un visiteur diffère de l’état par défaut, à savoir : aucun client connecté, la devise par défaut et un panier vide. Le hash encode l’état de connexion, la devise, le régime de taxe et les règles pertinentes pour le cache qui s’appliquent, et Shopware conserve une variante de cache distincte par hash. Les visiteurs dans l’état par défaut partagent une même variante.

Un CDN qui construit sa clé de cache uniquement sur l’URL ne sait rien de ces variantes. La règle pour le HTML est donc : ne mettez en cache que ce que voit un invité dans l’état par défaut, et envoyez chaque requête portant sw-cache-hash à Shopware.

Les prix par groupe de clients et les autres contenus pilotés par des règles se retrouvent aussi dans le hash, ces visiteurs ne doivent donc jamais recevoir la page par défaut en cache.

Respecter Cache-Control et les cookies

L’edge ne doit pas deviner ce qui est cachable, puisque Shopware le dit déjà. Avec le cache HTTP activé, les réponses cachables de la vitrine portent une durée de vie pour les caches partagés (s-maxage) ; la documentation sur le reverse proxy donne l’exemple Cache-Control: public, s-maxage=7200. Les réponses pour les clients connectés ou les paniers remplis ne reçoivent pas ces en-têtes.

Quel que soit votre CDN, deux règles s’appliquent :

1. Ne stockez que ce que Shopware marque comme public. Ne stockez jamais de réponses avec private, no-cache ou no-store, ni une réponse qui pose un cookie. Une règle générale « tout mettre en cache » écrase les décisions de Shopware, et c’est ainsi qu’un client finit par voir le panier d’un autre.
2. Contournez le cache edge pour les requêtes avec sw-cache-hash, ou intégrez ce cookie à la clé de cache. Si le CDN l’ignore, un invité qui a changé de devise peut recevoir depuis l’edge la page dans la devise par défaut. Pire, sa variante pourrait être stockée et servie à tous les autres.

Pour modifier les durées de vie, ajustez-les dans Shopware plutôt qu’en edge. Les versions récentes proposent des politiques de cache HTTP (en anglais) avec des directives comme s_maxage et stale_while_revalidate par zone ou par route. La documentation les indique comme expérimentales et prévues par défaut pour Shopware 6.8, vérifiez donc votre version.

Varnish, Fastly et un CDN générique

Shopware prend officiellement en charge deux reverse proxies : Varnish avec le module XKey et Fastly. Tous deux sont intégrés à son mécanisme d’invalidation : les réponses en cache portent des tags (surrogate keys) correspondant aux données qui ont servi à les construire, et quand vous modifiez un produit, Shopware envoie au proxy une requête d’invalidation pour exactement ces tags. Depuis Shopware 6.6, cela se configure sous shopware.http_cache.reverse_proxy. La documentation sur le reverse HTTP cache (en anglais) décrit la configuration complète.

Un CDN générique ne fait pas partie de cette boucle. L’invalidation par tags de Shopware atteint son propre cache et un reverse proxy configuré, mais pas un réseau edge qu’il ne connaît pas. Une page de catégorie en cache en edge y reste jusqu’à l’expiration de sa durée de vie ou jusqu’à ce que vous la purgiez.

Un proxy basé sur les tags offre une invalidation précise pour les grands catalogues qui évoluent vite, mais c’est un système de plus à exploiter. Un CDN générique de site complet s’ajoute plus simplement et apporte la diffusion en edge et la protection, mais la fraîcheur du HTML dépend de durées de vie courtes et de vos propres purges. Certaines boutiques combinent les deux.

Une stratégie de purge sans tags

Des durées de vie HTML courtes. Gardez le HTML des invités en edge pendant quelques minutes plutôt que quelques heures, tandis que les fichiers du thème et les images restent bien plus longtemps. Une copie edge obsolète disparaît alors au bout d’une durée de vie au maximum, même sans purge. Le cache intégré de Shopware absorbe les miss supplémentaires.

Des purges d’URL après les changements importants. Quand des soldes commencent, que les prix changent sur toute une catégorie ou que vous modifiez la navigation, purgez les URL concernées. Les changements visibles sur toutes les pages, comme le menu principal, le pied de page ou un thème recompilé, justifient une purge de tout le domaine, idéalement en dehors des heures de pointe.

Des purges depuis vos scripts. La plupart des CDN, fast.site compris, proposent une API de purge. Terminez votre import ERP ou de prix par un appel qui purge les URL modifiées, et faites purger votre pipeline de déploiement après theme:compile.

Vraies IP des clients et proxies de confiance

Derrière un CDN, chaque requête arrive chez Shopware depuis un serveur edge. La vraie IP du visiteur voyage dans un en-tête comme X-Forwarded-For, que Symfony ne lit que pour les proxies auxquels vous faites confiance via SYMFONY_TRUSTED_PROXIES dans votre .env (le nom de la variable depuis Shopware 6.6). Si vous enchaînez un CDN et Varnish, faites confiance aux deux étapes.

Cela dépasse la question des journaux. Les plugins de paiement et de détection de fraude vérifient souvent l’IP du client, et les limiteurs de débit de Shopware pour la connexion, la réinitialisation du mot de passe et le formulaire de contact perdent en précision quand toutes les requêtes semblent venir de quelques adresses.

Comment tester votre configuration CDN Shopware

1. Requête invité, deux fois. La deuxième requête doit venir de l’edge :

curl -sI https://shop.example.com/some-category/ | grep -iE 'cache-control|fs-cache|age|set-cookie'
curl -sI https://shop.example.com/some-category/ | grep -iE 'cache-control|fs-cache|age|set-cookie'

Sur fast.site, cherchez fs-cache: HIT et un fs-cache-age qui augmente (voir vérifier le cache). Les autres CDN envoient généralement un en-tête Age et leur propre en-tête de statut. Si la page ne devient jamais un HIT, comparez son en-tête Cache-Control avec les règles ci-dessus.

2. Routes personnelles. Vérifiez /checkout/cart et /account/login de la même manière. Elles ne doivent jamais afficher de HIT.

3. Une commande complète. Dans une fenêtre privée, ajoutez un produit, vérifiez que le compteur du panier se met à jour et finalisez la commande avec un moyen de paiement de test. Annulez ensuite la commande de test.

4. Client connecté. Connectez-vous avec un compte de test, idéalement un compte avec des prix par groupe de clients. Les pages doivent afficher les prix de ce client, et la vue invité doit revenir après la déconnexion.

5. Changement de devise. En tant qu’invité, passez à une deuxième devise et parcourez quelques catégories. Ouvrez ensuite les mêmes pages dans une nouvelle fenêtre privée : elles doivent afficher la devise par défaut. Répétez dans l’ordre inverse. Ce test révèle un CDN qui ignore sw-cache-hash.

Avec plusieurs canaux de vente ou plusieurs langues, répétez les étapes 1 et 5 pour chaque domaine. Pour la vitesse, comparez avant et après les données d’utilisateurs réels et un test en laboratoire sur corewebvitals.page, comme décrit dans le guide pour mesurer correctement la vitesse d’un site.

Comment fast.site vous aide

fast.site est une couche edge de site complet placée devant votre hébergement Shopware existant. Vous gardez votre hébergeur, ajoutez le domaine dans le tableau de bord et faites pointer ses serveurs de noms vers fast.site ; notre checklist serveurs de noms vous aide à conserver intacts vos enregistrements DNS et votre messagerie.

Fast Edge Cache™ respecte les en-têtes Cache-Control envoyés par votre boutique. Les réponses privées et dynamiques comme le panier, la commande et les sessions connectées affichent fs-cache: BYPASS, vous pouvez donc appliquer directement le plan de test ci-dessus. fast.site ne reçoit pas les invalidations par tags de Shopware. À la place, vous purgez des URL individuelles ou tout le domaine dans le tableau de bord, avec un journal des purges, ou via l’API depuis vos scripts d’import et de déploiement. Le préchauffage du cache garde les pages importantes prêtes.

Les images sont converties à la volée en WebP (AVIF selon votre offre), les fichiers texte sont compressés avec Brotli, et la détection DDoS de couche 7, la limitation de débit et les règles anti-bots filtrent le trafic en edge. La page Shopware donne tous les détails.

Mesurez le résultat sur votre propre boutique, avec les mêmes pages avant et après. Vous pouvez commencer avec un essai gratuit de 7 jours, sans carte bancaire.

Questions fréquentes

Shopware 6 a-t-il un CDN intégré ?

Non. Shopware dispose d’un cache HTTP intégré sur votre serveur, et vous pouvez définir une URL séparée pour les fichiers publics afin qu’ils se chargent depuis le nom d’hôte d’un CDN. Comme reverse proxies, Shopware intègre officiellement Varnish avec XKey et Fastly.

Peut-on mettre en cache les pages HTML de Shopware sur un CDN ?

Oui, pour les invités dans l’état par défaut : non connectés, devise par défaut, panier vide. Le CDN doit respecter les en-têtes Cache-Control de Shopware, contourner les requêtes portant le cookie sw-cache-hash et ne jamais mettre en cache le panier, la commande ou les pages de compte.

Pourquoi le panier ou le prix semble-t-il faux après l’ajout d’un CDN ?

En général, l’edge met en cache quelque chose de personnel : une réponse qui pose un cookie, une page demandée avec sw-cache-hash, ou une route de commande capturée par une règle « tout mettre en cache ». Supprimez la règle, purgez le domaine et refaites les tests.

Le cache HTTP de Shopware reste-t-il nécessaire derrière un CDN ?

Oui. Chaque miss en edge et chaque requête avec un cookie sw-cache-hash arrive sur votre serveur. Le cache intégré garde ces requêtes rapides, et des durées de vie courtes en edge ne fonctionnent bien qu’avec une origine rapide.

Comment vider le cache du CDN après des modifications dans Shopware ?

Les commandes bin/console cache:clear et cache:clear:http de Shopware n’atteignent pas un CDN générique. Purgez les URL concernées ou tout le domaine dans le tableau de bord du CDN, ou via son API depuis le script qui a effectué la modification.