À retenir
- Sur plus de 500 boutiques Shopify que nous avons analysées, les sites utilisant des constructeurs de pages par glisser-déposer étaient 22 à 37 % plus lents que les sites équivalents utilisant un constructeur générant du code de thème natif. L’écart est structurel, ce n’est pas un problème de configuration.
- La plus grande erreur que font les propriétaires de boutiques lorsqu’ils évaluent leur vitesse est de se fier à un seul test Lighthouse. Lighthouse correspond au chargement d’une page dans un environnement synthétique ; vos vrais utilisateurs visitent votre site avec des réseaux, appareils et pages très différents.
- Utilisez le Real User Monitoring (RUM) au 75ème centile (P75) pour mesurer ce que vos clients ressentent vraiment. C’est également ce que Google utilise pour son classement.
- Les tests synthétiques (Lighthouse, WebPageTest) sont parfaits quand il s’agit de faire une comparaison relative entre plusieurs outils. Ce n’est pas une mesure très fiable pour refléter votre vrai niveau d’UX lors d’utilisations de votre site en temps en réel.
Les constructeurs de pages Shopify les plus rapides sont ceux qui écrivent du code de thème natif, parce qu’ils n’ajoutent aucun JavaScript lors du runtime sur la page ; les constructeurs de pages par glisser-déposer (drag-and-drop) entraînent tous un coût en matière de vitesse qui est mesurable à cause de leur runtime d’app par visite — soit de l’ordre de 22 à 37 % en moyenne sur les plus de 500 boutiques Shopify que nous avons analysées. Un constructeur de pages ralentissant votre boutique vous coûte des conversions, du ROAS sur vos publicités et votre bon classement SEO tout à la fois. Ce guide vous explique ce qui cause en réalité le ralentissement, la manière de le mesurer sans tricher au moyen de données utilisateurs réelles, avec en bonus un modèle de speed test à copier-coller afin de pouvoir tester chaque outil vous-même.
Pourquoi vous pouvez nous faire confiance
Plus de 15 ans d’expérience en dev et quatre ans au sein de l’écosystème Shopify. Nous avons mesuré les performances de plus de 500 boutiques Shopify utilisant Fudge ainsi que d’autres outils, et nous en avons reconstruit les thèmes spécifiquement dans le but de récupérer la vitesse perdue à cause de ces apps en question. Nous développons également Fudge, l’outil qui modifie et crée vos pages de thème au lieu de solliciter la charge qui accompagne un runtime — ce choix de conception de notre part de l’application a précisément été guidé en réponse à cette grosse problématique.
Ce qui ralentit réellement une boutique Shopify quand on installe un page builder
Il y a quatre facteurs. Et ils s’additionnent.
1. Le JavaScript du runtime du builder
La plupart des builders en drag-and-drop injectent un bundle JavaScript à chaque visite sur une page qu’ils génèrent. Ce bundle gère l’hydratation de la mise en page, le lazy-loading des blocs, les animations, et le lien de prévisualisation de l’éditeur. Il s’exécute même quand le client ne fait que regarder ou scroller.
Le poids de ce fichier varie. Certains outils ont allégé leur runtime. D’autres chargent plus de 200 Ko de JavaScript que le client doit parser avant que la page ne devienne interactive. La différence se voit sur le Total Blocking Time et le Largest Contentful Paint.
2. Le CSS “render-blocking” injecté dans le head
Les page builders injectent souvent une feuille de style dans le <head> du document avant le rendu de la page. Cette feuille de style doit être téléchargée et parsée avant que le navigateur ne commence à afficher quoi que ce soit. Sur des réseaux lents, c’est la cause principale d’un LCP lent.
3. Les grandes images hero servies sans formats modernes
La faute ne revient pas en soi aux pages constructeurs — cependant leurs templates présentent souvent par défaut des images vitrines hero (images à la Une) surdimensionnées. Le client final télécharge par conséquent l’image hero de 1,5 Mo sur une connexion type mobile. Réglez le problème en utilisant l’optimisation des images sous le standard WebP ou AVIF, ce qui octroiera la mesure des tailles correctes, et intégrez les bons attributs via les loading.
4. L’accumulation d’apps qui ajoutent chacune leur propre poids
Une app de page builder + une app d’avis clients + un widget de chat + une app d’upsell = de 1 à 2 Mo de JavaScript avant même que la page ne fasse quoi que ce soit d’utile. Le page builder est rarement le seul coupable, mais c’est généralement l’un des plus lourds. Auditez le tout.
Ce que veut dire “pas de runtime” dans la pratique
Un constructeur de pages générant du code natif écrit le Liquid + le CSS + HTML dans les fichiers de votre thème et n’y rajoute rien d’autre. Quand un client le visite, l’interface du serveur hébergeant réalise le rendu de votre site de la même manière qu’une autre page Shopify. Aucun appel sollicitant un SDK depuis l’application, l’ajout du JavaScript et d’une structure de page (layout) est inexistant durant le runtime de vos thèmes sans quoi l’écosystème mettrait beaucoup plus de temps pour se monter sans pour autant paraître meilleur.
Fudge fonctionne de cette façon : vous configurez la page, Fudge l’écrit pour vous dans votre thème, et le côté technique produit le code qui aura ensuite la même empreinte JavaScript que s’il s’agissait d’une page codée à la main minutieusement par votre développeur. Le score Lighthouse se focalise sur votre thème, vos images et l’impact que produiront vos éventuelles autres applications, et il n’est pas restreint ou imputable à Fudge.
C’est l’atout structurel indéniable de l’application dans un tel domaine. Cela ne signifie pas intrinsèquement que les constructeurs construits autour de l’IA soient intrinsèquement plus performants ou rapides ; c’est avant tout parce que l’intégration du code au format natif au travers du programme à part, en n’y ajoutant de ce fait absolument aucun runtime pénalisant, évite le frein à un tel niveau.
Comment mesurer honnêtement la vitesse sur Shopify
La plupart des articles parlant de “speed test” effectuent un seul audit Lighthouse avant de dévoiler le résultat. C’est une erreur. Le score que vous obtenez avec un seul test Lighthouse n’est pas ce que vivent vos clients — et ce n’est pas ce que Google utilise pour estimer le classement de votre boutique.
Les méthodes ci-dessous sont réunies dans la mesure d’évaluer fidèlement l’impact de la vitesse sur l’UX, le trafic SEO et les conversions.
1. Les données des utilisateurs réels (RUM) — ce que nous et Google utilisons
Le moyen le plus fiable de mesurer la vitesse sur Shopify est d’utiliser les données récoltées auprès de vrais clients. C’est ce que Google utilise dans ses systèmes de classement via les Core Web Vitals. Les données RUM capturent les nombreux facteurs que les tests synthétiques ne peuvent pas voir : les différentes vitesses de réseau, tailles d’écran, capacités des appareils, régions géographiques, et le véritable mix des pages que les clients visitent.
Parce que l’expérience d’un seul utilisateur est trop imprécise pour en tirer des conclusions, vous l’agrégez. Tout comme Google, nous préférons retenir le 75ème centile (P75) de chaque Core Web Vital. Ainsi, un LCP de 4,5s au P75 signifie que 75 % de vos utilisateurs ont ce LCP ou un meilleur. Le P75 est le bon centile car il reflète l’expérience de la grande majorité des utilisateurs tout en limitant les valeurs extrêmes (un client avec une connexion 2G dans un tunnel ne définit pas l’UX de votre boutique).
Si votre métrique P75 est bonne, vous savez que la plupart des utilisateurs ont une bonne expérience. Sur les boutiques Shopify utilisant Fudge, les Core Web Vitals au P75 sont réussis pour plus de 80 % des utilisateurs.
Où trouver ces données :
- Dashboards Fudge — métriques P75 en temps réel sur 100 % des chargements de page, réparties par template et appareil
- Chrome User Experience Report (CrUX) — le jeu de données public RUM de Google, avec un décalage d’environ 28 jours par rapport au temps réel
- Google Search Console — rapport Core Web Vitals, alimenté par le CrUX
Si vous modifiez la vitesse de votre site aujourd’hui, vous le verrez immédiatement dans votre dashboard Fudge ; le changement apparaîtra dans le CrUX et la Search Console sous 28 jours.
2. Les tests synthétiques (Lighthouse, WebPageTest)
Les tests synthétiques consistent à passer une page dans un environnement contrôlé simulant un utilisateur. L’audit Lighthouse sur PageSpeed Insights en est l’exemple le plus courant. C’est utile, mais ça diffèrera toujours des données des utilisateurs réels. Lancez un audit Lighthouse sur Amazon, eBay ou Walmart et comparez-le à leurs chiffres CrUX — l’écart est important.
Trois choses à retenir en lisant un résultat de test synthétique :
Un test synthétique correspond à un seul chargement de page, le RUM en correspond à des milliers. Un seul test Lighthouse peut être décalé de plus de 30 % par rapport à la médiane de trois tests. Prenez toujours la médiane d’au moins trois tests, dans les mêmes conditions de réseau et à la même heure de la journée.
Le Total Blocking Time (TBT) peut induire en erreur. Les outils qui diffèrent (defer) le chargement des scripts non-critiques de sorte à ce qu’ils se chargent après le contenu principal (ce qui est la bonne méthode pour l’UX) ont souvent un score TBT plus élevé dans Lighthouse par rapport aux outils qui bloquent sur ces mêmes scripts. Le chiffre Lighthouse peut augmenter pendant que l’UX réelle s’améliore. Recoupez toujours avec le RUM avant de réagir à une régression du TBT.
Les pièges de la mesure du LCP. Lighthouse et WebPageTest mesurent le Largest Contentful Paint sur l’intégralité du chargement de la page. Les mesures RUM de Google examinent l’élément le plus large avant que l’utilisateur n’interagisse avec la page. Sur une page produit, c’est généralement l’image du produit — mais WebPageTest va parfois mesurer le temps d’affichage d’une popup d’intention de sortie. Paramétrez votre outil synthétique pour arrêter l’enregistrement à la première interaction, sous peine de surestimer le problème.
Si l’on doit choisir un outil de test synthétique, WebPageTest est la référence pour les experts en webperf car il permet de régler finement l’environnement pour coller à un utilisateur P75 (bridage de la connexion, émulation d’appareil, situation géographique). Nous l’utilisons nous-mêmes pour voir la différence d’expérience d’un site avec ou sans Fudge, avant d’avoir les données utilisateurs réelles.
3. L’ordre des opérations
- Connectez un outil RUM (le dashboard Fudge, la librairie web-vitals, ou en piochant via CrUX)
- Établissez une base de référence (baseline) P75 sur 28 jours en prenant en compte vos meilleurs templates et les différents appareils
- Faites une modification
- Surveillez le P75 dans le RUM. Utilisez Lighthouse uniquement pour faire une comparaison relative entre différentes configurations, jamais comme source de vérité.
Si vous n’avez pas encore de RUM, commencez par là. Les comparaisons synthétiques sans le contexte du RUM ne sont que des devinettes.
Un modèle de speed test à copier-coller
Utilisez ce modèle si vous devez comparer des constructeurs de pages sur une boutique de développement avant de vous décider. Associez la médiane synthétique à au moins une semaine de données RUM une fois que vous serez en ligne.
| Constructeur | LCP de base | LCP Page Constructeur | Δ LCP | INP | CLS | JS ajouté | Survit à la désinstallation ? | Notes |
|---|---|---|---|---|---|---|---|---|
| Fudge | Oui | Code de thème natif ; aucun runtime | ||||||
| PageFly | Non | Runtime rendu par l’app | ||||||
| GemPages | Non | Runtime rendu par l’app | ||||||
| Shogun | Non | Runtime rendu par l’app | ||||||
| Replo | Non | Runtime rendu par l’app |
Comment le remplir :
- Installez un thème Shopify Dawn neuf sur une boutique de dev. Lancez Lighthouse Mobile 3 fois sur la page d’accueil ; notez le LCP médian qui sera votre base de référence.
- Installez un constructeur. Publiez une page représentative (hero, trois blocs image+texte, slider de témoignages, FAQ, CTA). Lancez Lighthouse Mobile 3 fois ; notez la médiane.
- Le Δ LCP est votre estimation synthétique du coût infligé par ce constructeur. Note : ceci représente un seul chargement de page. Confirmez avec le RUM après une semaine de trafic réel.
- Désinstallez complètement le constructeur — sans oublier les balises script dans le theme.liquid qu’il aurait laissé dernière lui — avant d’en tester un autre.
- Utilisez les Chrome DevTools → onglet Coverage pour compter le « JS ajouté » (inutilisé vs total) pour chaque constructeur.
La colonne « Survit à la désinstallation ? » expose ce qu’aucune analyse Lighthouse ne peut vous montrer. Faites le test : construisez une page, désinstallez l’app, regardez ce qu’il en reste. Le code de thème natif reste ; le rendu par l’app redevient de simples placeholders (espaces réservés).
À quoi ressemble un « bon » résultat
Chiffres cibles pour une page Shopify sur mobile, mesurés au centile P75 :
- LCP (Largest Contentful Paint) : moins de 2,5s
- INP (Interaction to Next Paint) : moins de 200ms
- CLS (Cumulative Layout Shift) : moins de 0,1
- Poids total de la page : moins de 1,5 Mo (sans vidéo)
Ces résultats ne sont pas là pour faire rêver — ce sont vraiment les seuils Core Web Vitals de Google, mesurés au 75ème centile des chargements de pages sur mobile et desktop (web.dev, 2024). Google a confirmé que les Core Web Vitals sont utilisés par ses systèmes de classement des résultats de recherche — une page qui n’atteint pas ces objectifs n’est pas compétitive.
La façon la plus simple de les atteindre de manière constante sur chaque page que vous publiez est d’utiliser un constructeur qui n’ajoute aucun runtime — ce qui correspond aujourd’hui à un constructeur d’IA qui écrit du code de thème natif plutôt qu’une app en glisser-déposer affichant les pages via son propre runtime. L’écart de 22 à 37 % que nous observons entre les outils en glisser-déposer et les constructeurs de code natif sur plus de 500 boutiques Shopify n’est pas un problème de configuration ; c’est un problème d’architecture.
Les catégories qui ont un désavantage structurel en matière de vitesse
Sans citer d’outils spécifiques :
- Les pages générées par les apps avec des embeddings en iframe. L’iframe à lui seul pénalise votre LCP et complique le CLS.
- Les constructeurs qui injectent une feuille de style (stylesheet) globale sur tout le site, et pas seulement sur les pages générées par le constructeur. Chaque page de la boutique en fait les frais, même celles que le constructeur n’a pas touchées.
- Les constructeurs avec de lourds runtimes d’animation. Le smooth scroll, le parallaxe et les animations d’entrée détériorent l’INP.
- Les constructeurs qui lazy-loadent la mise en page (et pas seulement les images). Une mise en page qui a besoin du JavaScript avant de s’afficher (paint) pénalise à la fois le LCP et le CLS.
Les outils qui embarquent des runtimes légers peuvent rester acceptables — le coût est réel mais mesuré. Les outils qui embarquent de lourds runtimes associés à de lourds templates, en plus d’iframes, accumulent fortement les pénalités.
Pour une analyse plus globale, vous pouvez consulter notre classement des meilleurs constructeurs de pages Shopify ainsi que notre article explicatif qu’est-ce qu’un constructeur de pages Shopify.
Une petite note sur l’hébergement et le CDN
Shopify héberge chaque boutique sur son propre CDN par le biais du edge caching directement intégré. La lenteur liée aux constructeurs de pages provient rarement d’un problème d’hébergement — il s’agit presque toujours d’un problème de poids des pages (payload). L’amélioration des images, la suppression du JavaScript inutilisé et la consolidation des apps corrigent plus de choses que n’importe quel changement d’hébergement.
L’évolution de cette catégorie
Nous jouons cartes sur table — nous avons créé Fudge, qui écrit les pages directement dans votre thème au lieu d’en faire le rendu via un runtime d’app. Nous avons fait ce choix de conception parce que la perte de vitesse occasionnée par ce modèle basé sur le runtime n’est pas un simple bug qui se corrige ; c’est un problème intrinsèque à son architecture. Les constructeurs en glisser-déposer ont la possibilité d’optimiser leurs runtimes, mais ceux-ci ne pourront jamais tomber à zéro. Les constructeurs IA générant du code natif peuvent relever le défi.
Pour la plupart des boutiques en 2026 — en particulier celles qui utilisent du trafic payant où chaque tranche de 100 ms de LCP vous coûte du ROAS — la question n’est plus : « quel constructeur de pages est le plus rapide ? », mais : « quelle catégorie n’a pas de plafond structurel limitant sa vitesse ? ». C’est une optique très différente de celle adoptée par la catégorie il y a seulement un an.
FAQ
Quel est le constructeur de pages Shopify le plus rapide ?
Les plus rapides sont ceux qui génèrent du code de thème natif sans runtime, parce que les pages s’affichent sans la surcharge qu’imposerait une app. Sur plus de 500 boutiques Shopify analysées, les sites utilisant des constructeurs en glisser-déposer étaient en moyenne 22 à 37 % plus lents que ceux utilisant des constructeurs générant du code de thème natif. Vérifiez avec vos propres données RUM une fois en ligne ; Lighthouse seul ne suffit pas.
Dois-je me fier à un seul test Lighthouse ?
Non. Lighthouse correspond à un seul chargement de page dans un environnement contrôlé ; les vrais utilisateurs visitant votre site se heurtent à des milliers de conditions différentes. Utilisez la médiane de trois tests Lighthouse pour effectuer une comparaison relative entre différentes configurations, puis validez cette base après au moins une semaine à consulter les données réelles des utilisateurs au 75ème centile.
Qu’est-ce que le RUM et pourquoi est-ce important ?
Le Real User Monitoring (RUM) correspond aux données collectées via le navigateur de vos vrais clients, avec un rapport pointant au 75ème centile. C’est ce que Google utilise pour l’indexation et le classement via les Core Web Vitals. Les outils synthétiques (Lighthouse, WebPageTest) estiment ce que vivrait un client ; le RUM vous dit vraiment ce que ressentent la majeure partie de vos utilisateurs.
Un constructeur de pages va-t-il pénaliser le SEO de ma boutique Shopify ?
C’est possible, s’il ajoute assez de JavaScript pour pousser votre LCP P75 et INP hors des limites des Core Web Vitals. Les pages qui échouent aux Core Web Vitals sont désavantagées face à la concurrence dans les résultats de recherche. Faites vos tests sur un RUM mobile, et pas sur un Lighthouse depuis un ordinateur de bureau.
Le CDN intégré de Shopify rend-il la vitesse des constructeurs de pages moins importante ?
Non. Le CDN délivre les fichiers rapidement, mais le navigateur du client doit toujours parser et exécuter chaque bundle JavaScript chargé par le constructeur. Runtime lourd = page lente, peu importe la vitesse du CDN.
Comment puis-je tester un constructeur de pages sans l’installer sur ma boutique en direct ?
Utilisez une boutique de développement. Installez le thème Shopify Dawn, installez le constructeur, publiez une page représentative, lancez Lighthouse 3 fois sur mobile, gardez la médiane. Désinstallez avant de tester le suivant. Une fois qu’un constructeur est sur votre boutique en direct depuis une semaine, les données RUM sont la source de vérité — les tests synthétiques n’étaient qu’une première sélection.
Dois-je désinstaller les applications de constructeur de pages que je n’utilise pas pour gagner en vitesse ?
Oui — et vérifiez si des extraits de code (snippets) subsistent dans le thème après la désinstallation. Certains constructeurs laissent des balises script ou des imports CSS dans theme.liquid même après la suppression de l’app.
