Plongée dans le cache serveur de Shopify

Pour notre thème Shopify, nous avions besoin de comprendre comment fonctionne le cache de Shopify afin de proposer des options pertinentes. Par exemple, nous souhaitons ajouter une option de date d’affichage sur les sections (ex : afficher une section pour le début du blackfriday, des soldes à partir d’une certaine date etc…).
Bien entendu il existe des app pour gérer cela, mais encore une fois, l’objectif est de minimiser l’utilisations d’app pour des fonctionnalités que l’on considère comme basiques et pour

Pour les développeurs travaillant sur des thèmes Liquid, le cache serveur de Shopify est souvent une « boîte noire » mystérieuse. Contrairement au cache navigateur (assets), le cache serveur concerne le rendu HTML de vos pages. C’est lui qui détermine le TTFB (Time To First Byte) et la réactivité de votre boutique.

Cet article se concentre exclusivement sur ce qui se passe côté serveur : comment Shopify génère, stocke et invalide le HTML de vos pages.

L’Architecture : Le Moteur de Rendu (Storefront Renderer)

Lorsque qu’un utilisateur demande une page, la requête atteint le « Storefront Renderer » de Shopify. C’est ici que la magie (et le cache) opère via une architecture à plusieurs niveaux.

1. Full-Page Caching (Redis)

C’est le niveau le plus critique. Une fois que Shopify a calculé le Liquid d’une page (ex: une fiche produit complexe), il stocke le résultat HTML final dans un cache Redis.

Fonctionnement : Si une requête suivante correspond exactement à la même clé de cache, Shopify sert le HTML directement depuis Redis.
Gain : Le moteur Liquid n’est pas sollicité, aucune requête SQL n’est faite. La réponse est quasi-instantanée.

2. Liquid Object Memoizer

Même si la page n’est pas entièrement en cache (premier chargement ou cache expiré), Shopify optimise le rendu.

Principe : si votre code Liquid appelle product.variants à dix endroits différents de la page, Shopify ne fait la requête en base de données qu’une seule fois
Portée : ce cache est temporaire et ne vit que le temps de la génération de la page (Request-scoped), mais il est crucial pour les thèmes complexes

La Clé de Cache (Cache Key) : L’ADN de la Requête

Pour que le Full-Page Caching fonctionne, Shopify doit identifier de manière unique chaque version d’une page. Il construit pour cela une « Clé de Cache » composite (hash MD5).

Si un seul de ces éléments change, le cache est « manqué » (MISS) et la page est régénérée :

L’URL Exacte : /products/mon-produit est différent de /products/mon-produit?ref=email. Les paramètres de requête (Query Parameters) font partie intégrante de la clé.
Le Device : Shopify peut servir une version différente du HTML selon que l’User-Agent est mobile ou desktop (si le thème le gère).
Le Contexte de Session (Cookies) :
- Devise (cart_currency) : un utilisateur en EUR ne verra pas la page cachée d’un utilisateur en USD
- Langue (localization) : indispensable pour les boutiques multilingues
- Pays : Pour les règles de prix ou de taxes spécifiques au pays
- Customer Segment : si l’utilisateur est connecté, la clé de cache change pour permettre l’affichage de contenus personnalisés (ex: prix B2B)

Invalidation et Durée de Vie (TTL)

C’est ici que réside la principale frustration des développeurs : le manque de contrôle explicite.

Durée de vie (TTL – Time To Live)

Standard : le cache serveur pour une page dynamique a généralement un TTL court, autour de 5 minutes (300 secondes).
Persistance : si aucune modification n’est détectée sur la boutique, ce cache peut persister beaucoup plus longtemps (observé jusqu’à 30 heures)
Pas de contrôle manuel : Il n’existe aucune balise Liquid pour définir un TTL spécifique (ex: {% cache_for 1h %} n’existe pas)

Mécanismes d’Invalidation Automatique

Shopify invalide le cache de manière intelligente et événementielle (« Event-based invalidation ») :

Mise à jour Produit : sauvegarder un produit dans l’admin invalide instantanément le cache de sa page produit et des collections où il apparaît
Changement Global : modifier les paramètres de taxes, de livraison, ou le fichier settings_data.json du thème invalide le cache de toute la boutique
Mise à jour du Thème : modifier n’importe quel fichier .liquid invalide le cache du thème actif

Stratégies pour les Développeurs

Puisque nous ne pouvons pas configurer le cache serveur, nous devons composer avec lui.

1. Gérer le Contenu Dynamique

Si vous avez besoin d’afficher un contenu qui change à chaque seconde (ex: un compte à rebours précis) ou qui est unique à l’utilisateur sans casser le cache global :

Section Rendering API : chargez le HTML de la section via une requête AJAX (fetch('/?section_id=...'))
Web Components / JS : récupérez les données via l’API Storefront ou une API tierce et injectez-les dans le DOM

2. Tester sans Cache

Pour vérifier vos modifications sans attendre l’expiration du cache serveur, l’astuce la plus fiable est de modifier la clé de cache :

Ajoutez un paramètre unique à l’URL : ?v=dev1, ?timestamp=123.
Cela force Shopify à générer une nouvelle entrée de cache pour cette URL spécifique.

3. Attention aux Query Parameters

Puisque l’URL fait partie de la clé de cache, des campagnes marketing avec des UTMs uniques (?utm_source=...) génèrent chacune leur propre cache. Cela peut réduire l’efficacité du cache (Cache Hit Ratio) lors de gros lancements.

Dans un prochain article, nous vous expliquerons comment invalider le cache Shopify sans app (gratuitement)

Sources

Shopify Engineering : « How Shopify Reduced Storefront Response Times » (Architecture Redis & Memoizer).
Shopify Dev Docs : Documentation sur les contextes de requête et le rendu.