Parce que Shopify rendait le layout et le template en entier avant d’envoyer le document. Pendant ce temps, le navigateur ne pouvait ni lire le head, ni commencer à télécharger les feuilles de style et les polices nécessaires au premier affichage.

Le head d’un layout est pourtant surtout statique : balises meta, liens vers les feuilles de style, préchargement des polices, quelques scripts. Il se rend en quelques millisecondes. Le temps de rendu se concentre dans les sections du template, et le navigateur restait bloqué derrière ce travail Liquid, même pour des ressources déjà connues.

Shopify rend désormais tout ce qui précède {{ content_for_header }} dans le layout et l’envoie au navigateur dès que possible, pendant que le template continue de se rendre. Le reste de la page suit dans le même flux HTML une fois le rendu terminé.

Le navigateur lit donc l’en-tête plus tôt, ouvre les connexions et commence à télécharger les ressources qu’il y trouve. Quand le corps de la page arrive, une partie du travail réseau est déjà faite. Le HTML final est identique à celui d’avant : seul l’ordre d’envoi change.

D’après les mesures publiées par Shopify sur l’ensemble des pages storefront, le TTFB de la boutique médiane a baissé d’environ 29 % au p75 et de 21 % au p90. Le FCP et le LCP, qui mesurent ce que le client voit réellement, progressent aussi, dans une moindre mesure : environ 2 à 6 %.

Toutes les pages éligibles, sans action de votre part : Shopify a déployé ce comportement au niveau de sa plateforme.

Une page est éligible si elle utilise un template JSON (et non un template .liquid) et si le layout contient {{ content_for_header }} tel quel dans le head : sans filtre, sans condition if ni capture autour, hors snippet et sans assignation préalable à une variable.

Les thèmes en prévisualisation, la barre de prévisualisation et l’éditeur de thème ne sont pas concernés. Pour mesurer l’effet, testez donc sur le thème publié. Shopify élargit l’éligibilité progressivement, et les pages hors critères restent sur l’ancien mode d’envoi.

En plaçant les ressources nécessaires au premier affichage au-dessus de {{ content_for_header }}. Toute page éligible gagne en TTFB, mais le navigateur ne peut télécharger que ce qu’il a déjà reçu. Si la feuille de style principale et les polices sont placées sous le tag, l’avance profite surtout à des balises meta.

Dawn place content_for_header tôt, puis charge base.css, les polices et les feuilles de composants en dessous. Horizon déclare presque tout avant content_for_header. Selon Shopify, pendant le déploiement, le TTFB progressait de façon comparable sur les deux thèmes pour la boutique médiane au p75, mais Horizon transformait ce gain en environ 3 fois plus d’amélioration du FCP et 2 fois plus du LCP que Dawn.

Concrètement : confirmez l’usage de templates JSON, gardez {{ content_for_header }} intact dans le head, puis remontez au-dessus du tag les ressources du premier écran (feuilles de style visibles d’emblée, font_face et preload des polices, variables CSS issues des réglages du thème, import map et modulepreload utiles). Gardez le head léger, sans boucle coûteuse sur le catalogue avant l’envoi.

Ne modifiez pas content_for_header : pas de filtre, de condition, de capture, de snippet ni de variable. Un layout d’application qui capture ou réécrit le tag désactive le streaming pour les pages qui l’utilisent. Vérifiez aussi les layouts du dossier layout/ que vous n’avez pas écrits vous-même.

Un script inline qui lit l’objet Shopify au-dessus du tag provoque une erreur, car cet objet n’existe pas encore. Laissez ces scripts en dessous, ou lisez la valeur en Liquid (request.design_mode, routes.root_url, etc.). Une feuille de style déplacée au-dessus peut aussi perdre en priorité face aux styles injectés par Shopify : contrôlez à nouveau les composants et les boutons de paiement accéléré.

Mesurez sur le thème publié, pas dans l’éditeur. Le streaming modifie aussi la lecture du TTFB, puisque le premier octet peut arriver avant la fin du rendu du template. Theme Inspector continue de profiler le Liquid, et l’écart responseEnd - finalResponseHeadersStart reste une bonne approximation du travail serveur après le premier envoi. Le FCP et le LCP restent les indicateurs de ce que voit l’acheteur.

Celles qui ont un thème sur mesure ou dérivé de Dawn ou d’Horizon avec beaucoup de CSS et de polices chargées sous content_for_header, des pages produit ou collection lourdes en Liquid, ou un premier affichage lent malgré un TTFB correct.

La démarche : 1) vérifier l’éligibilité (templates JSON, tag intact dans le head) sur le thème publié ; 2) comparer l’ordre de vos ressources critiques à celui d’Horizon ; 3) déplacer les ressources avec prudence, puis contrôler la console et les métriques d’affichage dans Lighthouse ou les DevTools ; 4) continuer d’optimiser le Liquid des sections, car le streaming ne réduit pas le travail serveur total, il permet seulement au navigateur d’avancer en parallèle.

Lighthouse réalise ce type d’audit du layout et du premier affichage avec votre équipe technique, sur votre thème actuel et sans changement de plateforme.