Consultant web performance expert Medusa.js

Medusa.js, headless commerce modulaire et perf à cadrer

Medusa.js s'est imposé comme l'alternative open-source à Shopify pour les équipes qui veulent contrôler leur stack e-commerce de bout en bout. La version 2.0 réécrit le cœur en architecture modulaire (Modules, Workflows, Links), avec une séparation stricte backend / storefront — typiquement un storefront Next.js qui appelle l'API Medusa via le Store API ou les Server Actions.

Cette modularité est une force de design, mais ouvre quelques angles de dette performance qui se cumulent dès que le catalogue dépasse quelques milliers de produits ou que le trafic monte. L'angle d'optimisation web performance sur Medusa est multi-couche : Postgres profilé sur les requêtes catalogue et pricing, Redis configuré pour le cache et les events, workflows découpés entre synchrone et async, storefront Next.js en ISR ou streaming avec un budget JS strict.

Pricing engine et catalogue, premier chantier

Le pricing engine Medusa résout des règles complexes (price lists, currencies, customer groups, region, sales channel) à chaque requête. Sur un listing produits avec 50 cartes affichant les prix, le calcul peut générer des requêtes en cascade si les relations ne sont pas pré-chargées correctement.

Le diagnostic via le logger Medusa et le profiler Postgres (pg_stat_statements, EXPLAIN ANALYZE) expose les requêtes lentes immédiatement. Le passage en select + relations ciblés au lieu d'un fetch complet, plus le cache Redis sur les calculs de prix stables, descend le TTFB API de 40 à 70% sur les endpoints catalogue. Sur les boutiques à fort SKU, c'est souvent le levier qui fait passer le storefront au vert sur LCP.

Workflows et events, async par défaut

Medusa 2.0 introduit le Workflow Engine, qui orchestre les opérations multi-étapes (création de commande, refund, capture paiement) avec idempotence et compensation. C'est puissant, mais un workflow mal découpé exécute en synchrone des étapes qui devraient être async : envoi d'emails de confirmation, sync vers un ERP, mise à jour d'index Meilisearch ou Algolia.

Le refactor — étapes critiques en synchrone (capture paiement, stock), étapes secondaires en async via Subscribers + Redis events — descend la latence ressentie de la création de commande de plusieurs centaines de ms. C'est la même logique que les queues Laravel, mais portée par le workflow primitives de Medusa.

Storefront Next.js, le terrain Core Web Vitals

Le storefront est typiquement séparé du backend (Next.js, Remix, Astro). C'est là que se joue le LCP, le CLS et l'INP que Google mesure. Les pièges classiques : revalidate: 0 partout au lieu d'ISR sur les pages catalogue, hydration totale au lieu de RSC + streaming, payment SDK Stripe ou PayPal chargé sur la home alors qu'il n'est utile qu'au checkout.

L'audit storefront couvre le bundle JS (250 ko gzip cible sur la home), les images produits (format AVIF, sizes corrects, lazy au-dessous du fold), le cache CDN sur les pages produits, et le découpage RSC/Client précis. Sur un Next.js storefront Medusa correctement cadré, on tient un LCP sub-1.5s et un INP sub-200ms même sur 3G mobile.