Sylius 2 : le site sera-t-il plus rapide ?
Pas automatiquement. Sylius 2 modernise le socle de votre boutique (PHP plus récent, Symfony à jour, interface reconstruite sans jQuery ni Semantic UI) et crée de bonnes conditions pour un site plus rapide, mais la vitesse ressentie par vos clients dépend surtout de l'hébergement, du cache, des images et du code personnalisé. Une migration peut rendre le site plus rapide, aussi rapide, ou plus lent : la seule manière de le savoir est de mesurer avant et après.
Je préfère être franc sur ce point, parce que la promesse d'un site « beaucoup plus rapide » sert souvent à vendre une migration. Je n'ai pas de pourcentage à vous donner, et personne ne peut en donner un sans avoir mesuré votre boutique. Voici en revanche ce que la migration change réellement, ce qu'elle ne change pas, et la méthode pour en tirer un gain mesurable.
Qu'est-ce qui peut rendre une boutique Sylius 2 plus rapide ?
Plusieurs changements vont dans le bon sens. Le socle technique d'abord : Sylius 2 demande PHP 8.2 au minimum, et PHP 8.3 pour la version 2.3, avec Symfony 6.4, 7.4 ou 8. Passer d'un PHP ancien à une version récente est en général favorable aux performances côté serveur, mais l'ampleur du gain dépend de votre code et de votre configuration. Le guide officiel UPGRADE-2.0 indique aussi que les services sont désormais privés par défaut, ce qu'il présente comme une amélioration de la performance et de la maintenabilité.
L'interface ensuite. Le front boutique passe de Semantic UI et jQuery à Bootstrap 5, Symfony UX et Stimulus. C'est l'occasion de repartir d'un thème propre, sans des années de scripts et de feuilles de style accumulés. Sur les boutiques que j'ai migrées, le nettoyage du thème est souvent l'endroit où l'on gagne le plus, justement parce qu'on supprime ce qui ne servait plus. Le détail technique de ce nouveau front est dans l'article sur la migration du frontend vers Bootstrap et Stimulus.
Ce que la migration ne change pas
La plupart des lenteurs que je rencontre sur les boutiques Sylius n'ont rien à voir avec la version. Un serveur sous-dimensionné, un cache HTTP absent, des images de plusieurs mégaoctets sur les fiches produits, des requêtes de base de données mal optimisées dans un plugin, un script de suivi publicitaire qui bloque l'affichage : tout cela reste exactement pareil après une migration, si personne ne s'en occupe.
À l'inverse, une migration peut introduire des lenteurs. Un gabarit réécrit en Twig Hooks qui déclenche plus de requêtes qu'avant, un composant interactif du panier mal configuré, un cache que l'on a oublié de réactiver après la bascule. Ce sont des erreurs classiques, et elles passent inaperçues si personne ne compare les chiffres. Pour le cache, l'article sur Varnish et la performance de Sylius donne des pistes concrètes.
Pourquoi la vitesse compte pour vos ventes et votre référencement
Une boutique lente perd des visiteurs avant même qu'ils voient un produit, surtout sur mobile. Côté Google, la documentation Core Web Vitals de Google Search Central décrit trois mesures : l'affichage du contenu principal (LCP, objectif sous 2,5 secondes), la réactivité aux interactions (INP, objectif sous 200 millisecondes) et la stabilité visuelle (CLS, objectif sous 0,1). Google indique que de bons résultats sur ces mesures, avec les autres aspects de l'expérience de page, vont dans le sens de ce que ses systèmes de classement cherchent à récompenser. Ce n'est pas un levier magique, mais c'est un critère réel.
Pour un dirigeant, la conclusion est pratique : la migration est un moment où l'on touche à tout le front boutique. C'est le meilleur moment pour corriger les lenteurs, à condition de les avoir mesurées avant.
Comment obtenir un gain de vitesse mesurable
Ma méthode commence avant le premier changement de code. Je mesure la boutique actuelle sur un échantillon de pages représentatives : accueil, une catégorie chargée, une fiche produit avec beaucoup de déclinaisons, le panier, une étape du paiement. Je relève les temps de réponse du serveur et les Core Web Vitals, en laboratoire et, quand vous en disposez, avec les données réelles de vos visiteurs dans la Search Console.
Pendant la migration, je fixe un objectif simple : aucune page clé ne doit être plus lente qu'avant. Je profite de la réécriture du thème pour alléger ce qui peut l'être, et je contrôle la configuration du serveur sur la préproduction, identique à la production. Après la bascule, je refais les mêmes mesures sur les mêmes pages. La méthode complète de comparaison est détaillée dans l'article sur la comparaison des performances avant et après migration.
Sylius Upgrade Analyzer, l'outil open source que j'ai créé et publié sur le Sylius Store, ne mesure pas la vitesse : il inventorie ce qui doit être repris pour la version 2, comme les gabarits surchargés, les scripts jQuery ou les plugins. Cet inventaire dit en revanche où se trouve le code qui sera réécrit, et donc où un gain est possible. Si vous voulez cette liste pour votre boutique, c'est le premier livrable du diagnostic de migration offert.
Ce que je vous propose
Je lance Sylius Upgrade Analyzer sur votre projet et je vous remets un diagnostic offert commenté, avec une estimation en jours et les points où la migration peut aussi améliorer la vitesse. Je vous rappelle sous 24 heures ouvrées. Avec la fin des correctifs de sécurité de Sylius 1.14 le 31 décembre 2026, autant faire de cette migration obligatoire une occasion de gagner en rapidité, mesures à l'appui.