Test de vitesse des page builders Shopify : Méthodologie & bonnes pratiques RUM

Points clés

• Sur les plus de 500 boutiques Shopify que nous avons analysées, les sites utilisant des page builders drag-and-drop étaient 22 à 37 % plus lents que les sites équivalents utilisant des générateurs de code de thème natif. L’écart est structurel, ce n’est pas un problème de configuration.
• La plus grosse erreur que font les boutiques en testant leur vitesse est de se fier à une seule exécution de Lighthouse. Lighthouse correspond à un seul chargement de page dans un environnement contrôlé ; les vrais utilisateurs arrivent sur votre site via des réseaux ou des appareils différents, vers des pages différentes.
• Utilisez le real-user monitoring (RUM) au 75e centile pour mesurer ce que vos clients ressentent vraiment. C’est aussi ce que Google utilise pour ses classements.
• Les tests synthétiques (Lighthouse, WebPageTest) sont utiles pour obtenir une comparaison relative entre plusieurs outils. Ne comptez pas dessus pour calculer votre UX réel de façon fiable.

Oubliez les lenteurs, les page builders Shopify les plus rapides sont ceux qui créent du code de thème natif, car ils n’ajoutent aucun JavaScript d’exécution (runtime) à la page. Les builders drag-and-drop entraînent tous une pénalité de vitesse liée à l’exécution de leur app à chaque visite — 22 à 37 % en moyenne sur les plus de 500 boutiques Shopify que nous avons analysées. Un page builder qui ralentit votre boutique vous coûte simultanément des conversions, du ROAS sur vos annonces et de bonnes places en SEO. Ce guide explique ce qui cause réellement ce ralentissement, la meilleure manière de le mesurer avec des données RUM, et il vous offre même un template copier-coller pour évaluer le coût d’un outil par vous-même.

Pourquoi vous pouvez nous faire confiance

Nous profitons de plus de 15 ans d’expérience dans le dev et quatre ans au cœur de l’écosystème Shopify. Nous avons mesuré les performances de plus de 500 boutiques fonctionnant avec Fudge et d’autres outils, et nous avons retapé des thèmes dédiés dans le but de rattraper la rapidité que bouffaient les applis. Nous concevons également Fudge, qui code les pages directement dans votre thème au lieu d’y balancer un runtime — une idée issue du simple problème de lenteur.

Ce qui ralentit vraiment une boutique Shopify quand on installe un page builder

Il y a quatre sources de problèmes. Et ils s’accumulent.

1. Le bundle JavaScript lié au runtime du builder

La grande majorité des builders drag-and-drop déploient un paquet JavaScript à chaque visite sur une page qu’ils ont conçue. Ce paquet régit parfois l’hydratation du layout, un lazy-loading sur des blocs ou des animations, au même titre qu’un lien de prévisualisation dans le mode éditeur, et ce qu’importe si le client ne fait que jeter un coup d’œil.

Bon à savoir, l’impact change d’un outil à l’autre. Quelques-uns se contentent d’un volume peu dérangeant, à l’inverse de leurs camarades qui peuvent exiger des paquets de 200 Ko de JS que les visiteurs essaient de charger pendant que la page s’anime. Le décalage se voit au niveau du Total Blocking Time et du Largest Contentful Paint.

2. Le CSS “render-blocking” planqué dans le head

La fâcheuse manie des page builders ? Injecter une feuille de style dans le head dès l’affichage du site, qu’il faut pouvoir DL puis lire sans quoi le navigateur ne peut se charger du “paint”. Avec un piètre réseau, voilà de quoi flanquer par terre vos résultats de LCP.

3. Les immenses images hero sans format récent

Même sans leur conférer le mauvais rôle en la matière (la chose demeurant assez courante par défaut chez ce type de builders) un visiteur sur smartphone devra fatalement supporter les 1,5 Mo en moyenne pour un affichage sur son modèle. Essayez de passer au modèle WebP ou AVIF, avec des ajustements de taille et les propriétés loading requises pour compenser cela.

4. Le paquet d’applis qui s’ajoute à la liste

Une application de conception + le fameux programme d’avis + un petit widget pour engager la discussion + l’outil d’upselling derrière… La page a à peine démarré qu’elle vient de choper 1 ou 2 Mo de JavaScript dans la face. Le builder n’est évidemment pas l’unique responsable de cette dégradation, mais il finit le plus souvent dans le top des applications les plus lourdes. Pensez à auditer le bloc.

Ce que la notion “sans runtime” veut dire au final

Un page builder générant un code de thème natif pose sur les fichiers votre Liquid combiné au CSS et le code HTML (pas la peine de s’embarrasser de suppléments). Après connexion, aucune anomalie pour le client dont le code tournera d’une façon identique à tous les supports Shopify.

C’est la méthode de Fudge, qui met en forme votre page depuis le code en direct dans le thème, réduisant l’empreinte JavaScript à un résultat d’artisanat pure souche, comme si un codeur maison avait lui-même posé son ouvrage. Finalement l’analyse Lighthouse s’attarde essentiellement aux images ou à votre thème et ses extensions (exit l’outil de gestion Fudge).

Et voilà la force indiscutable d’une pareille catégorie. Contrairement à des idées reçues face à des rumeurs, l’IA ne conçoit pas mieux ou plus vite que d’autres outils ; l’intérêt revient tout bonnement à sa liberté de générer en échappant au fameux runtime des builders, qui tire constamment la vitesse vers le bas.

Le vrai test honnête sur Shopify

Bon nombre d’articles “spécialisés” dans l’analyse de vitesse lancent trop systématiquement une courte recherche Lighthouse avant de trancher la question. Or ce diagnostic s’avère bien plus erroné qu’on ne l’imagine. En effet, il se contente d’illustrer un échantillon de visiteurs et non la majorité du comportement client – et de son côté, Google refuse même de s’en servir afin d’établir un tel classement.

Découvrez à travers ces quelques recommandations comment réellement appréhender les conséquences d’un de ces tests à la lumière des comportements réels (UX), mais aussi pour le potentiel d’éventuelles conversions ou par rapport aux classements SEO.

1. La force des collectes RUM (pour nous comme pour Google)

Plutôt que d’essayer de décortiquer Shopify avec une appli annexe au fonctionnement expéditif, laissez les outils RUM se charger d’analyser vos clients pour collecter votre précieuse info. Google se base de lui-même sur le procédé avec d’autres collectes pour attribuer son positionnement à l’aide des Core Web Vitals. Et ça fait sens ; en effet, avec ce système il sera aisé de capturer un nombre très élargi de conditions impossibles en configuration synthétique : différentes connexions à Internet parmi plusieurs régions et selon leurs vitesses sans occulter de petits aléas, tel un changement d’écran à l’autre selon votre modèle voire selon vos différentes sections du site.

Dès que l’expérience dépasse du simple échantillon, il vaut d’autant plus mieux l’agréger, ce pourquoi Google recommande vivement (et nous derrière) l’utilisation des centiles évalués au sommet à 75 (le fameux P75) concernant les actions des Core Web Vitals du côté des utilisateurs, signifiant de façon mathématique qu’un délai du LCP à 4,5s sur la métrique concernera tout de même environ 75 % (voire idéalement davantage, s’il fait encore un temps inférieur). Pour ce paramètre, il vaudra d’autant moins le coup de calculer une navigation hasardeuse où le chargement plafonne à cause d’une très vieille 2G au fin fond d’une province rurale sans signal.

Avec une métrique à cet ordre de centiles très raisonnables, la marge d’exploration devient amplement exploitable pour qu’on sache déterminer comment votre groupe vit sa navigation. La boutique est reliée à un code de chez Fudge ? Préparez-vous à valider vos scores P75 au CWV et voir 80 % des connectés passer !

Voici le moyen de récolter la précieuse data :

• Avec le dashboard de Fudge — Le centile prend forme dans le direct face au trafic, classé méticuleusement par format ou par type de templates d’environnements.
• L’utilisation d’un RUM made in Google (CrUX) — Celui-ci prend note dans le domaine public à environ 28 jours en arrière de retard dans la diffusion des mises à jour.
• Search Console via Google également — Où le Core Web Vitals partage sa liaison aux systèmes avec ses paramètres pour la collecte des fameuses données CrUX.

Toute altération au taux de la navigation transparaîtra directement depuis votre tableau récapitulatif Fudge ; toutefois le procédé patientera dans son onglet concernant les CrUX (jusqu’à Search Console) peu ou prou un délai du genre à approcher un peu d’un trimestre ou du moins vingt-huit misérables journées pour ce faire valoir.

2. Les tests synthétiques (Lighthouse, WebPageTest)

Ces calculs prennent leurs mesures en posant toute leur analyse à l’issue de recherches qui visent un modèle factice aux paramètres de clients très modifiés sans aucunes nuances, reproduisant tout l’ensemble de A jusqu’à Z en simulation. On connaît les bienfaits de cette méthode popularisée à l’aide du célèbre mode de test “Lighthouse” chez PageSpeed Insights et des calculs dans son ensemble, toutefois la finalité change au grand air du reste des données qu’utilise un outil type du côté de votre base de visiteurs comme la RUM pourrait proposer. L’audit sur un site en utilisant ce calcul ou ceux pour Amazon ne manquera pas à d’immenses rebondissements à comparer avec ces informations récoltables par des moyens comme CrUX et son volume.

Avant de regarder de près le diagnostic en face du logiciel, voilà 3 grands piliers fondamentaux :

Une estimation unitaire versus ce trafic gigantesque du côté RUM. D’un simple test du Lighthouse s’invitent au bas mot trente de probables pourcentages au final si la source se décale depuis son premier coup ou à travers toute cette trilogie. Réduisez vos résultats plutôt par la moyenne à propos d’exactement 3 lancements au moins selon d’identiques circonstances en essayant précisément la tranche à des moments où l’heure concorde au démarrage du chrono de base ou similaire pour espérer ce diagnostic.

L’interprétation parfois houleuse des metrics type TBT. La question qu’infligent nos amis programmeurs repose à présent en un dilemme aux scripts repoussés peu pertinents vers ce bas fond des autres téléchargements (pour faire plaisir à cette même belle UX au fait, notez cette stratégie essentielle pour tous) en ce qu’il reste pour l’heure perçu comme néfaste durant son jugement au-delà qu’aucun chargement n’en devient réellement amoindri (Lighthouse augmentant considérablement la mesure du même TBT à notre perte), provoquant les colères du client bien moins conscient des faits au global car on confond le TBT dont le paramètre peut vite flancher bien aux antipodes quand cette propre notion vaudrait pourtant pour améliorer tout au réel dans sa base d’expérience des utilisateurs sans oublier leurs ressentis en pleine observation des comportements humains via ce dispositif. Considérez à tout crin la vérification liée des retours par rapport aux fameux outils avec le format sous sa version RUM.

Comment mesurer le LCP. L’avertissement essentiel se résume du côté des calculs vers l’écran en le test Lighthouse et des WebPageTest aux observations où ils décident pour le LCP que ce chiffre équivaut jusqu’au plein temps global. Or, une récolte issue aux calculs RUM pour le côté du groupe cherchant au nom du Google analyse tout le LCP pour l’instant depuis un premier “largest paint” ou un seul, au sein où vous voyez tout cela sans rien qu’avoir approché le fameux clique vers cette structure des modules à vos yeux. Le logiciel pour son observation WebPageTest retiendra pour d’amples occasions hélas au-delà du visuel un temps sur des petites choses un popup pour arrêter au premier regard dans certains clics depuis l’engagement où le paramétrage pourrait être décisif de sorte qu’il faille savoir bloquer son petit appareil pour interdire à cette chose la prise en compte qui ruinerait les résultats.

Vous devrez impérativement employer de nombreux sites dont l’excellent choix reste le parfait candidat : WebPageTest. En tant que mètre-étalon pour le dev des navigateurs et d’outils, il permet d’aménager de parfaites simulations comme la bande du net avec ses variables, selon le GPS comme l’endroit par appareils avec d’autant du reste, imitant du coup la méthode des métriques en simulant l’internaute sous ce filtre approchant de près ce dernier type en un comportement calé juste dans cette branche 75ème. Notre groupe tente du Fudge dans ces cas de figure et c’est super d’exploiter la plateforme.

3. L’ordre des opérations

1. Jumelez vos données avec votre module pour vos utilisateurs réels avec RUM comme un simple tableau pour Fudge au-delà ce que la bonne libraire au code de chez web-vitals par exemple vous donne.
2. Composez un résultat sur la durée moyenne de ce groupe des fameux 80 du centil 28 par la sélection pour du contenu en classant le matériel avec vos appareils.
3. Effectuez le test pour avoir des altérations ou quelques-unes de celles-ci au final sur du coup un élément avec votre projet.
4. Appliquez les vérifications au-delà avec RUM, Lighthouse devant en cas normal s’attacher qu’exclusivement au profit que de la simple comparaison du tout mais loin pour définir pour vos besoins ce qui restera à prendre avec cette finalité.

Faites d’abord dans RUM pour en ressortir tout d’abord ces choses pour le RUM afin d’établir la fondation ou bien, de sorte, attendez-vous aux désillusions, tout ne valant rien devant de pures comparaisons qui s’attendent juste vers du devinement en tant normal car elles nécessitent vos connaissances vers le RUM et aucun outil RUM laisse votre interprétation sur les autres synthétiques qu’on pourrait voir avec ses outils pour avoir l’œil.

Un template de test de vitesse à copier-coller

Utilisez ceci quand vous devez comparer les constructeurs sur une boutique de développement de Shopify au moment des premiers temps qu’avant vos choix tout devient décisif ! Testez à la fois des médias de tests au synthétique de tout genre pour comparer le calcul par un simple rapport synthétique dont on prend comme référence au minimum la plus infime de temps au moyen d’un délai sous huitaine avec le recours devant toute cette part du RUM sitôt votre activité prête.

Comment le remplir :

1. Privilégiez du nouveau en développant un environnement à part où installer du Dawn version vierge, passez un examen par trois sous le Lighthouse Mobile puis identifiez le moment clé au bas mot du meilleur moment de la liste sous ce délai concernant la moyenne LCP, ce temps servant de base.
2. Ajoutez à l’ensemble du setup un bon page builder afin de concevoir et ensuite voir du bon hero avec des éléments comme une section questions / réponses (ce FAQ), ainsi qu’avant aussi du block pour avis (testimonial) au-delà vos autres petits boutons. Lighthouse en version pour mobile y verra bien de quoi nous enregistrer la meilleure base pour cette moyenne des trois tests encore une autre fois.
3. Calculez votre premier écart au nom Δ de son petit signe où du nom se glisse ce Δ LCP et découvrez ensuite pour estimer via synthétisation, avant qu’en la circonstance après le petit temps pour les 7 prochains gros lancements avec votre version de tout ce moment avec une très intense période d’activité (ou sinon on considère les tests faux lors des chargements en un). Vous penserez du coup faire la révision avec ce grand rapport issu de vos outils RUM en fin.
4. Préparez la suite et retirez pour cela l’outil sous le nettoyage radical où même le script resté en la trace à nettoyer vers theme.liquid subira le même grand sort qui suit la désinstallation sous ce test d’au final aucun logiciel et tout le processus doit aboutir sur le nettoyage total.
5. Activez l’affichage au mode Développeur à travers la section Chrome de votre page, la solution dans celui pour le code au sein d’une option “Coverage”, de sorte que tout le surplus “JS ajouté” par vos inutiles codes (inutilisé versus total) pourra décupler tout vis-à-vis pour son petit examen au point le compte sera défini parmi les constructeurs analysables en une liste globale.

À la partie relative à l’outil où figure la petite colonne de mention nommée sur les désinstallations, c’est que ce paramètre se soustrait fatalement par cette même notion au dénuement de l’approche pure de nos logiciels aux analyses synthétiques avec ses fameux outils du Lighthouse par rapport à tous, car la mention ne prendra pas note par cela que du moment de son lancement qu’aux conséquences post suppression. Précisément, on voit avec un tel logiciel tout laisser derrière à sa disparition et ce que fait un natif, tout subsiste pour le site, l’app à l’inverse retombe avec cela sous l’affichage de ce bloc vierge.

À quoi ressemble une “bonne” vitesse

Chiffres cibles pour une page Shopify sur mobile, mesurés au P75 :

• LCP (Largest Contentful Paint) : inférieur à 2,5s
• INP (Interaction to Next Paint) : sous les 200 ms
• CLS (Cumulative Layout Shift) : < à 0,1
• Poids total de la page : inférieur à 1,5 Mo (sans compter les vidéos)

Ces données n’affichent pas qu’une chose pour ambition — car leur nature précise découle des seuils dans la recherche chez Google quant à cette section des signaux (Core Web Vitals), à des pics observés avec les relevés allant au centile d’à la hauteur d’approximativement la tranche fixée aux trois quarts (les 75ème au niveau des taux sur navigateurs à version ordi ni sans nier les mobiles (web.dev, 2024). Google a confirmé que les Core Web Vitals sont utilisés par ses systèmes de référencement : une page qui omet cela aura moins qu’aucune considération aux recherches de ses concurrents dans cette place du résultat global de la page qui perd sa position et se verra pas considérée pour la base de son SEO au fil de cette page du même moteur.

Le chemin idéal et de loin aux moyens des pages en conservant de très hautes qualités demeure qu’on reste fidèle au modèle “builder” ne posant pas à notre dos un “runtime”, un procédé où notre ère a fait tout se réunifier au moment en le confiant avec une app qu’à sa version drag-and-drop face avec de meilleures app pour une version dite au-delà tout natif dans ses versions. Au niveau de nos petites marges du fameux 22–37 % sur une bonne et large récolte vers les + 500 pour ce Shopify, on a qu’une configuration à l’erreur au nom architectural et jamais de fait via qu’aucune autre partie ni sous conditionnalité qu’elle n’inflige aucun dommage de conception en dehors.

Les catégories qui ont un désavantage structurel sur la vitesse

Sans citer d’outils précis :

• Les pages affichées via des intégrations iframe. L’iframe à elle seule ruine votre LCP tout en compliquant l’histoire de ce CLS au passage.
• Les builders injectant une feuille de style globale sur tout le site, et non pas uniquement sur les pages du builder. Tout Shopify pour la boutique passera ainsi sous ce lourd système, y compris la petite sélection des autres parties qui n’étaient à aucun propos visées.
• Les builders avec leurs animations aux charges folles. Apparitions subtiles en version de page avec la version dont l’effet un smooth scroll et du parallaxe ont beau amener une touche soignée ils coûtent une blinde à INP.
• Les builders appliquant du lazy-loading dans toute la conception ou de ce fait n’utilisant ça au mieux à d’autrui que pour ses grandes parties visuelles (et non pas sur l’image seule). Si la dépendance tombe depuis la structure avec les Javascript juste avant le “paint”, préparez-vous que ce procédé ruine totalement l’effet LCP aussi pour agir ensemble vers d’autres parts contre ce pauvre CLS des données.

Il reste envisageable au recours de petites runtimes pas très volumineuses en un simple coût où le tout semble bien aux petites charges qui posent pas grandes peines ni de quoi avoir ces inquiétudes à cela sans poser des conséquences mais en effet un outil se trouve vite pénalisé dès le moment devant toutes les grosses app dont l’ajout amène de fâcheux montants aux charges par rapport l’ajout pour les iframe qui font des ravages à se cumuler toutes ensemble en leur poids massif avec ce genre de ces cas pour plomber les bases sur cette version globalement et faire sombrer au poids maximal à ce problème.

Regardez de ce côté pour en apprendre comment en ces lieux vers d’avantage les autres du sujet sur tous nos articles sur les meilleurs choix comme de meilleurs articles au classement des meilleurs page builders Shopify ou consultez notre guide expliquant le concept à la question qu’est-ce qu’un page builder Shopify.

Une courte note sur l’hébergement et le CDN

Au passage on remarquera : Shopify installe des boutiques avec tout leur contenu via des CDN aux moyens vers le cloud par sa cache de diffusion à ce nom tel qui gère des réseaux par de tels éléments qu’aux services (ou version de cet edge caching au choix). L’inconvénient où tous nos développeurs d’applications pour le monde drag-and-drop des autres boutiques luttent face des systèmes ralentis se tourne majoritairement plutôt par cause au grand problème lié pour tous de son chargement ni vers d’autres qu’ainsi pour ses soucis au niveau du matériel face au souci de charges des éléments (le format qu’à ce fameux payload très souvent) mais quasiment point ou des rares fois d’un simple point qui viendrait toucher un hébergement. Alléger l’intégration vers des formats de photos tout afin mieux repérer les bouts à désinstaller au surplus depuis vos JS et se recentrer vers d’approuvés paquets aux appli aura une chance devant ça bien des dizaines de fois par-delà qu’aucuns réglages d’infrastructure liés ou pas pour vos hôtes.

Où va ce secteur

Nous précisons aussi tout de suite la part d’intérêts sur notre position — en développant du Fudge, nous avons axé une conception qu’à l’avantage lié par le recours pour un système des solutions des thèmes aux conceptions aux vues natives, car il nous semblait d’avantage clair qu’un modèle de rendu par un de nos runtimes face un tel décalage aux résultats à la baisse dans un seul souci posé d’origine face sa façon qu’à son format structurel qui, vu d’avance à ne rien faire dans l’avenir car nul ou point on l’aura corrigé comme la solution au fond de l’erreur au nom que l’impact de vitesse. Les programmes type qu’on crée avec drag-and-drop sont en leur moyen aptes s’ils tentaient d’approcher un plafond sans leur fameuse charge lourde au fond, pourtant d’atteindre nul niveau, il en ressortira point cette valeur pour eux par d’autres que la conception pour la ligne natif chez l’IA de nos jours.

Dans sa grosse réalité au monde pour vos versions pour les plus grands vers les fins de cet an pour à d’approchant à ces années futures dont 2026 l’illustre à propos aux choix concernant toutes les affaires dont leur plus fort potentiel face d’elles ou pour l’ensemble et de ce point tout achat aux acquisitions dont 100 millisecondes ont un effet radical par un petit ralentissement (car on joue sur LCP qui touche vos valeurs ROAS de bout en bout). Il s’agit des moyens qu’on en aura par la vraie et pure nature au meilleur de soi : la meilleure solution qui sort, point en des choix ou l’un ira un tout petit chouïa à l’avantage pour le monde et du logiciel qui est ce meilleur devant ceux avec un tel moyen de création du site : c’est celui ou tel ou quoi où on se trouve avec rien pour d’imposées contraintes liées pour limiter le flux. Un critère très loin depuis le standard duquel ce dernier dépendait aux premiers mois ou de cet autre temps depuis.

FAQ

Articles similaires

Meilleurs AI Page Builders pour Shopify : Comparatif de Fudge, GemPages, PageFly, Replo et Shogun

19 May 2026

Les meilleurs page builders Shopify (2026)

23 Mar 2026

Page Builder IA vs Drag-and-Drop pour Shopify : Vitesse, Contrôle, Propriété

11 May 2026