Comment comparer les performances avant et après Sylius 2 ?

Pour comparer les performances réelles avant et après une migration Sylius 2, il faut mesurer les mêmes pages, avec les mêmes outils et dans les mêmes conditions, avant la bascule puis après, sur trois niveaux : la vitesse vue par les visiteurs (les Core Web Vitals), le temps de réponse du serveur, et les indicateurs de vente comme le taux de conversion. Sans mesure de départ relevée sur la boutique 1.14, aucune comparaison n'est possible. Et les données réelles des visiteurs demandent environ quatre semaines avant de pouvoir conclure.

Je suis développeur Sylius indépendant et j'ai mené des montées de version 1.x vers 2.x de boutiques en production. La question « le site est-il plus rapide ? » arrive toujours le lendemain de la bascule, et la réponse honnête est souvent « on ne le sait pas encore ». Voici comment le savoir, sans se laisser tromper par un chiffre isolé. Si votre question est plutôt de savoir si Sylius 2 rend le site plus rapide en soi, elle est traitée dans l'article sur la vitesse de Sylius 2.

Pourquoi une comparaison avant après est-elle si souvent fausse ?

Parce qu'on compare rarement la même chose. Un test lancé un mardi matin sur la boutique 1.14 et un autre lancé un samedi soir sur Sylius 2 ne mesurent pas la migration : ils mesurent le trafic, le réseau et l'état des caches. Le lendemain de la bascule, les caches sont froids, les miniatures d'images sont régénérées à la première visite et la boutique paraît lente alors qu'elle ne l'est pas.

Il faut aussi isoler ce qui a changé. Une migration Sylius 2 change souvent plusieurs choses à la fois : la version de PHP, celle de Symfony, le thème réécrit sur Bootstrap 5 et Symfony UX, parfois l'hébergement. Si vous voulez savoir ce qui a amélioré ou dégradé la vitesse, il faut au minimum savoir ce qui a bougé, et dans l'idéal ne pas tout changer le même jour.

Quelles mesures relever avant la migration ?

Je choisis un petit nombre de pages qui représentent la boutique : l'accueil, deux ou trois catégories parmi les plus visitées, quelques fiches produits, le panier et les étapes du tunnel de commande. Pour chacune, je relève trois familles de chiffres.

Pour les visiteurs réels, Google publie des seuils : une bonne expérience correspond à un LCP de 2,5 secondes au plus, un INP de 200 millisecondes au plus et un CLS de 0,1 au plus, mesurés au 75e centile des chargements. Je les note page par page, pas seulement en moyenne sur le site. Le rôle de ces indicateurs dans le référencement est expliqué dans la documentation Google sur les Core Web Vitals.

Données de laboratoire ou données réelles : laquelle croire ?

Les deux, pour des usages différents. PageSpeed Insights distingue clairement les données de laboratoire, produites par Lighthouse dans des conditions simulées et fixes, et les données réelles, tirées du Chrome User Experience Report sur les 28 derniers jours. Les premières servent à diagnostiquer et à corriger avant la bascule, sur la préproduction. Les secondes disent ce que vivent vos clients, mais elles réagissent lentement.

Conséquence pratique : pendant les quatre semaines qui suivent la bascule, les données réelles mélangent l'ancienne et la nouvelle boutique. Je ne conclus qu'une fois la fenêtre renouvelée, et je compare avec le relevé fait avant la migration, au même moment de la semaine et hors période de soldes ou de fêtes si possible.

Quels points surveiller sur une boutique Sylius 2 ?

Le nouveau front repose sur Symfony UX et des composants dynamiques, notamment pour l'ajout au panier et le tunnel de commande. Chaque interaction de ce type déclenche un échange avec le serveur, ce qui pèse sur la réactivité mesurée par l'INP si le serveur répond lentement. Je mesure donc le temps de réponse de ces appels, pas seulement celui de la page complète.

Deuxième point, le thème. Un front reconstruit proprement sur Bootstrap 5 peut être plus léger ; un ancien design recopié avec une couche de CSS supplémentaire et des scripts hérités peut finir plus lourd. Les images sans dimensions déclarées, fréquentes dans un thème réécrit vite, font sauter la mise en page et dégradent le CLS. Le détail du nouveau front est dans l'article sur Bootstrap et Stimulus.

Troisième point, le serveur. Sylius 2 demande PHP 8.2 au minimum, et 8.3 pour Sylius 2.3. Le changement de version de PHP et de Symfony modifie le temps de réponse, dans un sens ou dans l'autre selon votre code et votre configuration de cache. Je compare ce temps sur les mêmes pages, avec le même trafic.

Si vous n'avez aucun relevé de départ aujourd'hui, c'est le moment de le faire, pendant que la boutique 1.14 tourne. Le diagnostic offert de migration Sylius 2 est l'occasion de le cadrer : j'analyse votre projet avec Sylius Upgrade Analyzer, l'outil que j'ai créé et publié sur le Sylius Store, et je repère les gabarits et scripts qui pèseront sur la vitesse.

Comment relier la vitesse au chiffre d'affaires ?

Pour un dirigeant, la vitesse n'est qu'un moyen. La question finale est de savoir si la boutique convertit au moins aussi bien qu'avant. Je compare le taux de conversion et l'abandon de panier sur des périodes équivalentes, par appareil, en tenant compte des campagnes en cours. Une baisse de conversion qui coïncide avec un INP dégradé sur mobile désigne un problème précis à corriger. Une baisse sans dégradation de vitesse oriente plutôt vers un parcours cassé ou un suivi des conversions incomplet, sujet traité dans l'article sur le tracking après Sylius 2. Si vous voulez un état des lieux de la boutique actuelle sous l'angle des ventes, l'audit de boutique s'y prête aussi.

Ce que je vous propose

Sylius 1.14 ne reçoit plus de correctifs de sécurité après le 31 décembre 2026. Une comparaison honnête se prépare avant la migration, pas après. Demandez le diagnostic de migration offert : je passe votre projet à l'analyseur, je vous indique ce qui pèsera sur la vitesse et la conversion, et je vous remets une estimation en jours dont le plan prévoit la mesure de départ.