Vitesse Mobile sur Shopify : Optimiser pour la 3G et les Appareils Lents

Les points clés

• La vitesse de Shopify sur mobile est un problème différent de celui sur ordinateur. Les téléphones ont des processeurs plus lents et utilisent des réseaux instables, or c’est sur mobile que se concentrent la majorité du trafic et des conversions.
• Google évalue trois Core Web Vitals sur mobile : le LCP, le CLS et l’INP. Il les mesure à partir de données de terrain réelles au 75ème centile, rapportées séparément pour le mobile.
• Les tactiques qui font vraiment la différence sont les images responsives via le CDN de Shopify, le lazy-loading pour les médias sous la ligne de flottaison, le report du JavaScript non essentiel et la réduction des scripts d’applications.
• La surcharge d’applications est la principale cause de lenteur sur mobile. Chaque application de widget injecte son propre JavaScript sur chaque page, et celui-ci s’exécute aussi sur le téléphone.
• Fudge écrit un code de thème natif léger au lieu d’ajouter un énième widget. Ainsi, une fonctionnalité est déployée sans l’impact qu’une application infligerait au chargement de chaque page.

Optimiser la vitesse de Shopify sur mobile n’est pas le même travail que de l’optimiser pour un ordinateur de bureau. Une page qui semble s’afficher instantanément sur un ordinateur portable avec la fibre peut ramer sur un téléphone milieu de gamme avec un réseau mobile instable. Et comme la majorité du trafic et des passages en caisse sur Shopify se font sur mobile, c’est cette version qui détermine réellement vos revenus.

Ce guide explique pourquoi le mobile est plus difficile à gérer, quels sont les Core Web Vitals évalués par Google, quelles tactiques concrètes réduisent les problèmes de vitesse sur mobile, et comment tester l’expérience vécue par vos acheteurs dont la connexion est la plus lente.

Pourquoi vous pouvez nous faire confiance

Jacques possède plus de 15 ans d’expérience en développement et a travaillé sur les performances de centaines de boutiques Shopify. Nous développons Fudge, un éditeur de vitrine IA noté 5,0 sur le Shopify App Store. Nous travaillons donc directement sur la couche du thème, là où se joue la vitesse sur mobile, et nous voyons l’impact d’une accumulation d’applications sur un téléphone.

Pourquoi la vitesse sur mobile est différente de celle sur ordinateur

Le même thème tourne sur les deux, mais les conditions ne sont pas les mêmes.

Les téléphones ont des processeurs (CPU) plus lents. Un appareil Android de milieu de gamme analyse et exécute le JavaScript beaucoup plus lentement qu’un ordinateur. Des pages chargées en scripts qui semblent fluides sur un ordinateur portable peuvent bloquer sur un téléphone, car celui-ci passe plus de temps sur le thread principal à exécuter le même code.

Les réseaux mobiles sont variables. Un acheteur peut être sur un réseau 5G rapide chez lui et sur une connexion 3G lente dans un train dix minutes plus tard. Chaque requête supplémentaire et chaque image trop lourde coûte plus cher sur une connexion lente à forte latence.

L’argent se trouve sur mobile. Pour la plupart des boutiques Shopify, le mobile représente la majorité des sessions et des commandes. C’est donc sur le rendu mobile qu’il faut concentrer vos efforts en priorité.

L’objectif n’est donc pas d’obtenir un bon score sur ordinateur. C’est d’avoir une page qui reste rapide sur un téléphone bon marché avec une connexion lente, car cela correspond à une part importante de vos vrais acheteurs.

Core Web Vitals sur mobile : les métriques évaluées par Google

Les signaux liés à l’expérience de la page de Google reposent sur les Core Web Vitals. Il y en a trois, et l’INP est devenu un Core Web Vital officiel en 2024, remplaçant le First Input Delay.¹

Les seuils sont les mêmes sur mobile et sur ordinateur, mais les chiffres que vous obtenez ne le sont pas. Sur un téléphone, une grande image hero fait grimper le LCP, et des scripts lourds font exploser l’INP car le thread principal reste occupé.

Pourquoi les données de terrain privilégient le mobile

Google évalue les Core Web Vitals à partir de données de terrain réelles, et non d’un simple test en laboratoire. Ces données proviennent du rapport d’expérience utilisateur Chrome (CrUX) et sont évaluées au 75ème centile des visites. Une boutique ne réussit donc le test que lorsque les trois quarts des sessions réelles dépassent le seuil exigé.¹

Ces données de terrain sont rapportées séparément pour le mobile et l’ordinateur. Ajouté à l’indexation « mobile-first », où Google utilise principalement la version mobile d’une page pour l’indexation et le classement, la conclusion est simple : c’est votre expérience mobile qui pèse le plus lourd.

Pour avoir une idée plus globale du classement réel des boutiques Shopify, consultez notre rapport sur l’état des performances Shopify.

Comment améliorer la vitesse de Shopify sur mobile

Les gains se concentrent dans quelques domaines : les images, les scripts et la stabilité de la mise en page. Voici où vous devez concentrer vos efforts.

Servir des images responsives depuis le CDN de Shopify

Les images sont généralement les éléments les plus lourds sur une page produit ou collection, et les téléphones n’ont pas besoin de fichiers aux dimensions d’un écran d’ordinateur.

Le CDN d’images de Shopify peut redimensionner une image à la volée. Le filtre Liquid image_url renvoie une URL CDN à la largeur que vous demandez, et le CDN sert automatiquement un format moderne comme WebP ou AVIF lorsque le navigateur le supporte.²

Associez cela à srcset et sizes pour que le navigateur télécharge un fichier adapté à l’appareil. Avec des descripteurs de largeur dans srcset et une indication sizes, le navigateur choisit la source la plus petite qui reste nette, ce qui évite à un téléphone de télécharger une image de 2000px pour un emplacement de 400px.³

Le moyen le plus efficace d’améliorer le LCP sur mobile est souvent de réduire la taille de l’image hero. Pour une explication détaillée, consultez comment compresser les images sur Shopify.

Utiliser le lazy-loading pour les médias sous la ligne de flottaison

Tout ce qui se trouve sous la ligne de flottaison peut attendre. L’attribut natif loading="lazy" sur une balise <img> indique au navigateur de différer le chargement de cette image jusqu’à ce qu’elle approche du viewport, ce qui réduit le nombre de requêtes en concurrence lors du premier chargement.⁴

Utilisez-le pour les images et les iframes situés plus bas sur la page : photos lifestyle, sections d’avis, logos de bas de page, vidéos intégrées. Ne faites pas de lazy-loading sur l’élément LCP lui-même, car différer le chargement de votre image hero aggravera votre LCP au lieu de l’améliorer.

Pour plus de détails, y compris sur la gestion des vidéos intégrées, consultez comment configurer le lazy-loading des images sur Shopify.

Différer le JavaScript non critique

Le JavaScript est ce qui pénalise le plus l’INP sur mobile, car le processeur plus lent du téléphone met plus de temps à l’exécuter et le thread principal reste bloqué.

Tout ce qui n’est pas nécessaire pour le premier affichage (first paint) ne doit pas le bloquer. Ajoutez l’attribut defer aux scripts afin qu’ils se chargent sans interrompre le rendu, et chargez les widgets non essentiels une fois la page interactive, plutôt que dans le <head>.

Les scripts bloquant le rendu méritent une attention particulière. Consultez comment corriger les scripts qui bloquent le rendu sur Shopify pour plus de détails.

Réduire les scripts d’applications

C’est l’erreur que la plupart des boutiques sous-estiment. Presque chaque application de widget injecte son propre JavaScript dans votre vitrine, et ce script s’exécute sur le téléphone à chaque page. Une dizaine d’applications empilées peut ajouter une charge qu’aucune optimisation d’images ne pourra compenser.

Auditez ce que chaque application vous coûte réellement. Supprimez les applications que vous n’utilisez plus, et pour les fonctionnalités que vous pouvez construire directement dans le thème, préférez du code natif plutôt que d’ajouter une énième balise script. Nous y reviendrons dans la section ci-dessous.

Ajouter du CSS critique et configurer font-display

Deux petites optimisations qui aident lors du premier affichage :

• CSS critique. Intégrez directement (inline) les styles nécessaires au rendu du haut de la page afin que le navigateur puisse afficher les éléments avant même d’avoir récupéré la feuille de style complète.
• font-display: swap. Laissez le texte s’afficher immédiatement avec une police de secours pendant le chargement de la police web, au lieu de laisser un espace vide. Cela évite d’avoir du texte invisible sur une connexion lente.

Empêcher les sauts de mise en page dus aux bannières et aux sections hero

Le CLS est souvent la métrique la plus facile à corriger, car les causes sont structurelles. Les sauts de mise en page sont causés par des éléments qui se chargent tardivement et poussent le contenu vers le bas : une barre d’annonce, une image hero sans espace réservé, un bandeau de cookies, ou un widget d’application injecté tardivement.

Réservez de l’espace pour tout ce qui se charge après le premier affichage. Donnez aux images des attributs width et height explicites pour que le navigateur réserve l’emplacement avant l’arrivée du fichier, et évitez d’insérer des bannières au-dessus d’un contenu qui a déjà été rendu.

Comment tester sur la 3G et les appareils lents

Vous ne pouvez pas juger de la vitesse mobile à partir de votre propre téléphone sur le wifi du bureau. Vous devez simuler les conditions rencontrées par vos acheteurs les plus lents.

Lancez Lighthouse en mode mobile. Dans Chrome DevTools, le panneau Lighthouse simule par défaut un appareil mobile de milieu de gamme avec un processeur et un réseau ralentis. C’est un indicateur bien plus proche de la réalité mobile qu’un test sur ordinateur.

Brider le réseau. Dans l’onglet Network (Réseau) de DevTools, réglez la limitation (throttling) sur un profil lent comme “Slow 3G” (3G lente) et rechargez la page. Cela met en évidence les requêtes qui posent problème sur une connexion à forte latence, ce qu’une connexion rapide dissimule.

Brider le processeur (CPU). Dans l’onglet Performance, appliquez un ralentissement du processeur de 4x ou 6x pour émuler un téléphone bas de gamme. Un JavaScript lourd qui s’exécute instantanément sur votre machine montrera ici son vrai coût, et c’est exactement ce que mesure l’INP.

Vérifiez aussi les données de terrain. Les tests en laboratoire détectent beaucoup de choses, mais Google évalue selon les données de terrain. Surveillez le rapport Core Web Vitals dans la Search Console, qui est segmenté par mobile et ordinateur, afin de confirmer que les visites réelles réussissent le test et pas seulement vos tests en laboratoire.

Testez après chaque modification majeure, surtout après l’installation d’une application. Une application qui semble inoffensive dans l’interface d’administration peut ajouter un poids réel à chaque page.

L’accumulation d’applications est le véritable ennemi de la vitesse sur mobile

S’il y a une seule chose à corriger, c’est celle-ci. Les images et le CSS ont leur importance, mais le frein le plus important et le plus fréquent à la vitesse de Shopify sur mobile est l’empilement d’applications.

Le schéma se répète d’une boutique à l’autre. Chaque application qui ajoute une fonctionnalité visible (une barre collante, un widget d’avis, un pop-up de vente incitative, un sélecteur de devise) embarque généralement son propre JavaScript, et ce script se charge sur le téléphone sur chaque page concernée. Individuellement, chacune semble légère. Mais empilées, elles bloquent le thread principal, retardent l’interactivité et font exploser l’INP.

Les pires élèves provoquent aussi des sauts de mise en page, car ils injectent leur interface après que la page a déjà été rendue, repoussant le contenu et dégradant le CLS.

La solution n’est pas d’accepter cela comme le prix à payer pour avoir des fonctionnalités. Beaucoup de ces fonctionnalités ne nécessitent qu’un peu de code dans le thème. Les développer de manière native, plutôt que d’ajouter une autre application, permet de déployer la fonctionnalité sans l’impact que chaque script externe impose à chaque page. Si votre boutique est déjà lente, commencez par là avant d’ajouter quoi que ce soit de nouveau : comment accélérer un thème Shopify explique comment réaliser cet audit.

La place de Fudge

La manière habituelle d’ajouter une fonctionnalité à une vitrine est d’installer une application, et chaque application installée représente plus de JavaScript sur chaque page, ce qui frappe particulièrement fort sur mobile.

Fudge prend un autre chemin. C’est un éditeur de vitrine IA qui écrit du code de thème natif. Vous décrivez ce que vous voulez, et il écrit le Liquid, le CSS et le JavaScript directement dans votre thème.

Comme le résultat est natif, une fonctionnalité construite avec Fudge ne nécessite pas de charger le widget tiers ou le script supplémentaire d’une application à chaque page. C’est cette différence qui se reflète dans vos Core Web Vitals sur mobile : moins de scripts bloquant le rendu, moins de charge sur le thread principal et aucun widget injecté tardivement causant un saut de mise en page.

Et comme il s’agit du code du thème, il survit à une désinstallation. Tout ce que vous construisez avec l’éditeur de boutique Shopify reste dans votre thème même si vous annulez, contrairement à un élément rendu par une application qui disparaît au moment où vous la supprimez.

FAQ