Tu regardes tes chiffres et tu vois que ta conversion mobile est nettement plus basse que ta conversion desktop. Le réflexe est de blâmer le format, l'écran trop petit, l'attention plus courte. Ce sont des facteurs réels, mais ils cachent une cause plus brutale et plus mesurable : ton site est probablement beaucoup plus lent sur mobile que tu ne le crois, parce que tu ne l'as jamais testé dans les conditions de tes vrais visiteurs.
Le piège est simple. Tu développes sur un ordinateur puissant, tu testes sur ton propre téléphone, souvent un modèle récent, en wifi rapide. Ton client, lui, est sur un Android milieu de gamme, en 4G fluctuante, dans le métro. Entre ton appareil de test et le sien, il y a un gouffre de puissance que tu ne ressens jamais. Voici pourquoi ce gouffre tue ta conversion mobile, et comment le mesurer pour de vrai.
Le mécanisme : le processeur mobile est le vrai goulot
Sur mobile, le poids des fichiers n'est qu'une partie du problème. Le vrai goulot, c'est le processeur. Le JavaScript, une fois téléchargé, doit être analysé puis exécuté, et cette opération est entièrement à la charge du processeur de l'appareil. Or le processeur d'un téléphone milieu de gamme est plusieurs fois moins puissant que celui de ta machine de développement. Le même JavaScript qui s'exécute en un clin d'oeil chez toi peut bloquer le fil principal pendant un temps bien réel chez ton visiteur.
C'est pour ça que la performance ne se transfère pas du desktop au mobile. Ce ne sont pas deux versions du même test avec un écran différent, ce sont deux mondes de puissance différents. Un site qui paraît instantané sur ta machine peut ramer sur un appareil modeste, parce que tout le travail que tu ne sens pas, l'analyse et l'exécution du code, s'étire en proportion de la faiblesse du processeur.
Il faut bien comprendre la différence entre un fichier image et un fichier JavaScript de même poids. Une image de cent kilooctets est lourde à télécharger, mais une fois arrivée, l'afficher coûte peu au processeur. Cent kilooctets de JavaScript, c'est l'inverse : le téléchargement n'est qu'un début, ensuite il faut analyser ce code puis l'exécuter, et c'est là que le processeur faible souffre. Sur mobile, un mégaoctet de JavaScript fait bien plus mal qu'un mégaoctet d'images, alors que ton compteur de poids les traite pareil. C'est pour ça qu'on peut avoir une page légère en apparence et lente en réalité, parce que la nature du poids compte autant que sa quantité.
Et c'est précisément sur mobile que se joue la majorité des décisions. La page médiane pèse déjà 2,16 Mo sur mobile selon le Web Almanac 2025 de HTTP Archive, dont une part lourde de JavaScript à exécuter sur ces processeurs faibles, ce que les Server Components permettent justement d'alléger. Tu sers donc de plus en plus de code à exécuter, à des appareils de moins en moins capables de l'absorber vite. L'écart se creuse au mauvais endroit.
La prise de position : ta performance desktop est un mensonge confortable
Je vais être direct. Le score de performance que tu regardes, mesuré sur ta machine ou en mode desktop, est un mensonge confortable sur l'expérience de la majorité de tes visiteurs. Il te rassure pendant que tes vrais utilisateurs, sur mobile, vivent autre chose. Et comme c'est sur mobile que beaucoup décident, ce mensonge te coûte directement de la conversion, parce que la vitesse mobile est un levier CRO de premier plan.
Donc je le pose. Tester la performance sur son propre appareil récent, c'est ne rien tester du tout. C'est se regarder dans un miroir flatteur. La seule mesure qui compte est celle d'un appareil représentatif de ton public, dans des conditions réseau réalistes. Tant que tu ne fais pas ça, tu optimises pour un utilisateur qui n'existe pas, toi.
Teardown : le piège de l'appareil de test
Le scénario que je vois sans cesse, et que je dois moi même éviter sur mes produits, est toujours le même.
- Ce qui se passe. Le développeur teste sur son iPhone récent en wifi de bureau. Tout est fluide, le site paraît rapide, le score est bon. La version mobile est validée sur cette base. Mais cet appareil et cette connexion ne ressemblent en rien à ceux de la majorité du public.
- Ce qu'il faudrait faire. Mesurer en bridant le processeur, ce que permettent les outils du navigateur, pour simuler un appareil modeste, et en bridant le réseau pour simuler une 4G moyenne. Et idéalement, garder un vrai téléphone milieu de gamme bon marché à portée, et tester dessus pour de vrai. C'est là que la vérité apparaît, souvent brutale.
La leçon, c'est que la fluidité sur ton appareil ne prouve rien. Elle prouve juste que ton appareil est puissant. Le test n'a de valeur que s'il reproduit la faiblesse de l'appareil de ton visiteur, pas la force du tien.
L'artefact : la checklist pour mesurer ce que vit vraiment ton visiteur
- Bride le processeur dans tes outils. Les outils de développement du navigateur permettent de ralentir le processeur d'un facteur quatre à six. Active ça à chaque test mobile. C'est le réglage le plus révélateur, parce qu'il simule le vrai goulot.
- Bride le réseau. Simule une 4G moyenne, pas ton wifi. Le téléchargement plus lent change l'ordre d'arrivée des ressources et révèle des problèmes invisibles en connexion rapide.
- Garde un vrai appareil modeste. Un Android d'entrée ou de milieu de gamme, gardé pour les tests. Rien ne remplace l'expérience réelle sur le matériel que tes visiteurs utilisent vraiment.
- Regarde le terrain, pas le labo. Tes métriques de terrain, segmentées mobile contre desktop, te disent ce que vivent tes vrais utilisateurs. Si l'écart mobile est large, c'est ta priorité, pas un détail.
Où tu commences : ouvre ta page principale, active le bridage processeur à six fois plus lent, et recharge. Ce que tu vois alors est plus proche de la réalité de ton visiteur que tout ce que tu avais mesuré avant.
Ce qu'il faut retenir
Ta conversion mobile n'est pas basse seulement à cause de l'écran, elle est basse parce que ton site est plus lent sur mobile que tu ne le crois, et que tu ne l'as jamais testé dans les conditions de tes vrais visiteurs. Le processeur d'un téléphone modeste est le vrai goulot, et ta machine de développement te cache cet écart. Bride le processeur et le réseau dans tes tests, garde un appareil d'entrée de gamme à portée, allège en priorité ce qui pèse le plus sur mobile, et regarde tes métriques de terrain segmentées par appareil. Active dès aujourd'hui le bridage processeur à six fois plus lent sur ta page principale, et regarde la vérité. Si tu veux savoir ce que ton SaaS fait vraiment vivre à tes visiteurs mobiles, c'est ce que je mesure dans un diagnostic de performance.