Core Web Vitals Shopify en 2026 : la checklist d'audit que nous lançons avant de chiffrer un projet

Chaque boutique Shopify qu'on nous a demandé d'auditer avait un problème de Core Web Vitals. Certaines le savaient. La plupart pensaient que leur site était "plutôt rapide" parce que la home tournait bien sur le MacBook du fondateur en Wi-Fi du bureau. Puis nous avons mesuré ce même site avec un outil de monitoring utilisateur réel sur un Android milieu de gamme en 4G, ce qui correspond au vrai trafic mobile, et les chiffres racontaient une autre histoire.

Voici la checklist que nous déroulons le premier jour d'une mission de performance. C'est le même process diagnostic qui nous sert à rédiger une proposition, et c'est exactement ce que plus de marchands devraient faire avant de croire que la prochaine app installée va régler le problème.

Ce que mesurent vraiment les Core Web Vitals en 2026

Trois métriques comptent pour le ranking et la conversion. Les seuils "Good" n'ont pas bougé en 2026, mais le poids relatif d'INP continue de croître à mesure que Google insiste sur la qualité réelle de l'interaction.

INP a remplacé FID en mars 2024 et c'est la métrique qui surprend le plus de boutiques. FID ne mesurait que le premier clic. INP mesure chaque interaction, ce qui veut dire qu'une modale d'avis qui met 800ms à s'ouvrir en fin de session compte autant qu'un add-to-cart lent.

Étape 1 : poser un vrai baseline avant de toucher à quoi que ce soit

On ne prouve pas une amélioration sans avoir mesuré le point de départ. Nous tirons les données baseline de trois sources avant d'écrire la moindre ligne de code.

1. Données field CrUX : "Origin Summary" de PageSpeed Insights plus données par URL pour la home, les trois premières collections, les cinq premiers produits, le panier, et tout article de blog à fort trafic.
2. Rapport Core Web Vitals de Google Search Console : il indique quels templates de page échouent et combien d'URLs sont impactées. C'est le rapport que Google utilise pour évaluer votre site.
3. Monitoring utilisateur réel : si la boutique fait plus de 10k sessions mensuelles, installez un outil RUM (CrUX Vis, SpeedCurve ou DebugBear) pendant au moins 7 jours avant optimisation. Les chiffres lab mentent. Les chiffres field, non.

Consignez ces chiffres dans un tableur. Chaque fix des 30 jours suivants doit être mesurable par rapport à ce baseline.

Étape 2 : trouver la fuite JavaScript

C'est là que vit presque chaque problème de performance Shopify. Pas dans le thème, pas dans les images, dans les scripts tiers que les apps injectent sur chaque page.

Ouvrez Chrome DevTools sur une page produit en navigation privée (extensions désactivées), et suivez cette séquence :

// Dans la console DevTools sur une page produit :
performance.getEntriesByType('resource')
  .filter(r => r.initiatorType === 'script')
  .sort((a, b) => b.transferSize - a.transferSize)
  .slice(0, 15)
  .forEach(r => console.log(
    `${Math.round(r.transferSize/1024)}KB  ${r.duration.toFixed(0)}ms  ${r.name}`
  ));

Ça vous sort les quinze plus gros fichiers JavaScript par taille de transfert, avec leur durée de chargement. Sur une boutique surchargée, vous verrez par exemple un widget d'avis de 280KB, une app d'upsell de 190KB, un bundle de chat de 140KB, et un outil d'analytics replay de 90KB, le tout sur une page où 80% des visiteurs ne dépasseront jamais le fold.

Allez ensuite dans l'onglet Coverage de DevTools, rechargez la page, et regardez la colonne "Unused Bytes". Sur une boutique Shopify typique, 60% à 80% du JavaScript chargé n'est pas utilisé sur une page donnée. C'est toute l'opportunité de ranking qui dort là.

Quoi faire de la liste de fuites

Trois seaux. Soyez honnête sur le seau de chaque script.

• Garder, différer : scripts qui méritent leur place mais n'ont pas à tourner avant le LCP. Widgets d'avis, chat, exit-intent. À différer ou lazy-loader.
• Garder, optimiser : scripts obligés de tourner tôt mais chargés salement. Analytics, A/B testing. Passer au server-side tracking ou au chargement async.
• Supprimer : scripts d'apps désinstallées, apps "gratuites" sans contribution mesurable, analytics redondants. Le cimetière est plus gros que vous ne le pensez.

Étape 3 : auditer l'élément LCP

Pour chaque template clé (home, collection, produit), identifiez ce qu'est réellement l'élément LCP. C'est généralement l'image hero. Parfois, gênant, c'est un paragraphe de texte parce que l'image hero est tellement lente que Chrome choisit l'élément suivant.

Utilisez le panneau Performance Insights de DevTools ou le diagnostic Lighthouse "Largest Contentful Paint element". Puis vérifiez dans l'ordre :

Le changement à plus fort impact sur la majorité des boutiques Shopify, c'est précharger l'image hero avec fetchpriority="high". Nous avons vu le LCP tomber de 4,2s à 1,8s en un seul déploiement avec ce changement plus la suppression du CSS bloquant pour le above-the-fold.

Étape 4 : chasser les tueurs d'INP

INP est la métrique que la plupart des boutiques ratent en 2026 parce que les apps Shopify ne sont pas optimisées pour elle. Pour trouver les coupables, ouvrez le panneau Performance de DevTools, démarrez l'enregistrement, faites ce que les vrais utilisateurs font (ouvrir un sélecteur de variante, add-to-cart, ouvrir le tiroir panier, cliquer une promo banner) et arrêtez l'enregistrement.

Examinez le flame chart. Toute "long task" au-dessus de 50ms est candidate. Les long tasks pendant les interactions tuent l'INP. Les coupables fréquents sur Shopify :

• Une app d'avis qui re-render tout le widget d'étoiles à chaque changement de variante
• Un convertisseur de devises qui mute les prix dans une boucle synchrone de 200 lignes
• Un bundle de live-chat qui s'initialise au premier scroll
• Un tiroir panier qui fetch tous les upsells de manière synchrone avant de s'ouvrir

Pour chacun, la correction suit le même schéma : différer le travail non critique, casser les long tasks en chunks via requestIdleCallback, et éviter les mutations DOM synchrones pendant les interactions.

Étape 5 : éliminer le CLS au chargement des fonts et des images

CLS est le plus facile des trois à corriger parce que les causes sont mécaniques.

• Chaque <img> a des attributs width et height explicites (pas juste en CSS). Les thèmes Shopify antérieurs à OS 2.0 oublient souvent.
• Les webfonts utilisent font-display: optional ou swap avec un fallback métriquement équivalent, pour que le swap soit invisible.
• Les apps qui injectent du contenu above-the-fold (bandeau cookie, bandeau promo, sélecteur de devises) réservent leur espace avant leur paint, via un min-height placeholder.
• Les pubs ou embeds tiers (vidéo, social) tiennent dans un container à aspect-ratio fixe.
• Le tiroir panier glisse via transform: translateX(), pas via une animation qui affecte le layout.

La majorité des boutiques Shopify atteignent un CLS sous 0,05 avec ces cinq changements seuls. Les autres ont un problème de thème custom qui demande un refactoring chirurgical.

Étape 6 : valider sur de vrais appareils, pas seulement sur votre laptop

Validation finale sur :

1. Un Android milieu de gamme (Pixel 6a ou équivalent) en 4G throttlée
2. Un iPhone en Wi-Fi (votre segment de trafic le plus rentable)
3. PageSpeed Insights mobile (c'est ce que Google voit)
4. Le rapport "Origin Summary" CrUX 28 jours après déploiement

Si la data field traîne derrière la data lab de plus de 30 jours post-déploiement, il y a une régression quelque part, généralement une nouvelle app installée ou un embed poussé par l'équipe marketing. C'est pour ça qu'on met en place un performance budget en CI pour chaque client Sentinu après lancement : toute pull request qui pousse LCP, INP ou CLS au-delà des seuils définis fait échouer le build avant déploiement.

Ce qu'on a trouvé dans nos dix derniers audits

Nous avons compilé les diagnostics des dix derniers audits Shopify menés au Q4 2025. Les patterns sont remarquablement constants.

Le point n'est pas que Shopify est lent. Le point est que Shopify est rapide et que la plupart des marchands sont lents à cause de ce qu'ils empilent au-dessus.

Quand faire appel à de l'ingénierie versus DIY

Vous pouvez faire les trois premières étapes de cette checklist seul, avec un compte PageSpeed Insights gratuit et un après-midi. Supprimer les apps mortes et précharger l'image hero, c'est vraiment du DIY accessible.

Il faut un partenaire d'ingénierie quand :

• Votre liste d'apps à désinstaller dépasse 5 entrées et vous n'êtes pas sûr de ce qui est safe à enlever
• Vos échecs INP viennent d'apps dont vous ne pouvez pas vous passer (vous avez besoin de refactoring, pas de suppression)
• Vous avez déjà fait les gains faciles et vous restez rouge dans CrUX
• Vous voulez un performance budget en CI pour que les gains ne régressent pas la prochaine fois que le marketing installe quelque chose

Ce dernier point, c'est ce qu'on entend par "corriger durablement". Un audit one-shot redresse votre score pour un trimestre. Un performance budget le garde vert pour toujours.

FAQ

Les Core Web Vitals sont-ils toujours un facteur de ranking en 2026 ?

Oui. Les Core Web Vitals font partie des signaux de page experience de Google et restent un facteur de ranking confirmé, particulièrement sur mobile et pour les requêtes où plusieurs résultats ont une pertinence topique proche. L'effet est rarement la différence entre page un et page cinq, mais c'est régulièrement la différence entre position trois et position sept.

Quel est un timeline réaliste d'amélioration Core Web Vitals ?

Pour la plupart des boutiques Shopify, les gains faciles (preload d'image, conversion de format, suppression d'apps mortes) sont livrés en semaine un et apparaissent dans la data field CrUX 28 jours plus tard. Le travail INP plus profond et le refactoring de thème prennent 3 à 6 semaines. Le cycle complet d'audit à data field durablement verte, c'est typiquement 60 à 90 jours.

Le CDN intégré de Shopify n'optimise-t-il pas déjà les Core Web Vitals ?

Il gère la livraison d'assets, le redimensionnement d'image via image_url et le push HTTP/2. Il ne vous protège pas du bloat d'app, du CSS bloquant ou du code de thème qui fait trop de travail synchrone. Ça reste votre responsabilité.

Faut-il passer headless si mes Core Web Vitals sont mauvais ?

Pas forcément. La majorité des boutiques peuvent atteindre des Core Web Vitals verts sur un thème Liquid bien construit. Le headless est la bonne réponse quand vous avez besoin de fonctionnalités de rendu que Liquid ne peut pas livrer (personnalisation temps réel, caching avancé, TTI sous la seconde sur des templates complexes), pas quand vous voulez simplement un site plus rapide. Voir notre comparatif Hydrogen vs Next.js pour l'analyse complète.

Comment savoir si une app plombe mes Core Web Vitals ?

Désactivez l'app embed dans le customizer de thème (ou utilisez les réglages de l'app pour retirer son injection de script), publiez sur un thème preview, et lancez cette URL preview dans PageSpeed Insights. Si LCP ou INP s'améliorent de 200ms ou plus, cette app a un coût de performance mesurable. Reste à savoir si elle mérite ce coût au regard du chiffre qu'elle génère.

Quelle cible Core Web Vitals viser pour une boutique Shopify Plus ?

Nous visons LCP sous 2,0s, INP sous 150ms, CLS sous 0,05 en data field sur les cinq templates principaux. C'est confortablement à l'intérieur du seuil "good" de Google et ça vous laisse de la marge pour l'inévitable ajout d'app sans repasser sous la ligne.

Pour aller plus loin

Pour un regard plus approfondi sur l'approche d'ingénierie que nous utilisons en performance, voir notre service optimisation de la vitesse Shopify. Si vous envisagez un changement architectural plus profond plutôt que des fixes incrémentaux, la page commerce headless couvre les arbitrages.

Si vous préférez simplement nous envoyer une URL et recevoir un rapport d'audit en retour, c'est habituellement à quoi ressemble la première conversation.