tech stack
Plateforme ecommerce détectée
MetricSpot détecte la plateforme ecommerce qui propulse le site (Shopify, WooCommerce, BigCommerce, Magento, PrestaShop, Wix, Squarespace). La plateforme détermine quels leviers SEO et performance bougent vraiment l'aiguille.
Ce que vérifie ce contrôle
Empreinte la page contre une bibliothèque de signatures de plateformes ecommerce et remonte laquelle (le cas échéant) propulse la boutique. C’est informatif — cela ne passe ni n’échoue. Cela change quelles recommandations en aval s’appliquent, parce que chaque plateforme a des défauts différents pour Schema.org, analytics, le cache et la gestion des images.
Pourquoi c’est important
Les conseils génériques « rendez votre boutique plus rapide » sont inutiles. Le conseil actionnable est spécifique à la plateforme :
- Shopify émet automatiquement Product Schema.org et gère la livraison CDN des images, mais chaque app tierce que vous installez ajoute du JS à chaque page — c’est le levier principal.
- WooCommerce tourne sur WordPress, donc il hérite du problème d’éparpillement des plugins WordPress et a besoin d’un cache objet (Redis) plus un CDN pour être rapide.
- Magento / Adobe Commerce est le plus lourd du lot et requiert Varnish, le mode catalogue plat et un préchauffage de cache agressif pour être tolérable.
- BigCommerce est hébergé, donc la plupart des leviers de performance sont hors de votre contrôle — vos leviers sont le choix du thème et la personnalisation Stencil.
Connaître la plateforme vous dit lesquels de ces leviers existent. Le reste de l’audit se lit différemment en contexte.
Comment corriger
Ce contrôle est informatif, donc l’action dépend de ce qui a été détecté.
Heuristiques de détection, pour référence. MetricSpot regarde :
- Balises
<meta name="generator">(Shopify,WooCommerce 8.x,Magento). - Objets JS globaux (
window.Shopify,window.wc_cart_fragments_params, namespaceMage). - Motifs de chemin d’assets (
/cdn.shopify.com/,/wp-content/plugins/woocommerce/,/skin/frontend/,/static/version*/frontend/). - Cookies (
shopify_session,woocommerce_cart_hash,frontendpour Magento). - Conventions d’URL (
/products/,/collections/,/cart/,/checkout/).
Leviers Shopify :
- Auditez les apps installées. Chaque app injecte des scripts sur chaque page même inutilisée — désinstallez, ne désactivez pas seulement. Utilisez les sections natives du thème au lieu des page builders tiers.
- Les sections natives Online Store 2.0 battent les builders tiers sur les Core Web Vitals à chaque fois.
- Shopify émet automatiquement le schéma Product ; vérifiez-le avec données structurées JSON-LD sur une page produit.
Leviers WooCommerce :
- Installez un cache objet persistant (Redis via le plugin Redis Object Cache). Sans lui, chaque chargement de page lance une requête à froid contre la table wp_options.
- Mettez un CDN devant (Cloudflare APO est conçu pour WordPress).
- Différez ou supprimez
wc-cart-fragmentssur les pages hors panier — il déclenche un appel AJAX à chaque chargement de page. - Passez les images produit en AVIF/WebP via un plugin comme Imagify ou utilisez Cloudflare Polish.
Leviers Magento / Adobe Commerce :
- Faites tourner Varnish (pas le cache full-page PHP intégré). Magento embarque le support Varnish first-class.
- Activez le catalogue plat (produit + catégorie) si vous avez moins d’environ 1M SKU.
- Mode production + DI compilé + JS/CSS fusionnés. Le mode développeur en production plombera le LCP.
- Sortez les bundles JS de checkout du chemin critique ; le checkout par défaut de Magento est la page la plus lourde sur la plupart des boutiques.
Leviers BigCommerce / Wix / Squarespace :
- Le choix du thème est votre contrôle principal. Choisissez un thème Stencil avec de hauts scores PageSpeed dès le départ ; les personnalisations ajoutent du poids, n’en retirent jamais.
- Limitez les scripts tiers dans le script manager — chaque widget analytics et chat se compose.
Combinez ce constat avec le contrôle détection CMS (remonte souvent le CMS hôte), outil analytics installé (setup de reporting ecommerce) et données structurées JSON-LD (schéma Product / Offer pour les rich results).
Questions fréquentes
Pourquoi MetricSpot n’a-t-il pas détecté ma boutique sur mesure ?
Les boutiques sur mesure (Next.js Commerce, Hydrogen, Remix + Stripe) ne laissent souvent pas d’empreintes de plateforme — c’est par design. Si la détection revient vide mais que vous savez que c’est une boutique, vous tournez probablement en setup headless et le contrôle framework web identifiera le frontend. Les conseils spécifiques à la plateforme ci-dessus ne s’appliquent pas ; vous possédez chaque levier.
Un site peut-il faire tourner plus d’une plateforme ecommerce ?
Oui — et c’est une mauvaise odeur. Des Shopify Buy Buttons embarqués sur un site WordPress déclencheront les deux détections. Idem pour un site WooCommerce embarquant un iframe Stripe Checkout (qui ne déclenche que le contrôle processeur de paiement, pas le contrôle ecommerce). Deux plateformes signifient généralement analytics en doublon, conversions doublement comptées et parcours client confus. Choisissez-en une pour le checkout.
La plateforme détectée affecte-t-elle mon score Lighthouse ?
Indirectement. La plateforme ne tourne pas dans Lighthouse — votre HTML rendu si. Mais les défauts de chaque plateforme vous poussent vers certains motifs : les thèmes Shopify tendent à shipper des vidéos héros lourdes, WooCommerce charge le JS cart-fragments sur tout le site, Magento envoie des mégaoctets de CSS. La plateforme façonne le plancher du score. Vos choix de thème et d’apps déterminent où vous atterrissez dans ce plancher.
Sources
Dernière mise à jour 2026-05-11