Comment on a fait passer un PageSpeed mobile de 26 à 70+ sans perdre de trafic
Sommaire
Un score PageSpeed mobile à 26/100, c’est un site qui perd des ventes à chaque chargement de page. C’est le point de départ d’une migration récente : un e-commerce sneakers & streetwear sur thème Shopify classique, alourdi par des années d’apps empilées. Voici comment on est passé de 26 à 70+, sans coupure de trafic ni perte SEO.
Le diagnostic : d’où vient un score à 26
Avant de coder quoi que ce soit, l’audit a porté sur trois sources : GA4 pour le comportement utilisateur, Clarity pour les sessions replay (voir concrètement où les visiteurs abandonnent), et un audit PageSpeed/Lighthouse poste par poste.
Trois causes concentraient l’essentiel de la dégradation :
Les apps tierces en cascade. Chaque app Shopify installée sur un thème classique injecte son propre script, souvent en render-blocking. Sur ce store, une dizaine d’apps actives (reviews, upsell, trust badges, chat) chargeaient en synchrone dès le premier paint. Aucune n’était individuellement lourde : c’est l’empilement qui tue le score.
Le thème Liquid non optimisé pour le mobile. Images non responsive, absence de lazy loading structuré, CSS non critique chargé en bloquant. Rien d’exotique, c’est le lot commun des thèmes achetés puis modifiés pendant des années sans refonte de fond.
L’absence de contrôle sur le rendu. Sur un thème Liquid, on optimise dans les limites de ce que le thème autorise. Impossible d’agir sur l’ordre de chargement des ressources critiques, ni de retirer le JS des apps non utilisées sur certaines pages.
Ce dernier point a tranché la décision : rester sur Shopify Liquid et optimiser à la marge aurait plafonné le gain autour de 45-50. Passer sur Hydrogen headless permettait de repartir d’une page blanche avec un contrôle total sur le rendu.
Les décisions techniques qui ont fait la différence
Rendu server-side sur Oxygen, edge-first. Hydrogen tourne sur Oxygen (l’edge runtime de Shopify), ce qui élimine le temps de cold start qu’on peut avoir sur un hosting classique et rapproche le contenu du visiteur géographiquement.
Remplacement des apps front-end par du code natif. Les fonctionnalités qui justifiaient des apps tierces (reviews, trust badges, cross-sell) ont été réécrites directement dans le storefront Hydrogen, connectées à la Storefront API. Résultat : zéro script tiers bloquant sur les pages produit et catégorie, qui concentrent l’essentiel du trafic.
Cart réactif sans rechargement de page. Le panier Hydrogen s’appuie sur un cart côté edge, mis à jour sans reload complet, ce qui réduit à la fois le temps perçu et la charge réseau à chaque interaction.
Images et fonts optimisées à la source. Formats modernes (WebP/AVIF), dimensionnement responsive strict par breakpoint, et fonts en font-display: swap pour éliminer le flash de texte invisible qui pénalise le CLS (Cumulative Layout Shift).
Priorisation du chargement critique. Seul le CSS nécessaire au premier écran charge en bloquant ; le reste est différé après le First Contentful Paint.
Pourquoi Hydrogen n’est pas automatiquement rapide
C’est le malentendu le plus fréquent sur ce cas : Hydrogen n’a pas « rendu le site rapide ». Hydrogen a rendu possible un travail de performance qu’un thème Liquid chargé d’apps ne permettait plus.
Un storefront headless mal construit peut très bien être plus lent qu’un bon thème Liquid. Les causes classiques :
- un bundle JavaScript qui gonfle au fil des composants React ajoutés ;
- des requêtes Storefront API en cascade, où chaque composant attend la réponse du précédent ;
- des images non dimensionnées, servies sans format moderne ;
- du contenu chargé côté client alors qu’il devrait être rendu côté serveur ;
- des scripts marketing réinjectés un par un après le lancement, exactement comme sur l’ancien thème.
Ce dernier point est le plus sournois. Rien n’empêche, six mois après la migration, de recoller un tag manager, trois pixels et un widget de chat sur toutes les pages. La dette technique ne dépend pas de l’architecture, elle dépend de la discipline qu’on s’impose ensuite.
Autrement dit : le gain sur ce projet vient de la combinaison rendu serveur + suppression des scripts tiers bloquants + optimisation des images et du chargement critique. Le framework a levé le plafond, il n’a pas fait le travail.
La bascule sans perte de trafic
Le risque numéro un d’une migration, ce n’est pas la technique, c’est le SEO pendant la transition. La méthode suivie :
- Audit complet des URLs existantes avant toute ligne de code : structure, données structurées (schema.org), balises canoniques.
- Reproduction à l’identique de la structure d’URLs sur le nouveau storefront : aucune URL cassée, donc aucune redirection nécessaire sur l’essentiel du catalogue.
- Plan de redirections 301 pour les pages réellement supprimées ou fusionnées, testé avant bascule.
- Bascule DNS en heures creuses, avec monitoring Search Console renforcé les 15 jours suivants pour détecter toute erreur d’indexation immédiatement.
Les résultats
| Indicateur | Avant | Après |
|---|---|---|
| PageSpeed mobile | 26 | 70+ |
| Taux de complétion checkout mobile | 28% | 40%+ |
| Trafic organique post-migration | réf. | stable, aucune perte constatée |
Est-ce que le gain PageSpeed améliore automatiquement la conversion ?
Non, et c’est important de le dire précisément, même sur un cas où les deux ont progressé ensemble.
Sur ce projet, le score mobile et le taux de complétion du checkout ont augmenté sur la même période. Mais la migration n’a pas seulement changé la vitesse : elle a aussi changé le parcours d’achat (panier réactif sans rechargement), retiré des widgets qui provoquaient des layout shifts sur la page produit, et remplacé plusieurs composants tiers par des interfaces plus cohérentes. Attribuer la totalité du gain au seul score PageSpeed serait faux.
Ce qu’on peut dire honnêtement :
- la latence mobile est un frein réel et mesurable, particulièrement dans le tunnel d’achat où chaque étape supplémentaire perd des visiteurs ;
- un score qui passe de 26 à 70 supprime un frein, il ne crée pas de la demande : un produit mal positionné ou une offre peu claire ne se corrigent pas avec de la performance ;
- au-delà d’un certain seuil, les gains marginaux de score n’ont plus d’effet perceptible sur le comportement : passer de 70 à 90 ne produit pas le même impact que passer de 26 à 70 ;
- le score Lighthouse est une mesure de laboratoire. Ce qui compte vraiment, ce sont les Core Web Vitals observés sur le terrain, sur les appareils et les réseaux réels de vos visiteurs.
La bonne façon de raisonner est donc de traiter la performance comme une condition d’entrée, pas comme un levier de conversion en soi. Et de continuer à mesurer le tunnel après la bascule, plutôt que de considérer que le sujet est réglé parce que le score est au vert.
Ce qu’il faut retenir
Un score PageSpeed dégradé sur Shopify n’est presque jamais un problème d’un seul facteur : c’est un empilement de compromis pris au fil du temps (une app ici, un widget là) qui devient invisible tant qu’on ne le mesure pas. La bonne nouvelle : c’est réversible, à condition d’avoir un contrôle total sur le rendu, ce qu’un thème Liquid classique ne permettra jamais complètement.
Si votre store est dans cette situation, le parcours de migration Shopify vers Hydrogen détaille comment l’audit initial et la bascule sont menés, palier par palier.