Le 22 septembre 2026, Shopify a annoncé que les boutiques construites sur un thème Liquid commencent à se charger 29 % plus vite, sans aucune intervention du marchand. Le chiffre est exact. Il est aussi très facile à mal lire : il mesure le premier octet renvoyé par le serveur, pas ce que votre client voit à l'écran. Sur ce second indicateur, le gain se situe entre 2 et 6 % en moyenne, jusqu'à 8 % sur les thèmes les mieux organisés : il dépend presque entièrement de la façon dont votre thème est écrit.
Cet article explique ce qui a changé, pourquoi deux boutiques ne récupèrent pas le même bénéfice, comment vérifier si la vôtre en profite, et ce qu'il faut changer dans votre façon de mesurer la performance à partir de maintenant.
Ce que Shopify a changé le 22 septembre 2026
Jusqu'ici, le navigateur ne recevait rien tant que Shopify n'avait pas fini de calculer toute la page. Or l'en-tête d'une page, la partie <head> qui déclare les feuilles de style, les polices et les scripts, se calcule en quelques millisecondes. Ce sont les sections du modèle, fiche produit, liste de collection, blocs de la page d'accueil, qui consomment l'essentiel du temps serveur.
Désormais, Shopify envoie la première partie de la page, jusqu'à la balise {{ content_for_header }}, dès qu'elle est prête. Le navigateur commence aussitôt à télécharger ce qu'il y trouve pendant que le serveur termine le reste. Les deux travaillent en parallèle au lieu de travailler l'un après l'autre. Le document final est identique à celui d'avant : seul le moment où le navigateur le reçoit change.
29 % : le bon chiffre, pour le mauvais indicateur
Shopify publie trois mesures, pour la boutique médiane, au 75e centile :
- Le temps de réponse du serveur (TTFB) baisse d'environ 29 %, et de 21 % au 90e centile.
- Le premier affichage (First Contentful Paint) et l'affichage du contenu principal (Largest Contentful Paint) progressent de 2 à 6 %.
Le premier indicateur est technique. Les deux suivants sont ceux que votre client ressent, et ceux que Google retient dans ses signaux d'expérience de page. Shopify le dit d'ailleurs lui-même : ce sont les mesures qui comptent le plus. Présenter l'annonce comme « des boutiques 29 % plus rapides » revient donc à promettre à un marchand un gain qu'il ne verra pas.
Le détail publié par Shopify pendant le déploiement est plus parlant, parce qu'il compare ses deux thèmes de référence :
| Indicateur (75e centile, boutique médiane) | Thème Dawn | Thème Horizon |
|---|---|---|
| Temps de réponse du serveur (TTFB) | -25 % | -29 % |
| Premier affichage (FCP) | -3 % | -8 % |
| Affichage du contenu principal (LCP) | -2 % | -4 % |
Le gain serveur est presque le même sur les deux thèmes. Le gain visible, lui, est près de trois fois plus important sur Horizon pour le premier affichage, et deux fois plus pour le contenu principal. La différence ne vient pas de Shopify : elle vient du thème.
Pourquoi votre thème décide-t-il du gain réel ?
Le navigateur ne peut télécharger que ce qu'il a déjà reçu. Tout ce qui est déclaré avant {{ content_for_header }} part avec la première partie de la page et se télécharge pendant que le serveur travaille. Tout ce qui est déclaré après attend, comme avant, la fin du calcul.
Horizon place quasiment toutes ses ressources critiques avant cette balise : feuilles de style, préchargement des polices, variables CSS, carte des modules JavaScript. Dawn fait l'inverse : il place {{ content_for_header }} très tôt dans l'en-tête et charge sa feuille de style principale, ses polices et ses styles de composants en dessous. Sur Dawn, l'avance prise par le serveur ne sert à envoyer que des balises meta.
Pour savoir dans quel cas se trouve votre boutique, il suffit d'ouvrir le fichier layout/theme.liquid de votre thème et de regarder où se trouve la feuille de style principale par rapport à {{ content_for_header }}. Si elle est en dessous, votre thème récupère le gain serveur, mais presque rien du gain visible. C'est précisément ce qui se corrige.
Votre boutique est-elle éligible ?
Toutes les pages ne sont pas encore concernées. D'après la documentation de Shopify, une page est envoyée en deux parties à trois conditions :
-
Elle utilise un modèle JSON. Les pages rendues à partir d'un modèle
.liquidne sont pas encore traitées, Shopify indique y travailler. Les modèles JSON sont ceux des thèmes Online Store 2.0, que nous présentons dans notre guide complet des thèmes Shopify 2.0. Un thème ancien, ou un thème personnalisé qui a conservé des modèles.liquid, est exclu sur ces pages. -
La balise
{{ content_for_header }}est écrite telle quelle. Sans filtre, pas enveloppée dans une condition{% if %}ou un{% capture %}, pas déplacée dans un snippet, pas stockée dans une variable. -
Elle se trouve dans le
<head>, et la fermeture</head>vient après.
Un point passe facilement inaperçu : les applications de création de pages d'atterrissage qui fournissent leur propre gabarit. Si ce gabarit capture ou réécrit {{ content_for_header }}, toutes les pages qui l'utilisent sont exclues. Shopify recommande de vérifier chaque fichier du dossier layout/ que vous n'avez pas écrit vous-même.
Enfin, les thèmes en aperçu, la barre d'aperçu et l'éditeur de thème ne bénéficient pas du mécanisme. Toute vérification se fait sur le thème publié.
Ce qu'un développeur peut corriger, et les trois pièges à éviter
La correction consiste à remonter au-dessus de {{ content_for_header }} tout ce dont le premier écran a besoin : feuille de style de base, déclarations et préchargement des polices visibles sans défiler, variables CSS issues des réglages du thème, carte des modules et scripts de type module. Shopify publie un guide dédié qui détaille la structure retenue sur Horizon.
Ce déplacement n'est pas un copier-coller. Trois effets de bord sont documentés :
-
Les scripts qui lisent l'objet
Shopifyau chargement cassent s'ils sont placés au-dessus de la balise : cet objet n'existe pas encore, et la page renvoie une erreurReferenceErrorsur la boutique en ligne, alors que tout fonctionne dans l'éditeur de thème. Ces scripts restent en place, ou lisent la valeur directement en Liquid. - Les règles de style à priorité égale changent de gagnant. Une feuille de style déplacée au-dessus perd les égalités face aux styles que Shopify injecte ensuite, notamment ceux des sections et des boutons de paiement accéléré. Il faut contrôler ces zones et relever la spécificité là où une règle ne s'applique plus.
- L'ordre d'exécution des scripts différés change. Un script du thème remonté s'exécute avant ceux que Shopify compile à partir des sections. Cela ne pose problème que s'il dépend de ces derniers.
Dernière règle, souvent négligée : l'en-tête doit rester léger. Shopify doit calculer tout ce qui précède {{ content_for_header }} avant d'envoyer quoi que ce soit. Une boucle sur les collections ou les variantes dans un snippet de balises meta annule le bénéfice.
Tout cela ne réduit pas le temps de calcul de vos sections. Les bonnes pratiques Liquid restent entières : le mécanisme change le moment où le navigateur peut commencer, pas la quantité de travail du serveur.
Comment vérifier sur votre boutique ?
- Dans Chrome DevTools, onglet Réseau, rechargez une fiche produit ou une collection du thème publié et sélectionnez la requête du document. Sur une page traitée, les requêtes de vos feuilles de style et de vos polices démarrent pendant le téléchargement du document, et non après.
- Comparez deux versions du gabarit, feuille de style sous la balise puis au-dessus, et faites plusieurs passages : le bruit réseau est plus grand que l'écart d'un seul essai, ce sont les médianes qui comptent.
- Lancez un audit Lighthouse avant et après. Le premier affichage et l'affichage du contenu principal doivent progresser. Les feuilles de style restent signalées comme bloquantes : c'est normal, le but est de les démarrer plus tôt, pas de les supprimer.
-
Ouvrez la console sur la boutique publiée, pas seulement dans l'éditeur, à la recherche de l'erreur
Shopify is not defined. -
Passez Theme Check pour confirmer que le contrôle
ContentForHeaderModificationne signale rien.
Mesurer la performance après le 22 septembre : le TTFB ne dit plus la même chose
C'est la conséquence la moins visible de l'annonce, et elle concerne tous ceux qui suivent la vitesse d'une boutique. Le temps de réponse du serveur servait jusqu'ici à estimer le travail côté serveur. Avec l'envoi en deux parties, il mesure l'arrivée du premier morceau de la page, qui peut précéder de beaucoup la fin du calcul. Shopify reconnaît qu'aucun indicateur standard ne mesure encore l'arrivée de la seconde partie.
Trois conséquences pratiques :
- Une baisse du TTFB constatée depuis septembre 2026 ne prouve pas qu'une optimisation a fonctionné. Elle peut venir entièrement de la plateforme. Un rapport qui s'en attribue le mérite se trompe.
- Comparer le TTFB d'une boutique Shopify avec celui d'une autre plateforme n'a plus de sens : les deux chiffres ne mesurent plus la même chose. C'est un point à garder en tête avant toute décision de migration fondée sur ce seul indicateur.
- Les indicateurs à suivre sont l'affichage du contenu principal, mesuré sur de vrais visiteurs dans le rapport de performance web de votre administration Shopify, et le premier affichage, mesuré par un audit Lighthouse. Pour isoler le travail du serveur, Shopify propose l'extension Theme Inspector pour Chrome, qui profile le rendu Liquid, et l'écart entre le premier et le dernier octet du document.
Notre lecture
L'annonce est une bonne nouvelle, sans contrepartie : chaque boutique éligible gagne quelque chose sans rien faire. Mais le gain automatique est surtout un gain serveur. Le gain que vos clients perçoivent se joue dans l'en-tête de votre gabarit, et il est modeste en moyenne : quelques points de pourcentage sur l'affichage.
Nous ne recommandons donc pas de refondre un thème pour cette seule raison. Nous recommandons en revanche de traiter le sujet dès qu'un développeur intervient sur votre thème : vérifier que vos pages clés sont éligibles, remonter les ressources du premier écran, contrôler les trois effets de bord. Sur un thème bien tenu, le chantier reste limité ; sur un thème que plus personne ne maîtrise, il commence par un audit. Dans les deux cas, le gain s'étend à chaque nouvelle page que Shopify rendra éligible.
Si votre boutique tourne encore sur des modèles .liquid, ou sur un thème dont personne ne maîtrise plus le gabarit, l'annonce est surtout un signal : les prochaines optimisations de la plateforme supposeront un thème moderne. C'est un critère de plus dans la décision de refondre votre site Shopify, pas une raison suffisante à elle seule.
Revu par Guillaume, expert en intégration front Shopify chez LobsTTer.
Questions fréquentes
Dois-je faire quelque chose pour bénéficier de l'accélération annoncée par Shopify ?
Non pour le gain serveur : il s'applique automatiquement à toutes les pages éligibles. Oui si vous voulez que vos clients le voient à l'écran : il faut que les feuilles de style, les polices et les scripts du premier écran soient déclarés avant la balise {{ content_for_header }} dans le gabarit du thème.
Ma boutique est-elle vraiment 29 % plus rapide ?
Non. Les 29 % portent sur le temps de réponse du serveur, pour la boutique médiane. Le premier affichage et l'affichage du contenu principal, ceux que vos clients perçoivent, progressent de 2 à 6 % en moyenne selon Shopify, et jusqu'à 8 % sur le premier affichage avec le thème Horizon.
Quelles pages ne sont pas concernées ?
Les pages rendues à partir d'un modèle .liquid plutôt que JSON, les pages dont le gabarit modifie la balise {{ content_for_header }}, notamment certains gabarits fournis par des applications de pages d'atterrissage, ainsi que les aperçus de thème et l'éditeur de thème. Shopify indique élargir progressivement les pages éligibles.
Est-ce que je dois passer au thème Horizon ?
Pas pour cette seule raison. Horizon est simplement déjà organisé de la bonne façon. Un autre thème peut être corrigé en déplaçant les ressources du premier écran, à condition de contrôler les scripts qui lisent l'objet Shopify, la priorité des styles et l'ordre des scripts différés.
Mon TTFB a baissé depuis fin septembre 2026 : est-ce grâce à nos optimisations ?
Pas nécessairement. L'envoi en deux parties fait baisser mécaniquement le temps de réponse mesuré sur les pages éligibles. Pour juger une optimisation, suivez l'affichage du contenu principal sur de vrais visiteurs, le premier affichage dans un audit Lighthouse, et le temps de rendu Liquid avec Theme Inspector.
Le gain aura-t-il un effet sur mon référencement ?
Google tient compte de l'affichage du contenu principal dans ses signaux d'expérience de page. Un gain de quelques pourcentages sur cet indicateur ne change pas un classement à lui seul. Il s'ajoute aux autres chantiers de vitesse, notamment le poids des images et le nombre de scripts tiers.
Vous voulez savoir si votre thème profite de ce changement ? LobsTTer est agence Shopify Platinum Partner, le plus haut niveau de partenariat Shopify, avec +500 sites créés, migrés ou refondus. Nous vérifions l'éligibilité de vos pages clés, l'organisation de votre gabarit et vos indicateurs de vitesse réels, puis nous vous disons ce qui mérite d'être corrigé, et ce qui ne le mérite pas. Pour aller plus loin, découvrez notre audit de site Shopify.
