TTFB Shopify Plus : réduire le temps de réponse serveur

Le TTFB Shopify Plus est la première brique de votre performance, et la plus souvent ignorée. Google considère qu'un Time To First Byte au-dessus de 800 ms est à corriger. En dessous de 200 ms, on est dans le très bon. Entre les deux, chaque centaine de millisecondes se paie sur le LCP, donc sur le classement et sur la conversion.

Le problème, c'est que la plupart des équipes attaquent la performance par les images et le JavaScript. Elles gagnent 300 ms sur le front, puis butent sur un plancher qu'elles n'expliquent pas. Ce plancher, c'est le temps que met Shopify à générer votre page avant même que le navigateur reçoive le premier octet.

Bonne nouvelle : sur Shopify Plus, ce temps serveur dépend beaucoup plus de votre thème que de l'infrastructure Shopify. Voici ce qu'on regarde, dans l'ordre, quand un client nous appelle parce que son site est lent et que personne ne trouve pourquoi.

Ce que mesure vraiment le TTFB sur une boutique Shopify

Le TTFB additionne trois choses : la résolution DNS et la négociation TLS, le temps de traitement serveur, et le transfert du premier octet. Sur Shopify, les deux extrémités sont gérées par la plateforme et son CDN. Vous n'y touchez pas.

Ce que vous contrôlez, c'est le milieu : le temps de rendu Liquid. Shopify compile votre template, exécute chaque boucle, résout chaque appel de metafield, injecte chaque script d'app, puis renvoie le HTML. Plus ce travail est lourd, plus le TTFB grimpe.

Un point important : Shopify met en cache les réponses au niveau du CDN. Une page produit populaire répond souvent en 50 ms parce qu'elle sort du cache. La même page, en cache miss, peut demander 900 ms de rendu. Vos outils de mesure ne voient pas toujours la différence, et c'est là que les diagnostics dérapent.

Les causes récurrentes d'un TTFB élevé sur Shopify Plus

En audit, on retrouve presque toujours les mêmes coupables. Par ordre de fréquence sur les thèmes qu'on reprend :

• Les boucles imbriquées sur les collections. Un for sur collection.products qui contient lui-même une boucle sur les variantes et les metafields. Sur 200 produits, ça fait des milliers d'opérations par page.
• Les appels all_products non filtrés. Chaque accès force Shopify à charger l'objet produit complet, images et variantes comprises.
• Les metafields résolus un par un au lieu d'être lus en une passe, typiquement sur les fiches techniques d'un catalogue outillage ou peinture.
• Les sections orphelines laissées par d'anciennes apps désinstallées, toujours rendues dans le layout.
• Les settings_data.json obèses, gonflés par des années de tests dans le Theme Editor.
• Les app blocks côté serveur qui font des appels bloquants pendant le rendu Liquid.

Aucun de ces points ne se voit dans un score Lighthouse. Ils se voient dans le temps de réponse serveur, et uniquement là.

Réduire le TTFB : les optimisations Liquid qui comptent

La règle de base : ne demandez à Liquid que ce que la page affiche réellement. Trois chantiers donnent la majorité du gain.

Limiter et filtrer les boucles

Utilisez systématiquement limit sur vos boucles produits. Une section produits similaires qui affiche 4 items ne doit pas itérer sur toute la collection. Remplacez les filtres écrits en Liquid par les filtres natifs de collection quand c'est possible : le tri est fait côté plateforme, pas dans votre template.

Sortir le non critique du rendu initial

Tout ce qui n'est pas visible au chargement peut partir en Section Rendering API. Les avis clients, les recommandations, les blocs de cross-sell, le contenu des onglets : chargés après coup, ils disparaissent du calcul serveur. C'est souvent 200 à 400 ms récupérées sur une fiche produit chargée.

Nettoyer le layout

Le fichier theme.liquid est le plus coûteux du thème : il s'exécute sur chaque page. Chaque snippet inclus, chaque condition, chaque appel d'app s'y paie au multiple du trafic. C'est le premier endroit à auditer, et souvent celui où personne n'ose toucher.

Les apps, le poids caché du temps de réponse serveur

Une app Shopify coûte sur deux plans. Le coût front, mesurable en poids de JavaScript, est connu. Le coût serveur l'est beaucoup moins.

Une app qui installe un app block dans le layout ajoute du rendu Liquid sur toutes vos pages. Une app qui écrit des metafields lus en boucle sur la collection ajoute des résolutions à chaque affichage. Une app désinstallée qui laisse son snippet en place continue de coûter, sans rien apporter.

Notre méthode : sortir la liste des apps installées, la croiser avec une recherche textuelle dans le thème, et identifier ce qui est appelé sans être utilisé. Sur un thème de trois ans, on trouve régulièrement quatre à six apps fantômes. Les retirer coûte une demi-journée et se voit immédiatement dans les mesures.

Mesurer le TTFB correctement avant d'optimiser

Un audit sérieux ne se fait pas sur une seule mesure. Voici le protocole qu'on applique.

D'abord, mesurez en cache miss. Ajoutez un paramètre d'URL aléatoire pour contourner le cache CDN, et comparez avec la même URL sans paramètre. L'écart vous donne le vrai coût de rendu de votre thème.

Ensuite, mesurez par gabarit. Page d'accueil, collection, fiche produit, panier, recherche : chacun a son profil. Le problème est presque toujours concentré sur un ou deux gabarits, rarement partout.

Enfin, croisez avec les données terrain. Le rapport Web Vitals de l'admin Shopify et la Search Console donnent la réalité de vos visiteurs, pas celle d'un test isolé. C'est le même réflexe que pour optimiser les Core Web Vitals d'un Shopify : sans données terrain, vous optimisez à l'aveugle.

Ce qu'on a appris sur un catalogue technique de 12 000 références

Chez Artich.io, on a repris le thème d'un fabricant d'outillage dont les pages collection répondaient en 1,4 seconde côté serveur. Le front avait déjà été optimisé par une autre équipe, sans effet visible.

Le diagnostic a pris une demi-journée. La section de filtres personnalisés parcourait l'intégralité de la collection à chaque chargement pour construire dynamiquement la liste des attributs techniques, lus en metafields un par un. Sur une collection de 900 références, cela représentait plusieurs milliers de résolutions par page.

La correction : construire la liste des attributs une seule fois dans un metaobject, mis à jour par un job planifié, et lire ce metaobject unique au rendu. Le TTFB en cache miss est passé de 1,4 seconde à 340 ms. Le LCP mobile a suivi, sans qu'une seule image soit retouchée.

La leçon est simple : sur un catalogue technique, le problème est rarement le poids des assets. C'est la façon dont le thème interroge la donnée. Un audit structuré permet de le voir en quelques heures au lieu de plusieurs semaines de tâtonnement.

Conclusion

Réduire le TTFB d'un Shopify Plus n'est pas un sujet d'infrastructure, c'est un sujet de thème. Shopify vous fournit un CDN mondial et un cache performant. Ce qui reste sous votre responsabilité, c'est le temps que met votre Liquid à produire le HTML.

La méthode tient en quatre étapes : mesurer en cache miss et par gabarit, traquer les boucles et les metafields résolus en série, sortir le non critique du rendu initial, auditer le coût serveur des apps. La plupart des boutiques que nous reprenons gagnent entre 400 et 900 ms sur ce seul périmètre, sans toucher au design ni au contenu.

Si votre site plafonne malgré des images optimisées et un JavaScript allégé, le TTFB est probablement votre plafond. Il se mesure en une demi-journée. Voir aussi notre page performance et CRO Shopify Plus et la documentation performance officielle de Shopify.

Vous voulez en parler avec un expert Shopify ? L'équipe Artich.io accompagne marques hardware, fabricants d'outils et enseignes de bricolage sur Shopify et Shopify Plus en France, du catalogue technique au B2B avec intégration ERP. Parlons de votre projet →