Magento lent sur mobile ? Voici pourquoi Hyvä le corrige

Magento sur mobile est lent. Ce n'est pas subjectif. Le magasin Magento Luma par défaut obtient généralement entre 30 et 55 sur la performance mobile Lighthouse, bien en dessous du seuil "bon" de 90 de Google et loin de ce dont la conversion a besoin.

Les raisons sont spécifiques et bien comprises. La solution est également spécifique : remplacer la couche de rendu frontend. C'est exactement ce que fait Hyvä. Cet article est le "pourquoi c'est lent" technique + "ce que Hyvä change."

Pourquoi Magento par défaut est lent sur mobile, en cinq couches

1. La charge JavaScript

Magento par défaut expédie plusieurs mégaoctets de JavaScript par page. Les plus grands contributeurs :

• Knockout.js (~25KB gzippé, plus des dizaines de modèles de vue)
• RequireJS (~20KB gzippé, plus les frais généraux de chargement différé)
• Composants UI de Magento, un système réactif lourd superposé à Knockout
• jQuery (~30KB gzippé, encore utilisé dans les modèles Luma)
• Tous les composants UI par page pour le panier, le mini-panier, le sélecteur d'adresse, etc., ceux-ci se chargent sur chaque page que vous les utilisiez ou non

Même après compression, la charge JS atterrit généralement entre 2 et 4 Mo sur PDP, PLP, panier et paiement. Sur un Android de milieu de gamme avec une connexion 4G lente, le temps de parsing JavaScript seul (oubliez le téléchargement, juste le parsing du JS) peut prendre 3 à 6 secondes.

2. Le modèle de blocage de rendu

RequireJS est un système de chargement de modules asynchrone. En pratique sur Magento, la séquence de démarrage est :

1. Le navigateur analyse le HTML
2. Le navigateur voit le script de démarrage RequireJS de Magento
3. RequireJS lance des requêtes pour l'arbre de dépendance
4. Chaque dépendance charge d'autres dépendances
5. Finalement, la page devient interactive

Le résultat : Le premier affichage de contenu est correct, mais le temps pour interagir est terrible car la page ne peut pas répondre aux clics tant que l'arbre de dépendance RequireJS ne se résout pas.

3. Les frais généraux du modèle de vue de Knockout

Chaque élément interactif sur une page Luma, icône de mini-panier, menu déroulant d'adresse, sélecteur de variante de produit configurable, a un modèle de vue Knockout attaché. Au chargement de la page, chaque modèle de vue doit s'initialiser et se lier à sa cible DOM.

C'est acceptable sur desktop. Sur mobile, le temps cumulé de parsing + de liaison pour des dizaines de modèles de vue ajoute 1 à 3 secondes au temps d'interaction même sur une page propre.

4. Poids HTML rendu par le modèle

Les modèles Luma de Magento produisent un HTML lourd, avec de nombreux divs enveloppants, un DOM profondément imbriqué, des noms de classes étendus. Un PDP typique pèse entre 200 et 400 Ko d'HTML avant que les images de produit ne se chargent. Sur 4G, ce n'est pas catastrophique ; sur une connexion mobile instable, c'est douloureux.

5. L'amplificateur de balises tierces

C'est le secret sale. Même un site Luma bien optimisé s'effondre lorsque l'équipe marketing ajoute :

• Google Tag Manager chargeant 8 à 15 balises tierces
• Hotjar / Microsoft Clarity pour l'enregistrement de session
• Yotpo / Trustpilot pour les avis
• Klaviyo / Bloomreach pour l'automatisation marketing
• Widgets de chat (Intercom, Zendesk, etc.)

Chacune de ces balises ajoute une charge JS + un blocage de rendu + du travail sur le thread principal. Sur Luma, le tirage cumulatif des balises tierces est souvent pire que le JavaScript expédié avec Magento lui-même.

Hyvä ne corrige pas magiquement les balises tierces, mais la base plus légère de Hyvä vous donne plus de marge avant que le tirage des tiers n'abaisse les performances en dessous des seuils.

Ce que Hyvä change, couche par couche

1. Charge JavaScript : réduction d'environ 5x

Hyvä remplace Knockout + RequireJS + Composants UI par Alpine.js. Alpine fait environ 15 Ko gzippé. La charge totale de JS sur une page Hyvä typique se situe entre 400 et 700 Ko, soit une réduction de 5x par rapport à Magento par défaut.

La réduction ne se limite pas à une taille de bundle plus petite. Alpine n'a pas le problème de démarrage de l'arbre de dépendance de RequireJS, il analyse les attributs HTML en ligne. Le temps d'interaction s'effondre de "après la résolution de RequireJS" à "après que le navigateur ait analysé le HTML."

2. Modèle de rendu : rendu côté serveur, pas lié au JS

Hyvä s'appuie fortement sur l'HTML rendu côté serveur. La plupart du contenu de la page se trouve dans la réponse HTML, pas ajouté par JavaScript après le chargement de la page. La réactivité d'Alpine est pour l'interactivité (clics, états de survol, menus déroulants), pas pour le rendu du contenu initial.

Sur mobile, cela signifie que le premier affichage de contenu et le plus grand affichage de contenu se produisent tous deux de manière beaucoup plus rapide car ils n'attendent pas que JavaScript remplisse le DOM.

3. Modèles de vue Knockout : disparus

Il n'y a pas de modèles de vue Knockout. Il y a des composants Alpine, mais ils font un dixième de la taille des modèles de vue Knockout équivalents et n'ont pas les frais généraux de démarrage. L'icône du mini-panier se met à jour parce qu'Alpine se déclenche sur un événement personnalisé ; pas parce qu'une souscription Knockout se déclenche après qu'une dépendance requirejs se soit résolue.

4. HTML de modèle : plus propre, plus léger

Les modèles Hyvä utilisent des classes utilitaires Tailwind au lieu des noms de classes LESS-BEM. Cela donne des chaînes de classes légèrement plus lisibles dans l'HTML mais drastiquement moins de divs enveloppants car Tailwind compose des mises en page en ligne plutôt que de s'appuyer sur des composants enveloppants imbriqués. L'HTML typique de Hyvä est 30 à 50 % plus léger que l'HTML Luma équivalent pour la même sortie visuelle.

5. Balises tierces : plus de marge

Hyvä ne change pas le fonctionnement des balises tierces, mais la base Magento plus légère signifie que vous avez plus de budget de performance pour le tirage des tiers avant de franchir le seuil de 90 de Lighthouse. En pratique : un site Luma à 55 sur Lighthouse pourrait tomber à 35 lorsque le marketing ajoute trois balises GTM. Un site Hyvä à 92 sur Lighthouse pourrait tomber à 85 avec les mêmes balises, restant toujours dans le territoire vert.

Chiffres de performance typiques

Pour une comparaison Luma → Hyvä dans le même magasin :

Métrique	Luma typique	Hyvä typique
Performance mobile Lighthouse	30–55	80–92
Plus grand affichage de contenu (LCP)	4.0–7.0 s	1.5–2.5 s
Interaction au prochain affichage (INP)	400–900 ms	100–300 ms
Décalage de mise en page cumulatif (CLS)	0.15–0.40	0.00–0.10
Temps de blocage total (TBT)	1500–4000 ms	100–400 ms
Charge JavaScript (par page, gzippé)	2.0–4.0 Mo	400–700 Ko
Temps d'interaction (TTI)	6–12 s	2–4 s

Ce sont des plages typiques à travers les migrations Hyvä que nous avons mesurées. Vos chiffres dépendront du nombre d'extensions, du nombre de balises tierces et de la qualité de la configuration Magento précédente.

Ce que Hyvä ne corrige pas

L'honnêteté est importante. Hyvä est un échange de frontend. Il n'aide pas avec :

• Réponse lente du backend Magento (TTFB). Si votre serveur Magento est sous-dimensionné ou non indexé, le temps de réponse du serveur reste le même après Hyvä. Hyvä est plus rapide dans le navigateur, pas plus rapide sur le serveur.
• Grandes images de produit. Si vous servez des images héro de 2 Mo, Hyvä ne les compressera pas. L'optimisation des images est séparée.
• Tirage lourd des balises tierces. Hyvä vous donne plus de budget mais n'élimine pas le tirage.
• Requêtes de base de données lentes sur PDP. Le rendu lent de PDP côté serveur reste lent.
• Problèmes de pertinence de recherche. La recherche par défaut de Magento est ce qu'elle est ; Hyvä utilise le même backend de recherche.

Ces problèmes nécessitent des corrections séparées. L'argument pour Hyvä est les gains en charge JS + modèle de rendu, qui sont les plus grands goulets d'étranglement spécifiques aux mobiles pour la plupart des magasins Magento.

Au-delà de Hyvä, les 10 prochains points de Lighthouse

Après que Hyvä vous ait fait passer de 40 à 88, les 4 à 7 prochains points pour atteindre 90+ proviennent généralement de :

1. Inclusion de CSS critique, rendre côté serveur le CSS au-dessus de la ligne de flottaison pour que le premier affichage n'attende pas le fichier CSS
2. Optimisation des polices, font-display: swap, précharger les polices critiques, moins de poids de police
3. Indices de priorité d'image, fetchpriority="high" sur l'image LCP, bon srcset pour les images responsives
4. Audit des balises tierces, différer les balises non critiques via GTM, déplacer l'analytique côté serveur via Stape
5. Fractionnement du code JavaScript, charger paresseusement tout ce qui est en dessous de la ligne de flottaison

C'est un réglage de performance standard qui s'applique à tout site moderne. Hyvä rend possible d'atteindre les objectifs ; ne le fait pas automatiquement.

Qu'en est-il de Hyvä Checkout ?

La page de paiement sur Magento par défaut est la surface la moins performante, un flux multi-étapes avec un lourd Knockout JS et aucun parallélisme. Mobile Lighthouse sur le paiement par défaut de Magento obtient souvent des scores dans les 20.

Hyvä Checkout (un produit distinct de Hyvä Theme) reconstruit le paiement en un flux Alpine.js sur une seule page. Mobile Lighthouse sur Hyvä Checkout obtient généralement des scores de 88 à 95. Le taux de complétion du paiement mobile augmente de 8 à 15 % à travers les implémentations.

Si votre paiement mobile est votre goulet d'étranglement de conversion, Hyvä Checkout est le meilleur investissement en ROI de Hyvä.

Le mot de la fin

Le problème de performance mobile de Magento est bien compris : charge JavaScript + modèle de blocage de rendu + frais généraux de Knockout. Hyvä aborde chacun de ces problèmes en remplaçant la couche frontend par une pile fondamentalement plus légère.

Les coûts de migration varient de 12 000 £ à 35 000 £ et prennent de 6 à 10 semaines. L'amélioration de Lighthouse mobile est généralement de +35 points. L'augmentation du taux de complétion du paiement mobile (avec Hyvä Checkout) est généralement de +8 à 15 %.

Pour un magasin Magento réalisant plus de 1 million de £ de revenus annuels avec un trafic mobile important, la migration se rembourse en 6 à 9 mois uniquement sur l'augmentation de conversion + SEO.

Prochaines étapes

• Consultez la page de service de migration Hyvä
• Lisez Pourquoi votre score Lighthouse Magento est bloqué à 40 pour la liste de contrôle d'optimisation de performance
• Lisez Les Core Web Vitals de Magento échouent ? Voici la solution pour le guide spécifique aux CWV
• Réservez un appel de cadrage pour un devis à prix fixe