Avec le thème Hyvä, Magento 2 sera-t-il toujours plus rapide qu’avec n’importe quel autre thème ?

Imaginez deux boutiques Magento. La première utilise Hyvä, mais lance dès l’arrivée sur la page une quinzaine d’outils marketing, charge de grandes images et régénère la page à chaque fois. La seconde utilise un autre thème, soigneusement optimisé, avec un cache efficace et uniquement les scripts dont le client a besoin.

Laquelle sera la plus rapide ? Le nom du thème ne suffit pas pour répondre.

Hyvä offre à Magento un très bon point de départ pour créer une boutique rapide. Il ne garantit toutefois pas un avantage inconditionnel sur toute autre implémentation. Le résultat dépend de tout le parcours entre le clic sur un lien et le moment où le client voit le produit et peut l’acheter.

C’est pourquoi il est utile d’associer le déploiement de Hyvä à un audit du serveur, des modules, des images et de la conception de l’interface. Il devient alors possible de travailler vers un objectif ambitieux : 95 à 100 points dans Google PageSpeed Insights, tout en conservant les fonctionnalités nécessaires à la vente.

Que signifie réellement un score de 95 à 100 dans PageSpeed ?

Dans le langage courant, on parle de 100 % dans PageSpeed, mais l’outil présente des points sur une échelle de 0 à 100. Dans la partie basée sur Lighthouse, il évalue quatre domaines différents :

Ces évaluations ne se remplacent pas les unes les autres. Une boutique rapide peut avoir des boutons peu lisibles. Une boutique techniquement correcte peut charger trop de JavaScript. Lighthouse est un outil de diagnostic, et le périmètre de ses audits ne couvre pas toute la qualité d’une boutique. Description de Lighthouse.

Le score Performance provient d’une mesure en laboratoire et peut varier d’un essai à l’autre. PageSpeed affiche également, lorsqu’elles sont disponibles, les données d’utilisateurs réels issues de CrUX, collectées sur une période glissante de 28 jours. Un nouveau déploiement ne modifiera pas immédiatement l’ensemble de ces données. Fonctionnement de PageSpeed Insights.

En pratique, nous avons besoin de deux objectifs : des tests régulièrement bons et une bonne expérience client. Pour les Core Web Vitals, cela signifie :

• LCP jusqu’à 2,5 s — apparition rapide du plus grand élément dans la zone visible ;
• INP jusqu’à 200 ms — réaction fluide aux interactions ;
• CLS jusqu’à 0,1 — mise en page stable.

Ces seuils sont évalués au 75e percentile, séparément pour les appareils mobiles et les ordinateurs. Le test de chargement standard de Lighthouse ne mesure pas l’INP ; pour diagnostiquer le blocage du navigateur, il utilise notamment le TBT. Un TBT faible ne confirme pas automatiquement un bon INP. Core Web Vitals.

Comment Hyvä aide à accélérer Magento ?

Hyvä réduit le poids du frontend par rapport à Luma, le thème standard. Il utilise Alpine.js pour les interactions et Tailwind CSS pour le style. Moins de code à télécharger et à exécuter laisse davantage de marge au navigateur pour afficher rapidement l’offre. La documentation Hyvä indique que la limitation du JavaScript et du CSS constitue une partie importante de cette architecture. Performance de Hyvä.

Cet avantage peut toutefois être facilement réduit. Il suffit d’ajouter à un frontend léger un slider complexe, un chat, plusieurs trackers et des modules qui ramènent les anciennes dépendances du thème précédent.

Hyvä ne corrigera pas non plus une requête lente vers la base de données, un cache défaillant ni un serveur occupé par un import. C’est pourquoi la question avant le déploiement devrait être : qu’est-ce qui retarde aujourd’hui l’achat et lesquels de ces problèmes seront résolus par un changement de frontend ?

1. Serveur : nginx et Varnish doivent faire le bon travail

Avant que le navigateur n’affiche le produit, il doit recevoir le document HTML. S’il attend longtemps le premier octet de la réponse, même un thème léger démarre avec du retard.

Nginx : livraison efficace des ressources

Dans une architecture Magento typique, nginx gère notamment HTTPS, les fichiers statiques et la transmission des requêtes vers les services suivants. Il est utile de vérifier la compression des réponses textuelles, HTTP/2 ainsi que les en-têtes de cache pour les fichiers CSS et JS versionnés. Adobe fournit un exemple de configuration nginx comme point de départ pour un déploiement avec Varnish. Configuration de Varnish dans Adobe Commerce.

Il ne faut pas attribuer la même durée de conservation à toutes les réponses. Une feuille CSS versionnée peut être utilisée longtemps depuis le cache du navigateur. Le prix, le contenu du panier et la réponse liée à un client connecté exigent un autre traitement.

Si le serveur choisit WebP selon l’en-tête Accept, il faut aussi vérifier la clé de cache et l’en-tête Vary: Accept. Le navigateur et les couches de cache intermédiaires doivent distinguer les variantes d’image.

Varnish : vérifier les hits de cache, pas seulement l’installation du service

Varnish permet de servir les pages publiques depuis le cache sans refaire tout le travail côté Magento. Adobe recommande son utilisation en environnement de production. Gestion du cache Magento.

Le test pratique est simple : nous ouvrons plusieurs fois la même adresse publique et vérifions si, après la première réponse, des hits HIT apparaissent. Nous comparons ensuite le temps de réponse depuis le cache et le temps de génération de la page avec MISS.

Si une catégorie populaire contourne constamment le cache, il faut en trouver la cause : configuration, cookies, paramètres d’URL, personnalisation ou fonctionnement d’un module. Acheter un serveur plus puissant peut alors seulement masquer le problème.

La justesse est également essentielle. Le cache ne doit pas transmettre le panier ou les données d’un client à un autre utilisateur. Il faut tester les variantes de boutique, les devises et les groupes de clients, ainsi que le rafraîchissement du contenu après une modification de produit. Un prix rapide mais obsolète n’est pas une réussite d’optimisation.

Au-delà de nginx et Varnish, nous vérifions PHP-FPM, OPcache, le cache backend compatible avec la version de Magento, la base de données, cron et l’indexation. Le nombre de processus PHP doit découler de la mémoire disponible et de la charge réelle. L’augmenter sans mesure peut aggraver la situation.

2. Modules pour Hyvä : la compatibilité n’est qu’un début

Un module peut fonctionner correctement avec Hyvä tout en effectuant trop de travail à l’arrivée sur la page. Une bonne optimisation couvre donc à la fois la fonctionnalité et le coût de son lancement.

Chez kowal.store, nous adaptons nos modules à Hyvä et les développons avec l’objectif de préserver les performances de ce thème après installation. Nous veillons à ce que les nouvelles fonctionnalités ne chargent pas inutilement le frontend, en limitant les dépendances et en choisissant une méthode appropriée de chargement du JavaScript et du CSS. Consultez nos modules Magento 2 et choisissez des extensions pour votre boutique. L’effet d’un déploiement concret doit être confirmé par des mesures, car il dépend aussi de la configuration et des autres intégrations.

Prenons le chat. Un client qui parcourt une catégorie a d’abord besoin d’un bouton pour ouvrir la conversation. L’interface complète du chat et ses bibliothèques peuvent être chargées à l’ouverture. De la même manière, les suggestions avancées du moteur de recherche peuvent être préparées lors de l’entrée dans le champ de recherche, tout en laissant immédiatement visible et fonctionnel le formulaire.

Cette approche est également décrite par Hyvä dans ses recommandations sur le chargement du JavaScript externe.

defer, async et le report d’un composant sont des choses différentes

defer permet d’exécuter un script classique externe après le traitement du document et de conserver l’ordre des scripts de ce type. async lance le script lorsqu’il est prêt, sans garantie d’ordre par rapport aux autres. Aucun de ces attributs ne signifie à lui seul que le fichier ne sera téléchargé qu’après un clic.

Hyvä propose également x-defer, qui permet de retarder l’initialisation d’un composant Alpine, par exemple jusqu’à ce qu’il se rapproche de la zone visible. Ce n’est pas un report automatique du téléchargement de tous ses fichiers. Il faut aussi tenir compte des événements que le composant peut manquer avant son initialisation, par exemple ceux liés aux données client. Documentation x-defer.

Les changements doivent être vérifiés sur le panier, les filtres, les formulaires et les événements analytiques. La simple présence de l’attribut defer ne prouve pas qu’un module est bien optimisé.

CSS : l’apparence nécessaire doit être prête avant le premier rendu

Les styles de l’en-tête, de la liste de produits et de la mise en page mobile sont nécessaires dès le début. Leur chargement trop tardif peut provoquer un clignotement de la page et des déplacements d’éléments. En même temps, une catégorie de produits n’a pas besoin de charger tous les styles de chaque module installé.

Il est utile de limiter les feuilles globales, de supprimer les restes de l’ancien thème et de vérifier le build de production de Tailwind. Pour les classes créées dynamiquement, il faut veiller à ce que les règles nécessaires se retrouvent dans le CSS final. Le CSS critique intégré au HTML peut aider, mais il nécessite maintenance et tests ; il ne doit pas être la première réponse à chaque problème. Ressources bloquant le rendu.

L’analytics et les données SEO ont aussi un coût

Lors d’un travail d’optimisation d’une boutique Magento 2, nous avons vérifié la charge liée à l’analytics sur une page de catégorie. GTM et gtag représentaient environ 304 KB, soit 44 % du transfert enregistré lors de la première mesure mobile. C’est une bonne raison de revoir les tags et les déclencheurs. Cela ne signifie pas qu’il faut retarder toute l’analytics sans réflexion : un tel changement peut modifier le nombre de visites et d’événements enregistrés.

Il vaut aussi la peine d’examiner le HTML lui-même. Des données JSON-LD très développées, des informations produit dupliquées et des configurations de modules augmentent la réponse du serveur. JSON-LD ne s’exécute pas comme un programme JavaScript classique, mais il doit tout de même être transmis. Les données structurées d’une catégorie doivent correspondre à la liste visible, à sa pagination et à son ordre.

3. Images : le format, la taille et le moment du téléchargement comptent

Une image source de plusieurs milliers de pixels de large ne devrait pas arriver inutilement dans une petite tuile produit. Nous préparons des variantes adaptées à la taille d’affichage et à la densité de l’écran, tandis que srcset et sizes aident le navigateur à choisir le bon fichier. WebP ou AVIF doivent être comparés en termes de qualité et de poids sur les images concernées.

La distinction la plus importante concerne les images visibles immédiatement et celles situées plus bas. L’image qui constitue le LCP doit être facile à découvrir dans le HTML, sans loading='lazy' ; fetchpriority='high' peut être justifié. Les images sous le premier écran sont de bonnes candidates au lazy loading. Les dimensions ou proportions leur réservent une place dans la mise en page. Images responsives.

Nous n’attribuons cependant pas une priorité élevée à chaque image. Le navigateur a besoin de savoir ce qui est réellement le plus important. Fetch Priority.

Nous vérifions également les bannières CMS, le logo, le favicon, les miniatures vidéo et les graphismes des popups. L’optimisation doit couvrir le processus d’ajout de nouveaux fichiers, sinon la campagne suivante réintroduira des images lourdes.

Une adresse se terminant par .png ne détermine pas à elle seule ce que le navigateur télécharge. Le serveur peut fournir du WebP à cette adresse. Nous vérifions Content-Type et le transfert dans l’onglet Network.

4. Couleurs : leur impact principal se voit dans l’accessibilité

Remplacer un bouton bleu par un bouton vert n’accélérera pas Magento. La couleur joue toutefois un rôle important dans la lisibilité et le score Accessibility.

Les problèmes les plus fréquents viennent de descriptions gris clair, de boutons pastel avec texte blanc, d’étiquettes de promotion et de textes placés sur des images. Selon WCAG, le contraste d’un texte normal doit être d’au moins 4,5:1, et celui d’un grand texte 3:1. Un grand texte signifie au moins 18 pt, soit environ 24 px, ou 14 pt en gras, soit environ 18,7 px. Exigences de contraste du texte.

Pour les éléments visuels importants des contrôles et l’indication de leur état, une exigence de contraste de 3:1 par rapport aux couleurs adjacentes s’applique également, avec les exceptions décrites dans la norme. Contraste des éléments non textuels.

Il est utile de définir la palette de manière centralisée, par exemple via des variables CSS ou la configuration d’un module de couleurs. Ainsi, une modification de la couleur du texte ou des boutons s’applique à toute la boutique. Il faut également vérifier les états hover, focus, les erreurs de formulaires et les filtres sélectionnés. Un contour rouge ne doit pas être la seule information indiquant qu’un champ contient une erreur.

Les performances peuvent être influencées par la méthode d’implémentation de l’apparence : feuilles supplémentaires, script qui change les couleurs après chargement ou effets visuels lourds. La palette elle-même ne remplace toutefois pas l’optimisation du JS, des images et du serveur.

Pourquoi un seul bon résultat ne suffit-il pas ?

Lors de l’optimisation d’une boutique Magento 2 avec Hyvä, nous avons réalisé deux mesures Lighthouse locales pour la même page de catégorie. Sur mobile, nous avons obtenu 94 et 73 points. Le LCP était respectivement de 2,5 et 5,7 s, bien que dans les deux cas il concernait la même image du premier produit. Sur desktop, le score a atteint 100 points.

Toutes ces exécutions ont signalé un dépassement du délai de chargement, nous avons donc traité les résultats comme diagnostiques et potentiellement incomplets. Il ne s’agissait pas de résultats PageSpeed Insights confirmés ni de données CrUX. Ce n’est pas non plus une comparaison de Hyvä avec un autre thème.

Dans l’essai le plus faible, l’image s’est téléchargée rapidement, mais son affichage est intervenu plus tard. Cela montre pourquoi il faut distinguer le temps de téléchargement du temps de rendu. Continuer à compresser le fichier ne suffit pas à expliquer ce type de problème. Analyse des étapes du LCP.

Dans le travail sur une boutique, nous comparons plusieurs essais, la médiane et la dispersion, en conservant les mêmes conditions. Les rapports avec erreurs ne sont pas traités comme un point de référence stable. Nous vérifions aussi le comportement après acceptation des cookies, après ouverture de la recherche et après ajout d’un produit au panier.

Checklist Magento et Hyvä : la voie vers 95 à 100 points

La liste ci-dessous aide à planifier l’audit et la recette des travaux. Ce n’est pas une garantie de quatre scores à 100/100. L’évaluation dépend de la page, de la configuration, des conditions de test et de la version de Lighthouse. Un résultat vert ne remplace pas non plus les tests manuels d’accessibilité, l’audit de sécurité ni la stratégie SEO.

Mesure et point de référence

• La page d’accueil, la catégorie, le produit, la recherche et les étapes d’achat clés ont été analysés.
• Des mesures séparées mobile et desktop ont été réalisées, sur plusieurs essais comparables.
• La version de l’outil, le profil de l’appareil, l’état des consentements et la plage des résultats ont été enregistrés ; les timeouts ont été expliqués.
• Le LCP, l’INP et le CLS ont été vérifiés à partir de CrUX ou d’un monitoring interne, si disponibles.
• Les données d’une URL unique ont été distinguées des données de l’ensemble du domaine.
• La première visite, le retour de l’utilisateur et le fonctionnement après interaction ont été testés.

Serveur, nginx et Varnish — Performance

• Magento fonctionne en mode production, avec des ressources statiques correctement préparées.
• Les pages publiques atteignent Varnish HIT ; le temps de réponse avec MISS a également été vérifié.
• Le cache distingue correctement les variantes de boutique, et les données privées ne se retrouvent pas dans une réponse partagée.
• La modification d’un produit, d’un prix ou d’un contenu invalide correctement le cache concerné.
• Nginx compresse les ressources textuelles appropriées et prend en charge un protocole HTTP moderne.
• Les fichiers versionnés disposent d’en-têtes de cache adaptés ; le HTML et les réponses privées ont une politique séparée.
• PHP-FPM, OPcache et le cache backend sont configurés conformément à la version de Magento et aux ressources du serveur.
• Cron, l’indexation, les imports et les bots ne provoquent pas de pics de temps de réponse.

Modules, JavaScript et CSS — Performance

• Chaque module actif a une justification métier ; les doublons fonctionnels inutiles ont été supprimés.
• Les intégrations Hyvä ne réintroduisent pas inutilement les dépendances lourdes de l’ancien frontend.
• Le JS et le CSS des modules ne sont chargés que sur les pages qui utilisent leurs fonctionnalités.
• Les scripts ont été différés en respectant les dépendances, l’ordre et les événements d’initialisation.
• Le x-defer sélectif et le chargement des composants à l’usage ont été testés.
• Les styles critiques sont disponibles avant le premier rendu ; aucun clignotement de mise en page n’apparaît.
• GTM, les pixels, le chat et les widgets ont des déclencheurs et un coût de lancement examinés.
• Les changements d’analytics conservent le comportement convenu des consentements et des événements e-commerce corrects.
• Le HTML, le DOM et JSON-LD ne contiennent pas de données inutiles et dupliquées.
• Le panier, les filtres, le tri, la pagination et le checkout fonctionnent après optimisation.

Images et stabilité de la mise en page — Performance

• Les graphismes ont les dimensions, la qualité et le format appropriés ; le transfert réel a été vérifié.
• Les variantes responsives des images correspondent aux tailles d’affichage.
• L’élément LCP a été identifié séparément pour mobile et desktop.
• L’image LCP n’est pas retardée par le lazy loading ni par une initialisation JS inutile.
• Une priorité élevée n’a été accordée qu’aux ressources justifiées.
• Les images, bannières et contenus intégrés ont une place réservée dans la mise en page.
• Le logo, le favicon, les graphismes CMS et les images ajoutées par les modules ont été vérifiés.
• Le processus de publication de nouvelles images inclut la génération de variantes optimisées.

Couleurs et utilisation de l’interface — Accessibility

• Le texte, les prix, les boutons et les messages ont le contraste requis sur les arrière-plans réels.
• Le contraste des contrôles importants et la visibilité du focus clavier ont été vérifiés.
• Une erreur, une promotion ou une sélection ne sont pas communiquées uniquement par la couleur.
• Les liens et les boutons ont des noms accessibles compréhensibles ; les formulaires ont des libellés.
• Les images informatives ont un texte alternatif adéquat, et les images décoratives un alt vide.
• Le menu, les filtres, les popups et le panier peuvent être utilisés au clavier.
• Le zoom de la page, le petit écran et l’utilisation de base avec un lecteur d’écran ont été vérifiés.

Qualité technique — Best Practices

• La page et ses ressources fonctionnent via HTTPS, sans mixed content.
• Les erreurs de console, les requêtes échouées et les avertissements signalés par l’audit ont été expliqués.
• Les bibliothèques et modules sont maintenus ; les vulnérabilités signalées ont été examinées.
• Les images conservent leurs proportions, et les fonctionnalités n’utilisent pas inutilement d’API obsolètes.
• Le score élevé a été confirmé en même temps que le bon fonctionnement des paiements, formulaires et consentements.

Visibilité technique — SEO

• Les pages destinées à l’indexation renvoient le bon statut et ne comportent pas de noindex accidentel.
• robots.txt ne bloque pas les pages ni les ressources nécessaires.
• Le titre et la meta description correspondent au contenu de la page.
• Le canonical est correct ; les versions linguistiques et hreflang ont été examinés séparément.
• Les liens de navigation peuvent être lus par les robots, et la pagination fonctionne correctement.
• Les données structurées ont été vérifiées avec un outil séparé et correspondent au contenu visible.
• Le sitemap et l’indexation dans Search Console ont été examinés, également en dehors du périmètre de notation Lighthouse.

Les tests automatiques d’accessibilité ne couvrent qu’une partie des problèmes possibles. Même un score de 100 nécessite un test manuel complémentaire. Comment l’accessibilité est calculée dans Lighthouse.

Par où commencer dans votre boutique ?

Commençons par déterminer ce que le client attend. S’il attend la réponse du serveur, nous commençons par le backend et le cache. S’il attend une image, nous vérifions sa détection, son téléchargement et son affichage. Si la page est visible mais réagit avec retard, nous analysons le travail du JavaScript et des composants.

Ensuite, nous déployons un groupe logique de corrections, puis nous répétons les mesures et les tests d’achat. Cela permet de savoir ce qui a aidé et si le coût du changement était justifié. Atteindre les seuils Core Web Vitals ne garantit pas à lui seul un score de 95 : la Performance est calculée à partir de plusieurs métriques pondérées. Règles de notation Lighthouse.

Hyvä permet de partir d’un frontend léger. Maintenir cet avantage exige des décisions conscientes à chaque nouveau module, bannière et outil marketing. Il vaut donc mieux considérer la performance comme un critère de validation des déploiements successifs, et non comme un projet ponctuel terminé par une capture d’écran avec un résultat vert.

Si vous prévoyez un déploiement Hyvä ou souhaitez accélérer une boutique existante, contactez l’équipe kowal.store. Le point de départ devrait être un audit de pages concrètes et du parcours d’achat, avec une liste de causes, de priorités et de mesures avant et après les changements.