Pourquoi les scores sur mobile et ordinateur sont différents
Si vous avez déjà géré votre boutique Shopify via PageSpeed Insights, vous avez vu l'écart : votre score sur ordinateur peut se situer dans les années 80 ou 90 tandis que votre score sur mobile languit dans les années 30 ou 40. Ce n'est pas un bug, c'est intentionnel.
Google teste les mobiles et les ordinateurs de bureau sous conditions complètement différentes. Le test mobile simule un smartphone de milieu de gamme avec une puissance de traitement limitée et une connexion réseau lente. Le test de bureau utilise la pleine vitesse du processeur et votre connexion réelle.
📱 Conditions de test mobile
- ● CPU: Ralentissement 4x (simule un téléphone de milieu de gamme)
- ● Réseau : 4G étranglée (~ 1,6 Mbps, 150 ms RTT)
- ● Fenêtre : 412 x 823px (mobile typique)
- ● Appareil : Puissance Moto G simulée
🖥️ Conditions de test sur ordinateur
- ● CPU: Pas de limitation (pleine vitesse)
- ● Réseau : Pas de limitation (vitesse réelle)
- ● Fenêtre : 1350 x 940px (bureau typique)
- ● Appareil : Ordinateur de bureau/ordinateur portable moderne
Le résultat ? Exactement la même page, même code, mêmes actifs — testé dans des conditions très différentes. Un fichier JavaScript analysé en 200 ms sur un ordinateur de bureau prend 800 ms sur le processeur mobile limité. Une image téléchargée en 100 ms sur votre haut débit prend 500 ms sur une 4G simulée.
C'est pourquoi un écart de 30 à 50 points entre les appareils mobiles et les ordinateurs de bureau est tout à fait normal pour les boutiques Shopify. Cela ne signifie pas que votre boutique est en panne sur mobile, cela signifie que le test mobile de Google est délibérément sévère. Vous voulez vérifier votre écart ? Exécutez un test de vitesse gratuit sur votre boutique.
La solution facile : augmentez instantanément les deux scores
Avant de plonger dans les optimisations mobiles manuelles, il existe un moyen plus rapide. Thunder Page Speed Optimizer améliore considérablement les scores mobiles en abordant les facteurs exacts que le test mobile de Google pénalise le plus.
Pourquoi Thunder frappe plus fort sur mobile : Le report de script
réduit la charge du processeur
Le JS non critique est différé — impact massif sur les processeurs mobiles limités
CSS critique pour Fast First Paint
Chargements CSS au-dessus de la ligne de flottaison en ligne — aucune requête bloquant le rendu sur les réseaux lents
Optimisation des polices
Précharge et optimise la livraison des polices pour réduire le LCP mobile
Priorisation des ressources mobiles d'abord
Donne la priorité aux ressources les plus importantes pour le rendu mobile
Amélioration mobile moyenne : +27 points PageSpeed
Parce que le mobile est plus sensible au JavaScript et aux ressources bloquant le rendu, les optimisations de Thunder ont un impact démesuré sur les scores mobiles.
Plan gratuit disponible · Aucune carte de crédit requise · Configuration en 30 secondes · Fonctionne avec tous les thèmes
Comment Google teste Mobile vs Desktop (en détail)
PageSpeed Insights utilise Lighthouse sous le capot. Voici exactement ce qui se passe différemment entre les tests sur mobile et sur ordinateur :
| Facteur | Test mobile | Test de bureau | Impact |
|---|---|---|---|
| Limitation du processeur | Ralentissement 4x | Aucun | L'exécution JS prend 4 fois plus de temps lors du test mobile |
| Vitesse du réseau | ~1,6 Mbit/s (4G) | Pas de limitation | Les ressources prennent plus de temps à télécharger sur mobile |
| Latence du réseau | 150 ms RTT | ~40 ms RTT | Chaque requête entraîne plus de surcharge sur mobile |
| Largeur de la fenêtre | 412px | 1350px | Différentes mises en page réactives, tailles d'image |
| Agent utilisateur | Mobile Chrome | Bureau Chrome | Peut déclencher différentes réponses du serveur |
| Poids de notation | TBT : 30%, LCP : 25% | Mêmes poids | Même formule, mais la limitation amplifie les problèmes |
Le La limitation du processeur est le facteur le plus important. Le temps de blocage total (TBT) – qui mesure la durée pendant laquelle le thread principal est bloqué par JavaScript – compte pour 30 % du score PageSpeed. Avec un ralentissement du processeur 4x, chaque milliseconde d'exécution JS devient quatre. Un script qui bloque pendant 150 ms sur le bureau bloque pendant 600 ms sur le test mobile.
💡 Aperçu clé : Cela signifie que l'optimisation JavaScript a 4x plus d'impact sur votre partition mobile que sur votre partition ordinateur. Chaque kilo-octet de JS que vous reportez ou supprimez vous rapporte plus sur mobile que sur ordinateur. C'est exactement pourquoi le report des scripts de Thunder a un effet si dramatique sur les scores mobiles.
Pourquoi la vitesse mobile est plus importante pour le référencement
Depuis 2019, Google utilise indexation mobile-first pour tous les nouveaux sites internet, et depuis 2021, il s'applique à l'ensemble du web. Cela signifie :
- Google explore et indexe principalement les version mobile de votre site
- Mobile Core Web Vitals sont le principal signal pour l'amélioration du classement
- Si le contenu existe uniquement sur ordinateur (pas dans la vue mobile), Google ne peut pas l'indexer
Au-delà du référencement, vos données de trafic confirment probablement pourquoi le mobile est important : over 70% of Shopify store traffic typically comes from mobile devices. Votre expérience mobile est l'expérience par défaut pour la plupart de vos clients.
70%+
du trafic Shopify est mobile
53%
of mobile users leave if load > 3s
100%
des sites utilisent l'indexation mobile first
L'essentiel : si vous devez choisir entre l'optimisation pour mobile ou ordinateur, choisissez toujours mobile. Les améliorations sur mobile améliorent presque toujours le bureau (mais pas l’inverse). Pour une perspective SEO plus large sur la vitesse, consultez notre Guide des éléments essentiels du Web.
Le problème JavaScript sur mobile
JavaScript est la première raison pour laquelle les scores sur mobile sont inférieurs à ceux sur ordinateur. Voici pourquoi cela frappe tellement plus fort sur mobile :
Temps d'analyse
Avant que JavaScript puisse s'exécuter, le navigateur doit l'analyser. Avec une limitation du processeur 4x, un bundle JS de 500 Ko qui analyse en 100 ms sur le bureau prend 400 ms sur le test mobile. Les thèmes Shopify contiennent généralement entre 200 et 600 Ko de JavaScript.
Temps d'exécution
Chaque gestionnaire d'événements, routine d'initialisation et script tiers prend 4 fois plus de temps à s'exécuter. Les scripts d'application qui semblent instantanés sur le bureau deviennent des retards notables sur mobile.
Concours de fil principal
Sur mobile, le thread principal gère l'exécution, la mise en page, la peinture et la saisie utilisateur JS. Avec un processeur limité, ces tâches entrent en concurrence de manière plus agressive, ce qui entraîne un temps de blocage total plus long et un INP pire.
Ce que vous pouvez faire
- Différer le JavaScript non critique : Chargez des analyses, des widgets de discussion et des scripts de révision après le rendu initial. Il s'agit de la principale optimisation de Thunder.
- Supprimez les applications inutilisées : Chaque application frontale ajoute JavaScript. Auditez les applications que vous n’utilisez pas et désinstallez-les.
- Utilisez du JavaScript moderne :
Modules ES avec
type="module"sont analysés plus efficacement par les navigateurs modernes. - Répartition des codes : Ne chargez pas le JavaScript de la page produit sur les pages de collection et vice versa.
Pour des techniques d'optimisation JavaScript détaillées, consultez notre guide pour correction des ressources bloquant le rendu et gestion des scripts tiers.
Images réactives : la plus grande victoire mobile
Après JavaScript, les images sont le deuxième contributeur à l'écart de vitesse entre les appareils mobiles et les ordinateurs de bureau. Sans images réactives, votre téléphone mobile télécharge la même image de héros massive que votre bureau affiche en pleine largeur – un énorme gaspillage sur une fenêtre d'affichage de 412 pixels de large.
Utilisez les images réactives intégrées de Shopify
Le CDN de Shopify sert automatiquement les images dans des formats modernes (WebP/AVIF) et peut les redimensionner à la volée. Utilisez le
Filtre image_url
Filtre avec image_tag
Le filtre pour générer des attributs srcset réactifs :
{{ product.featured_image | image_url: width: 1200 | image_tag:
widths: '200,400,600,800,1000,1200',
sizes: '(max-width: 768px) 100vw, 50vw',
loading: 'lazy'
}}Ceci indique au navigateur : "Sur mobile (moins de 768 px), cette image remplit toute la largeur de la fenêtre d'affichage, alors téléchargez une version d'environ 400 px. Sur ordinateur, elle remplit la moitié de la fenêtre d'affichage, donc téléchargez une version d'environ 600 à 700 px." La différence peut être énorme : une image de 1 200 pixels peut faire 150 Ko, tandis qu'une version de 400 pixels ne fait que 25 Ko.
Optimisation de l'image du héros
Votre image de héros est généralement votre élément LCP – le plus grand élément de contenu qui détermine votre score le plus grand de Contentful Paint. Sur mobile, cette image nécessite une attention particulière :
- Utilisez différents recadrages d'images pour mobile : Une large bannière de bureau recadrée sur mobile perd de son impact. Considérons un héros mobile distinct et plus grand.
- Précharger l'image LCP mobile : Ajoutez un indice de préchargement pour la taille de l'image mobile afin d'accélérer LCP.
- Ne chargez pas le héros paresseusement : L'image du héros devrait se charger avec impatience (
chargement="impatient") puisqu'il est au-dessus du pli. - Utilisez fetchpriority="high": Dites au navigateur de donner la priorité au téléchargement de l'image du héros par rapport aux autres ressources.
Pour un manuel complet d'optimisation d'image, consultez notre Guide d'optimisation des images Shopify.
Optimisations spécifiques aux mobiles pour Shopify
Au-delà du JavaScript et des images, voici des optimisations qui ciblent spécifiquement les performances mobiles :
Réduire la taille du DOM sur mobile
De nombreux thèmes Shopify affichent des éléments en double : un menu de bureau ET un menu mobile, tous deux toujours dans le DOM. Sur mobile, masquez les éléments du bureau avec
Affichage : aucun — mais mieux encore, enveloppez-les dans un état liquide ou utilisez-les visibilité du contenu : auto afin que le navigateur puisse ignorer complètement ses calculs de mise en page.
Réduire le contenu au-dessus de la ligne de flottaison sur mobile
Les fenêtres mobiles affichent moins de contenu au-dessus de la ligne de flottaison (hauteur de 823 px contre 940 px, et la majeure partie est occupée par l'en-tête et le héros). Simplifiez votre mobile au-dessus de la ligne de flottaison : une image de héros, un titre, un CTA. Moins de contenu = moins de rendu = LCP plus rapide.
Réduire le nombre de fichiers de polices
Chaque fichier de police est une requête réseau supplémentaire, ce qui fait plus mal sur la 4G étranglée. N'utilisez pas plus de 2 familles de polices avec 2 à 3 épaisseurs chacune. Pensez à utiliser des polices système pour le corps du texte et à charger uniquement une police personnalisée pour les titres. Cela permet d'économiser 100 à 300 Ko et d'éliminer les changements de disposition par échange de polices.
Préconnexion aux origines critiques
Avec 150 ms RTT sur le test mobile, chaque nouvelle connexion serveur ajoute une latence importante. Ajoutez des conseils de préconnexion pour vos domaines externes les plus importants :
<link rel="preconnect" href="https://cdn.shopify.com" crossorigin>
<link rel="preconnect" href="https://fonts.shopifycdn.com" crossorigin>Utiliser les requêtes multimédias CSS pour les styles mobiles uniquement
Ne transmettez pas de CSS réservé aux ordinateurs de bureau aux navigateurs mobiles. Utiliser
Média Attributs sur les balises de lien afin que les navigateurs mobiles puissent donner la priorité au CSS mobile et différer les styles de bureau.
Gestion des événements tactiles et INP sur mobile
Les appareils mobiles utilisent des événements tactiles au lieu des clics de souris, ce qui introduit des fonctionnalités uniques. Défis INP:
Le délai de prise de 300 ms (problème hérité)
Les anciens navigateurs ajoutaient un délai de 300 ms après un appui pour détecter les doubles appuis. Les navigateurs modernes éliminent cela si votre page inclut avec largeur = largeur de l'appareil – que tous les thèmes Shopify incluent. Mais certains scripts d’applications plus anciens peuvent ajouter des écouteurs d’événements tactiles qui réintroduisent des retards.
Écouteurs tactiles passifs
Événements tactiles qui n'appellent pas empêcheDefault() doit être marqué comme passif : vrai. Cela permet au navigateur de commencer le défilement immédiatement au lieu d'attendre de voir si le gestionnaire annule le défilement. De nombreuses anciennes applications Shopify ne le font pas.
Dimensionnement de la cible tactile
Google recommande que les cibles tactiles mesurent au moins 48 x 48 px avec un espacement de 8 px. Des cibles trop petites entraînent des erreurs de saisie et de la frustration – ce n'est pas un problème de vitesse direct, mais cela affecte la réactivité perçue de votre magasin.
PageSpeed Insights signale les auditeurs tactiles non passifs et les cibles tactiles sous-dimensionnées. Les corriger améliore à la fois votre score et la véritable expérience mobile. Pour en savoir plus sur l'optimisation spécifique aux mobiles, consultez notre guide d'optimisation de la vitesse mobile.
Objectifs de score mobile réalistes pour Shopify
Ne recherchez pas un parfait 100 sur mobile : c'est pratiquement impossible pour une vraie boutique Shopify avec des applications, des analyses et un contenu de produits riche. Voici des objectifs réalistes :
| Type de magasin | Cible mobile réaliste | Cible de bureau | Remarques |
|---|---|---|---|
| Magasin minimal (1 à 2 applications) | 60–80 | 90–98 | Thème Dawn, personnalisation minimale |
| Magasin moyen (3 à 5 applications) | 45–65 | 80–92 | Thème Premium, avis + analyses |
| Boutique riche en fonctionnalités (6+ applications) | 35–55 | 70–88 | Thème personnalisé, nombreuses applications frontales |
| Boutique d'entreprise (10+ applications) | 25–45 | 60–80 | Personnalisation complexe, intégrations ERP |
N'oubliez pas : The PageSpeed score is a synthetic benchmark. What actually matters for SEO and conversions are the Core Web Vitals (LCP, CLS, INP) from real user data. A store scoring 40 on mobile but passing all Core Web Vitals in the field is in a better position than a store scoring 60 but failing INP.
Pour plus de contexte sur la signification de votre score, consultez nos guides sur Benchmarks de vitesse Shopify et comprendre PageSpeed Insights. Prêt à optimiser ? Commencez par notre guide d'optimisation complet.
Foire aux questions
Pourquoi mon score de vitesse Shopify sur mobile est-il tellement inférieur à celui sur ordinateur ?
Google PageSpeed Insights teste le mobile avec une limitation agressive : ralentissement du processeur 4x pour simuler un téléphone de milieu de gamme et réseau limité pour simuler les conditions 4G. Les tests sur ordinateur utilisent votre vitesse de connexion réelle et la pleine puissance du processeur. Cela signifie que JavaScript qui s'exécute en 200 ms sur un ordinateur de bureau peut prendre plus de 800 ms sur l'appareil mobile simulé. La même page avec le même code obtiendra toujours un score inférieur sur mobile – généralement 20 à 40 points de moins.
Google utilise-t-il les scores mobiles ou de bureau pour le classement SEO ?
Google uses mobile-first indexing, meaning the mobile version of your site is what Google primarily crawls and uses for ranking. Core Web Vitals from mobile field data (real Chrome users on mobile devices) are the ranking signal. This makes mobile performance more important for SEO than desktop. However, Google evaluates Core Web Vitals (LCP, CLS, INP) separately for mobile and desktop — your desktop pages are ranked using desktop metrics and vice versa.
Quel appareil mobile Google PageSpeed Insights simule-t-il ?
PageSpeed Insights utilise Lighthouse, qui simule un Moto G Power de milieu de gamme (ou équivalent) avec une limitation du processeur 4x sur une connexion 4G étranglée (~ 1,6 Mbps de téléchargement, 150 ms RTT). C’est intentionnellement dur – cela représente l’expérience des utilisateurs disposant d’appareils moyens et non haut de gamme. Les performances mobiles réelles de vos clients dépendent de leurs appareils et connexions réels, c'est pourquoi les données de terrain (CrUX) sont plus importantes que les résultats de laboratoire.
Dois-je d'abord optimiser la vitesse des appareils mobiles ou des ordinateurs de bureau ?
Optimize for mobile first. Since Google uses mobile-first indexing, your mobile Core Web Vitals directly impact rankings. Additionally, over 70% of Shopify traffic is typically from mobile devices. If your mobile speed is good, your desktop speed will almost always be good too — the reverse isn't true. Focus on reducing JavaScript execution time, optimizing images for mobile viewports, and ensuring fast LCP on smaller screens.
Puis-je avoir des scores PageSpeed différents pour mobile et ordinateur ?
Oui – et vous le ferez presque certainement. Il est extrêmement courant qu'une boutique Shopify obtienne un score de 35 sur mobile et de 85 sur ordinateur. L'écart de 30 à 50 points est normal et causé par les différentes conditions de test (limitation du processeur, simulation de réseau, taille de la fenêtre d'affichage). Ne paniquez pas à propos d'un faible score mobile si le score de votre ordinateur est sain : l'écart indique une surcharge JavaScript normale, et non un site en panne.
Comment les images réactives affectent-elles la vitesse des mobiles par rapport aux ordinateurs de bureau ?
Les images réactives (utilisant les attributs srcset et size) permettent au navigateur de télécharger des images de taille appropriée pour chaque appareil. Sans eux, un téléphone mobile télécharge la même image de héros de 2 000 pixels de large qu'un moniteur de bureau, ce qui gaspille de la bande passante et augmente le LCP de quelques secondes. Le filtre Liquid image_url de Shopify prend en charge le dimensionnement réactif et la plupart des thèmes modernes implémentent automatiquement srcset. Il s’agit de l’une des plus grandes victoires pour réduire l’écart de vitesse entre les appareils mobiles et les ordinateurs de bureau.