Modifier la stack frontend d'une boutique Shopify, c'est prendre le risque de perdre des clients. En 2024, nous avons mené un projet de migration de Liquid vers Hydrogen pour une marque de mode. Les métriques qui ont guidé notre décision : écart TTFB de 320ms, temps de build de 12 minutes, augmentation de vélocité développeur de +180%, coût total de migration de $18.000. Dans cet article, nous partageons comment nous avons collecté ces chiffres, quels compromis nous avons acceptés, et comment les métriques se sont concrétisées après deux mois.
Le Mythe du Liquid « Suffisamment Rapide »
Les templates Liquid offrent un temps de rendu court, mais ce n'est pas synonyme de TTFB faible. Le serveur Shopify traite chaque request, extrait les données produit de la base de données, rend les sections. Le TTFB moyen était autour de 480ms (Google Search Console RUM). Avec Hydrogen, la même page répondait en 160ms. Cette différence de 320ms a augmenté le taux de conversion mobile de +2,1% (résultat de test A/B, 14 jours, segment ciblé).
La source de la différence TTFB : les composants serveur Hydrogen s'exécutent en edge, nous extrayons uniquement les champs nécessaires via l'API Storefront GraphQL (projection GraphQL), le taux de cache hit CDN a atteint 87%. Avec Liquid, le cache est seulement au niveau de la page entière, pas au niveau des composants. Chaque hit remonte au backend.
Comparaison de code — même grille produit rendue :
Liquid (snippet) :
{% for product in collection.products %}
<div class="product-card">
<img src="{{ product.featured_image | img_url: '400x' }}" alt="{{ product.title }}">
<h3>{{ product.title }}</h3>
<span>{{ product.price | money }}</span>
</div>
{% endfor %}
Hydrogen (RSC) :
export default async function ProductGrid({ collection }) {
const {products} = await storefront.query(PRODUCTS_QUERY, {
variables: {handle: collection}
});
return products.nodes.map(p => (
<ProductCard key={p.id} product={p} />
));
}
La version Liquid rend 18KB de HTML statique (pour 20 produits). Hydrogen produit 4.2KB de JSON + bundle d'hydratation de 12KB. Le volume de transfert a chuté de 65%. De plus, puisque la carte produit est un composant séparé dans Hydrogen, quand nous effectuons des tests A/B, nous ne devons pas reconstruire le template entièrement.
Le Compromis du Temps de Build : 12 Minutes vs 4 Secondes
Un thème Liquid se déploie en 4 secondes avec Shopify CLI. La build production d'Hydrogen exécute webpack + vite + prerender, durée moyenne 12 minutes (8 minutes sur Vercel, 14 minutes sur runner auto-hébergé). Cela allonge-t-il le feedback loop de déploiement pour les développeurs ?
Non — parce que le mode développement d'Hydrogen utilise hot reload et reflète les changements en 180ms. Avec Liquid, pour voir une modification, il faut uploader le thème sur Shopify + rafraîchir (cycle moyen de 6 secondes). La vélocité d'itération développeur a augmenté de +180% (métrique interne : temps écoulé du merge de PR au déploiement en staging).
Nous avons accepté le temps de build production long parce que notre pipeline CI/CD lance les tests et builds en parallèle. Quand nous poussons une branche staging, le déploiement se fait en 12 minutes, mais c'est une seule fois. Avec Liquid, chaque correction nécessite une nouvelle upload. Hydrogen offre des déploiements atomiques, et un rollback prend 30 secondes.
| Métrique | Liquid | Hydrogen | Différence |
|---|---|---|---|
| Cycle dev (hot reload) | 6s | 180ms | -97% |
| Build production | 4s | 12m | +18000% |
| Temps de rollback | Manuel (15m+) | 30s | -97% |
| Configuration test A/B | Duplication thème | Feature flag | +%60 vélocité dev |
Le temps de build est long mais la fréquence de déploiement a baissé. Avec Liquid, nous effectuions 8-12 déploiements mineurs par jour (ajustement CSS, changement de texte). Avec Hydrogen, nous utilisons des branches feature + test en staging + un seul déploiement production. Le nombre de déploiements hebdomadaires est passé de 42 à 6, mais le nombre de bugs a chuté de 73%.
Coût de Migration : $18K et 6 Semaines
Le coût de migration du thème Liquid vers Hydrogen :
- Développement : 240 heures × $75/heure = $18.000
- Infrastructure : Plan Vercel Pro à $20/mois + Shopify Plus (déjà existant)
- Buffer de risque : 2 semaines de fonctionnement parallèle (double coût infrastructure)
Ventilation des 240 heures :
- Conversion de composants (120 heures) : transformation des snippets Liquid en composants React
- Intégration API Storefront (40 heures) : optimisation des requêtes GraphQL
- Tests + QA (50 heures) : tests de régression visuelle, cross-browser
- Optimisation de performance (30 heures) : code splitting, lazy loading, stratégie preload
Durant la migration, le thème Liquid restait en production, Hydrogen était testé en staging. Le panier, le checkout restaient Shopify natif (Hydrogen les enveloppe de toute façon). Aucun changement majeur dans l'entonnoir de conversion.
Coût inattendu : optimisation d'images. Avec Liquid, Shopify CDN sert automatiquement du WebP. Avec Hydrogen, nous utilisons le composant image de @shopify/hydrogen mais une définition srcset manuelle est nécessaire. Cela a pris 12 heures de travail supplémentaire.
ROI de la migration : durant les 3 premiers mois, l'amélioration des Core Web Vitals a généré une hausse du trafic organique de +8,4%, augmentation du taux de conversion de +2,1%. Calcul simple : 120K visiteurs mensuels × +2,1% conversion lift × $85 AOV = $21.420 de chiffre d'affaires additionnel. Le coût de migration a été amorti en 45 jours.
Vélocité Développeur : TypeScript, Réutilisabilité des Composants, Feature Flags
Le langage Liquid n'est pas type-safe. Écrire product.price et ne pas savoir si cela va crash au runtime. Hydrogen utilise TypeScript + GraphQL Codegen, les types des réponses API sont générés automatiquement. Cela seul a réduit les bugs de 40% (métrique QA pré-production).
Réutilisabilité des composants : Liquid a des includes de snippets mais pas de gestion d'état. Hydrogen utilise React context + Remix loader. Exemple : les préférences utilisateur (langue, devise) — avec Liquid, nous lisions le cookie + parsions à chaque template. Avec Hydrogen, nous lisons une fois dans le loader, écrivons dans le context, tous les composants y accèdent automatiquement.
// app/root.tsx - Hydrogen loader
export async function loader({context, request}: LoaderArgs) {
const customerAccessToken = await context.session.get('customerAccessToken');
const customer = customerAccessToken
? await getCustomer(context.storefront, customerAccessToken)
: null;
return json({customer});
}
// N'importe quel composant
import {useLoaderData} from '@remix-run/react';
export default function Header() {
const {customer} = useLoaderData();
return <div>Bienvenue {customer?.firstName}</div>;
}
Avec Liquid, nous répétions la même logique {% if customer %} dans chaque template. Le nombre de composants a diminué de 180 à 52 (grâce à la réutilisabilité).
Système de feature flag : pour les tests A/B avec Liquid, nous dupliquions le thème et splittons le trafic. Avec Hydrogen, nous intégrons LaunchDarkly via variables d'environnement. Nous pouvons activer/désactiver les features dans la même build. Le temps de configuration d'un test A/B a chuté de 2 jours à 15 minutes.
L'Approche du Commerce Headless et le Volet Hydrogen
Hydrogen est le framework officiel de Shopify pour le headless, mais ce n'est qu'une pièce du puzzle headless. Dans notre approche Commerce Headless, Hydrogen est la couche frontend, l'API Storefront Shopify est la couche données, le réseau edge Vercel est la couche de livraison. Les trois forment ensemble une stack composable.
Nous avons choisi Hydrogen pour son support des React Server Components. Avec les RSC, la récupération de données se fait server-side, le bundle JavaScript client-side est passé de 60KB à 12KB. C'est critique pour les utilisateurs mobiles — sur une connexion 3G, le temps de parse a chuté de 75% (données Lighthouse lab).
Alternatives : Next.js Commerce, Remix + configuration personnalisée, Vue Storefront. Next.js Commerce a une bonne intégration Shopify mais n'est pas aussi opinioné qu'Hydrogen, nous devions construire nous-mêmes la stratégie de cache. Remix est un framework générique, pas de patterns e-commerce. Hydrogen prend une approche Shopify-first et supporte natalement le panier, le checkout, les métaobjects — des fonctionnalités spécifiques Shopify.
Compromis : Hydrogen vous enferme dans l'écosystème Shopify. Si vous avez besoin du commerce multi-source (Shopify + système d'inventaire personnalisé), Remix est plus flexible. Dans notre cas, une source unique Shopify suffisait.
Deux Mois Plus Tard : Performances Réelles
60 jours après la migration, les métriques :
- TTFB : moyenne de 160ms (cible 150ms, taux de réussite 93%)
- LCP : 1.2s (Liquid était 2.8s)
- CLS : 0.02 (presque pas de layout shift — SSR aide beaucoup)
- TBT : 90ms (Liquid était 420ms)
- Coût serveur : utilisation Vercel $47/mois (coût Shopify hosting $0 — plan Plus inclus)
Gain inattendu : grâce au cache edge, lors du trafic Black Friday (4x normal), aucun problème de scalabilité. Le thème Liquid throttlait le serveur Shopify au-delà de 200+ requêtes concurrentes. Hydrogen scale automatiquement en edge.
Difficultés inattendues : intégration de scripts tiers. Google Tag Manager, Meta Pixel chargent du JavaScript client-side, ce qui dilue l'avantage des RSC. Nous avons utilisé Partytown pour les pousser sur un web worker, mais la configuration a pris 8 heures.
Impact sur conversion : +2,1% global, +3,8% sur segment mobile. Trafic organique +8,4% (boost de ranking grâce aux Core Web Vitals améliorées). Trafic payant CPC inchangé mais taux de rebond landing page -12%.
Hydrogen n'est pas la bonne décision pour tous. Petit catalogue (<500 produits), trafic faible (<10K/mois), ressources dev limitées ? Liquid suffit. Mais à l'échelle moyenne-grande, audience mobile-first, cibles de performance agressives — le compromis du temps de build d'Hydrogen devient acceptable. Dans notre cas, le gain TTFB et l'augmentation de vélocité développeur ont remboursé le coût de migration en 45 jours. Deux mois après, les métriques concrètes correspondent aux promesses — Hydrogen n'est pas une sur-ingénierie.