Shopify Mobile Speed: How to Optimise for Slow Phones and Networks

Points clés

• La vitesse sur mobile de Shopify est un problème différent de celui sur ordinateur. Les téléphones ont des processeurs plus lents et utilisent des réseaux variables, et c’est sur mobile que se font 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 75e 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 des médias sous la ligne de flottaison, le report (defer) du JavaScript non critique et la réduction des scripts d’applications.
• Les scripts d’applications sont l’une des causes de ralentissement les plus courantes sur mobile. Chaque application de widget injecte son propre JavaScript sur chaque page, et cela s’exécute aussi sur le téléphone.
• Fudge écrit du code de thème natif léger au lieu d’ajouter une énième application de widget, de sorte qu’une fonctionnalité est déployée sans la taxe de script qu’une application impose à chaque chargement de page.

Optimiser la vitesse sur mobile de Shopify n’est pas le même travail que sur ordinateur. Une page qui semble instantanée sur un ordinateur portable avec la fibre peut ramer sur un téléphone de milieu de gamme avec un réseau mobile instable. Et comme la majorité du trafic et des paiements Shopify se font sur téléphone, c’est la version mobile qui décide réellement de vos revenus.

Ce guide explique pourquoi le mobile est plus difficile, quels Core Web Vitals Google évalue, les tactiques concrètes pour réduire les problèmes de vitesse des pages sur mobile, et comment tester l’expérience de vos acheteurs les plus lents sur la boutique.

Pourquoi vous pouvez nous faire confiance

Jacques a plus de 15 ans d’expérience en développement et a travaillé sur les performances de centaines de boutiques Shopify. Nous créons Fudge, l’opérateur IA pour les boutiques Shopify, noté 4.9 sur le Shopify App Store. Nous travaillons donc sur la même couche de thème que celle où réside la vitesse mobile et nous voyons ce qu’une pile d’applications surchargée fait à un téléphone.

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

Le même thème s’exécute sur les deux, mais les conditions ne sont pas les mêmes.

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

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

C’est sur mobile que se trouve l’argent. Pour la plupart des boutiques Shopify, le mobile représente la majorité des sessions et des commandes. C’est pourquoi le chemin de rendu mobile est celui sur lequel il vaut la peine de concentrer vos efforts en premier.

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é et une connexion lente, car cela correspond à une grande partie des vrais acheteurs.

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

Les signaux d’expérience de page de Google reposent sur les Core Web Vitals. Il y en a trois, et l’INP a remplacé le First Input Delay en tant que Core Web Vital en mars 2024.¹

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

Pourquoi les données de terrain sur mobile sont déterminantes

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 l’élément le plus lourd sur une page produit ou collection, et les téléphones n’ont pas besoin de fichiers de la taille 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 du CDN à la largeur que vous demandez, et le CDN sert automatiquement un format moderne comme WebP ou AVIF lorsque le navigateur le prend en charge.²

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 plus petite source qui reste nette, ce qui évite à un téléphone de charger une image de 2000px dans un emplacement de 400px.³

Le gain de LCP le plus rapide sur mobile consiste généralement à réduire la taille de l’image hero. Pour le guide complet, voir 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.

Ajouter du CSS critique et configurer font-display

Deux petites victoires qui aident au premier affichage (first paint) :

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

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

Le CLS est souvent le signal le plus facile à corriger, car les causes sont structurelles. Les sauts de mise en page proviennent d’é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 avis de cookies, 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 des réseaux et appareils lents

Vous ne pouvez pas juger de la vitesse sur mobile depuis votre propre téléphone sur le Wi-Fi du bureau. Vous devez simuler les conditions que rencontrent vos acheteurs les plus lents.

Exécutez Lighthouse en mode mobile. Dans Chrome DevTools, le panneau Lighthouse utilise par défaut un appareil mobile simulé de milieu de gamme avec un processeur et un réseau bridés. C’est une bien meilleure approximation du mobile réel qu’un test sur ordinateur.

Bridez le réseau. Dans l’onglet Network (Réseau) des DevTools, réglez la limitation (throttling) sur un profil lent tel que “Slow 4G” ou “3G” et rechargez la page. Cela expose les requêtes qui posent problème sur une connexion à forte latence, ce qu’une connexion rapide cache.

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

Vérifiez aussi les données de terrain. Les tests en laboratoire repèrent beaucoup de choses, mais Google note sur 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 vraies visites réussissent le test et pas seulement vos analyses en labo.

Testez après chaque changement significatif, en particulier après l’installation d’une application. Une application qui semble inoffensive dans l’admin peut ajouter un poids réel à chaque page.

Comment la surcharge d’applications ralentit Shopify sur mobile

Les images et le CSS sont importants, mais l’un des freins les plus courants à la vitesse de Shopify sur mobile est la pile d’applications. La plupart des boutiques la sous-estiment : une pile d’une douzaine d’applications peut ajouter un poids qu’aucune optimisation d’image ne pourra compenser.

Le schéma se répète d’une boutique à l’autre. Chaque application qui ajoute une fonctionnalité visible (une barre fixe, un widget d’avis, une popup d’upsell, un sélecteur de devises) embarque généralement son propre JavaScript, et ce script se charge sur le téléphone sur chaque page concernée. Prises individuellement, elles semblent légères. Mais empilées, elles bloquent le thread principal, retardent l’interactivité et font exploser l’INP.

Les pires d’entre elles provoquent également des sauts de mise en page, car elles injectent leur interface après que la page a déjà été affichée, poussant le contenu et nuisant au CLS.

La solution n’est pas de l’accepter comme le prix à payer pour avoir des fonctionnalités. Auditez ce que chaque application coûte réellement et supprimez celles que vous n’utilisez plus. Beaucoup des fonctionnalités restantes représentent une petite quantité de code de thème. Les coder nativement, au lieu d’ajouter une autre application, signifie que la fonctionnalité est déployée sans la taxe de script par 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 détaille l’audit.

Où Fudge intervient

La méthode habituelle pour ajouter une fonctionnalité à la vitrine est d’installer une application, et chaque application installée représente plus de JavaScript sur chaque page, ce qui impacte lourdement le mobile.

Fudge emprunte l’autre voie. C’est l’opérateur IA pour les boutiques Shopify, et il é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 sous forme de brouillon que vous prévisualisez sur votre téléphone avant de publier.

Puisque le résultat est natif, une fonctionnalité que vous créez avec Fudge ne comporte pas de widget tiers ni de script supplémentaire chargé sur chaque page par une application. C’est la différence qui se reflète dans vos Core Web Vitals sur mobile : moins de scripts bloquant le rendu, moins de travail sur le thread principal et aucun widget injecté tardivement causant des sauts de mise en page.

Et parce que c’est du code de thème, il survit à une désinstallation. Quoi que vous construisiez 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 dès que vous la supprimez.

Fudge peut également trouver les points de lenteur en premier. Demandez-lui un audit de vitesse et il listera ce qui alourdit vos pages, puis préparera les correctifs que vous pourrez approuver, y compris le code que les applications désinstallées laissent souvent derrière elles dans votre thème.

FAQ