Hyvä Checkout 1.3 est la mise à jour la plus sous-estimée de Magento en ce moment

Hyvä Checkout 1.3 a été lancé plus tôt en 2026 et la plupart de l'écosystème Magento l'a traité comme une mise à jour mineure. En utilisant Hyvä Checkout sur une douzaine de boutiques en production depuis 2023, nous pensons que c'est la mise à jour la plus sous-estimée de Magento en ce moment. Cet article couvre les trois problèmes que 1.3 a corrigés pour nous et pourquoi la plupart des boutiques à thème Hyvä devraient mettre à jour ce trimestre.

Ce qu'est réellement Hyvä Checkout

Petit rappel pour le contexte. Hyvä Themes remplace la vitrine Magento Luma par une pile Tailwind plus Alpine. Hyvä Checkout est un produit distinct qui remplace le processus de paiement par défaut de Magento (qui reste basé sur Knockout même sur une boutique à thème Hyvä) par un processus de paiement natif Hyvä. La plupart des boutiques Hyvä adoptent le thème et le Checkout ensemble, mais ce sont des achats indépendants et un nombre significatif de boutiques utilisent des thèmes Hyvä avec le processus de paiement par défaut de Magento.

Hyvä Checkout 1.3 mérite d'être remarqué en raison de ce qu'il a changé sous la surface, pas seulement des fonctionnalités visibles par l'utilisateur.

Problème 1 corrigé : surcharge AJAX de la section client

L'appel AJAX de la section client par défaut de Magento se déclenche à chaque chargement de page, y compris lors du processus de paiement. Il récupère le nombre d'articles dans le panier, le nom du client, le contenu du mini-panier et quelques autres fragments. Sur Luma, cela ajoute 200 à 600 millisecondes au temps d'interaction après le rendu de la page.

Avant 1.3, Hyvä Checkout déclenchait encore la section client sur la page de paiement elle-même, ce qui était redondant : le processus de paiement a déjà un contexte complet du panier. La version 1.3 désactive l'appel de la section client sur les pages de paiement et récupère les fragments nécessaires à partir de l'état de paiement existant. Amélioration moyenne de l'INP que nous avons mesurée sur quatre boutiques : 40 à 90 millisecondes au 75e percentile.

Problème 2 corrigé : latence de l'autocomplétion d'adresse

L'autocomplétion d'adresse de Hyvä Checkout avant 1.3 effectuait un aller-retour vers le service d'adresse configuré (Google, Loqate ou services postaux locaux) à chaque frappe après les trois premiers caractères. Pour des processus de paiement à fort volume, cela signifiait que l'API de validation d'adresse Google réduisait la boutique lors des pics de trafic, entraînant un échec silencieux de l'autocomplétion.

La version 1.3 a introduit un débounce côté client et une coalescence des requêtes. Plusieurs requêtes d'autocomplétion pour le même préfixe sont fusionnées. Le débounce par défaut est de 220 millisecondes, configurable. Nous avons mesuré une réduction de 60 à 80 % des appels à l'API d'autocomplétion pendant les pics de trafic sur trois boutiques à fort volume. Le comportement d'autocomplétion visible par le client est identique ou meilleur.

Problème 3 corrigé : rendu conditionnel des méthodes de paiement

Hyvä Checkout prend en charge le rendu conditionnel des méthodes de paiement, où, par exemple, les options d'Acheter Maintenant Payer Plus Tard ne s'affichent que pour des valeurs de panier supérieures à 100 £. Avant 1.3, la logique conditionnelle s'exécutait sur le serveur lors de chaque rendu du composant d'étape de paiement, ce qui ralentissait l'affichage de l'étape de paiement de 100 à 200 millisecondes.

La version 1.3 a déplacé la logique conditionnelle vers des liaisons réactives Alpine dans le navigateur. Le serveur envoie uniquement la liste complète des méthodes une fois ; le client filtre au fur et à mesure que le panier change. Ce changement nous a coûté environ une journée de travail d'intégration pour mettre à jour nos deux modules de méthode de paiement personnalisés vers le nouveau modèle. Le gain de performance sur l'affichage de l'étape de paiement a été immédiat.

Ce qui ne fonctionne pas encore dans 1.3

Pour l'équilibre, les choses que 1.3 ne corrige pas encore.

Le processus de paiement en plusieurs étapes (séparer l'expédition et la facturation en vues distinctes) est toujours uniquement sur une seule page. Nous avons des clients qui souhaitent spécifiquement un processus de paiement en plusieurs étapes pour des flux de travail B2B ; ils continuent d'utiliser un processus de paiement en plusieurs étapes basé sur Knockout personnalisé.

Le calcul des taxes lors du changement d'adresse d'expédition déclenche toujours un recalcul complet du devis, ce qui peut prendre de 300 à 800 millisecondes sur des boutiques avec des règles fiscales complexes. L'équipe Hyvä a signalé qu'elle s'attaquerait à cela dans une future version.

L'API du magasin de données client (le mécanisme interne de Magento pour partager l'état du panier entre les composants) est toujours enveloppée par Knockout. Les futures versions de Hyvä Checkout déplaceront probablement cela vers une implémentation Alpine native, mais 1.3 ne l'a pas fait.

Devez-vous mettre à jour

Trois conditions où nous recommandons de mettre à jour ce trimestre.

Vous utilisez Hyvä Checkout sur une boutique B2C réalisant plus de 50 000 £ de revenus mensuels. L'accélération cumulative du processus de paiement se traduit de manière mesurable.

Vous avez intégré une méthode de paiement avec rendu conditionnel (Acheter Maintenant Payer Plus Tard, options de paiement régionales). Le modèle réactif 1.3 est le bon modèle et est important pour le nouveau travail sur les méthodes de paiement.

Vous dépendez fortement de l'autocomplétion d'adresse. Les économies d'appels API justifient à elles seules le temps de mise à jour.

Si aucune de ces conditions ne s'applique, prévoyez la mise à jour dans votre prochain cycle trimestriel mais ne vous précipitez pas.

Pourquoi nous pensons qu'elle est sous-estimée

La plupart des communications de mise à jour de l'équipe Hyvä se sont concentrées sur les fonctionnalités visibles (nouvelle mise en page du mini-panier, nouveaux modèles d'erreurs de formulaire). Les changements d'infrastructure n'ont pas reçu l'attention qu'ils méritent. En utilisant le code en production, les changements d'infrastructure sont là où se trouve la véritable valeur. Nous sommes heureux d'être sur cette version.

Liens connexes

• Hyvä : le guide complet couvre l'écosystème Hyvä.
• Optimisation des performances Magento couvre l'ordre des opérations de performance plus large.