magento1-header
E-commerce

Idée reçue #1 :
Magento est lent

Par Gautier H. le 24 octobre 2022

 Lecture 10 minutes

Idée reçue #1 : Magento est lent. 

Avec un nombre de sites oscillant entre 100 000 et 250 000 (selon les sources), la popularité de la plateforme Adobe Commerce (ex Magento 2) ne fait pas débat. La solution a l’avantage d’être open source, elle est donc très largement accessible pour les développeurs du monde entier. Il s’agit là d’un atout incontestable puisqu’elle bénéficie des contributions de milliers de développeurs à travers le monde. Mais la médaille a un revers... Ces avantages ont poussé bon nombre d’agences à franchir le pas pour s’improviser expertes Magento (en témoigne l’explosion du nombre de sites e-commerce qui utilisent Magento, entre 2015 et aujourd’hui). Toutes n’ont pas réussi le pari de la performance. Et il n’est pas rare de trouver des plateformes Magento 2 dont la rapidité et la qualité laissent à désirer.

Comment expliquer ces défauts de performance ?

La réponse à cette question se décompose en quatre aspects distincts que nous allons détailler ici :

  • Qualité des développements
  • Architecture et utilisation du cache
  • Architecture monolithique vs. PWA/headless
  • Hébergement

 

Qualité des développements

Adobe Commerce (ex Magento 2) est une application dont l’un des enjeux principaux est l’extensibilité. L’objectif d’une plateforme comme Adobe Commerce est d’offrir aux développeurs un certain nombre de moyens d’étendre ses fonctionnalités et de changer les comportements standards sans avoir besoin de toucher le cœur de l’application maintenu par l’éditeur. Par ailleurs, l’application est hautement modulaire et décomposée en un très grand nombre de briques applicatives spécialisées.

idee-recue-magento-lent-1

Ces facteurs font d’Adobe Commerce une solution très extensible, mais hautement technique. Devenir expert de la solution en maîtrisant l’architecture et les concepts les plus avancés requiert des années d’expérience de la part des développeurs.

La rapidité d’une plateforme Adobe Commerce est intimement liée à la maîtrise des concepts architecturaux qui lui sont propres, ainsi qu’à la qualité d'optimisation des développements réalisés pour la customiser. Il est donc facile pour un développeur non initié d'impacter lourdement et négativement les performances de la plateforme.

De nombreux sites sont développés avec Adobe Commerce en dépit des bonnes pratiques de la solution. Nous constatons chez Synolia, lors des audits de plateformes, que les agences expertes de l’application sont très rares. De ce manque d’expertise de la solution, il résulte des plateformes lentes, difficiles à maintenir ou à faire évoluer et, parfois, un cauchemar pour les clients mal servis et mal conseillés par leur intégrateur.

 

Architecture et utilisation du cache

D’un point de vue architectural, Adobe Commerce repose sur un certain nombre de niveaux de caches. Ces différents niveaux jouent chacun un rôle crucial dans la rapidité du traitement des requêtes faites par les utilisateurs. Bien qu’optionnels pour certains, leur utilisation s’avère essentielle afin d’optimiser les performances. Ces caches sont de deux types :

  • Des caches externes (CDN / Varnish…)
  • Un cache interne (reposant généralement sur le service REDIS)

 

Chacune des couches de caches mentionnées dans le schéma ci-dessous répond à la même logique lorsqu’un client demande une information (fichier ou page) :

  • Si le système de cache possède déjà cette information, il la retourne directement à l’utilisateur évitant ainsi de solliciter le serveur et permettant d’augmenter sa capacité d’accueil.
  • Si le système de cache ne la connaît pas, il passe la requête au serveur pour qu’il la calcule et la renvoie. Le système de cache met ainsi cette réponse en mémoire pour le prochain utilisateur qui demandera la même information.

 

Le schéma simplifié du chemin d’une requête depuis le poste d’un visiteur jusqu’à la base de données :

idee-recue-magento-lent-2

 

Dans une architecture Adobe Commerce optimale, lorsqu’un visiteur demande une page, les opérations s'enchaînent comme suit :

  • La demande arrive au CDN dont le but est généralement de ne livrer que les fichiers statiques (images, fichiers CSS, fichiers javascripts). Si le CDN est en mesure de servir la ressource demandée, il la renvoie directement à l’utilisateur sans passer par les étapes suivantes.
  • La demande arrive au système de fullpage cache. Si le service est en mesure de servir la ressource demandée, il la renvoie directement à l’utilisateur sans passer par les étapes suivantes.
  • La demande arrive dans Adobe Commerce. Pour la majorité des composants de la page, l’application va, au moment de leur génération, regarder si le composant n’est pas déjà en cache dans le système de cache applicatif (généralement REDIS). La mise en cache d’un composant doit être réfléchie au moment de son développement et n’est pas systématique.
  • Enfin, si le composant n’est pas en cache, l’application va réaliser tous les calculs pour le générer et accéder, si nécessaire, à la base de données.

 

NB : Dans certains cas, le CDN et le cache de page ne sont qu’un seul et unique outil (Fastly sur Adobe Commerce Cloud)

 

Il est assez fréquent de constater que certains de ces niveaux de caches sont peu ou mal utilisés sur les plateformes Adobe Commerce. De cette mauvaise utilisation résulte des performances dégradées et des plateformes moins disposées à accueillir un fort trafic. Dans le pire des cas, la surcharge engendrée sur les serveurs entraîne une indisponibilité de la plateforme. Cela se produit généralement sur les périodes à fort trafic.

 

idee-recue-magento-lent-3

Architecture monolithique vs. PWA/headless

En complément du point précédent lié à l’architecture des services d’une plateforme Adobe Commerce, il est également possible de choisir une architecture découplée (headless et/ou PWA).

De manière très schématique, dans une implémentation classique d’Adobe Commerce, l’application se charge de gérer la totalité d’une demande client :

  • Réceptionner la demande
  • Déterminer le contenu à afficher en fonction de l’URL
  • Récupérer le contenu dans la BDD
  • Générer la page à afficher

 

Dans une implémentation headless, les étapes ci-dessus ne sont plus réalisées par un seul outil mais par deux. Les actions se répartissent de la manière suivante :

  • Réceptionner la demande : outil front-office
  • Déterminer le contenu à afficher en fonction de l’URL : outil front-office
  • Demander à l’application e-commerce les données nécessaires : outil front-office
  • Récupérer le contenu dans la BDD : outil back-office
  • Générer la page à afficher : outil front-office

 

Ainsi, dans ce modèle, l’application e-commerce est dédiée à la récupération de la donnée, à son stockage et à son administration par les équipes métier.

 

Les avantages :

  • L’application front-office est une application qui s’exécute exclusivement sur le navigateur du visiteur. La puissance de calcul nécessaire à la génération du rendu se déporte donc sur l’utilisateur final, rendant la sollicitation serveur moindre.
  • L’application front-office est généralement une SPA (single page application) et ne possède donc pas de rechargement de pages, donnant aux utilisateurs un sentiment de fluidité et de performance considérablement améliorées.

 

Adobe Commerce est aujourd’hui parfaitement compatible avec une implémentation de ce type et propose sa propre application front-office : PWA Studio. Cette application permet une implémentation facilitée des architectures de ce type visant à leur démocratisation future.

 

Attention : ce type d’implémentation demande, en plus de la connaissance de l’application Adobe Commerce, celle de l’application PWA studio ajoutant ainsi un niveau de complexité supplémentaire difficile à surmonter pour les intégrateurs non experts.

 

Plus d’informations sur la PWA dans cet article.

 

Hébergement

Le dernier aspect à bien prendre en compte pour bénéficier d’une plateforme Adobe Commerce performante est, évidemment, l’hébergement. Espérer de bonnes performances sur sa plateforme Adobe Commerce nécessite de savoir s’entourer du bon partenaire hébergeur et de bien dimensionner l’hébergement. Cela permet à la plateforme de traiter le volume de requêtes attendu, non pris en charge par les services de cache évoqués précédemment.
idée-reçue-magento-lent-4

Et bien qu’Adobe fournisse une liste de prérequis assez claire, pour ce qui est du dimensionnement, rien ne remplace l’expertise d’un hébergeur expérimenté sur la solution.

Ici aussi, un certain nombre d’e-commerçants ou d’intégrateurs peu expérimentés font le choix de mettre en place leur hébergement eux-mêmes sans réellement connaître les points de vigilance à avoir en tête. Encore une fois, les conséquences sont sans appel : des plateformes lentes et des coupures de service…

 

Idée reçue #2 : Magento est complexe à héberger

 

Comparativement aux autres solutions...

Les résultats ci-dessous proviennent d’un outil de monitoring développé par Synolia. Il permet à nos clients de monitorer quotidiennement leur webperformance, ainsi que celle de leurs concurrents. Les notes présentées sont les notes calculées par Google et ont vocation à révéler la qualité de l’expérience client. Elles vont de 0 à 100 (100 étant la meilleure note possible).

 

schéma-webperformance

 

(Adobe Commerce sur 78 sites monitorés, Salesforce sur 61 sites monitorés, Shopify sur 83 sites monitorés, Cléor).

 

Les notes présentées ci-dessus sont la moyenne des 28 derniers jours du panel de chaque solution. Pour cette analyse, seules les pages listes sont prises en compte, car elles sont les seules à être très similaires d’une solution et d’un site à l’autre. Et elles sont généralement peu impactées par le travail d’administration des marques (elles comportent peu de contenus éditoriaux).

On constate sur ces résultats qu’il est assez difficile de dégager une tendance, les notes moyennes des différentes solutions étant assez similaires. En revanche, on peut constater que les notes de la plateforme Cléor, développée par Synolia sur Adobe Commerce (ex Magento 2), sont très largement supérieures aux notes moyennes des différentes solutions. Preuve que le travail d’intégration influe beaucoup plus sur la note que la plateforme elle-même. Preuve également qu’en moyenne, Adobe Commerce n’a rien à envier à ses concurrents.

Alors, Adobe Commerce est-il vraiment lent ?

Sans surprise, notre réponse à cette question est non. Nous estimons que Adobe Commerce est avant tout victime de sa popularité.

L’explosion de sa courbe de popularité et la multiplication des intégrateurs s’improvisant experts sur la plateforme ont terni l’image d’une des solutions les plus complètes, abouties et évolutives du marché.

Il existe de très nombreuses manières d’intégrer Adobe Commerce et d’en faire une plateforme parfaitement optimisée. Cependant, il n’en existe aucune qui ne repose pas sur l'expérience et une expertise forte de la part de l’intégrateur.

 

Vous rencontrez des problèmes de performance avec votre plateforme Adobe Commerce ?

Contactez nous pour un audit !

 

Je prends contact

LinkedIn Email
Découvrez également...