Clara la Genevoise
Cet article se veut une ressource pratique complète sur l’optimisation de la vitesse de Magento. Il contient des recommandations très faciles à mettre en œuvre pour les plus avancés.
On parle beaucoup de la façon dont Magento utilise des ressources abondantes et de la difficulté de travailler avec.
Nous essayons de déboulonner certains mythes et de montrer un autre côté des choses.
Alors décomposons les choses morceau par morceau !
Caching
Le cache sert de tampon entre l’utilisateur et le serveur web. Servir une page web mise en cache à un visiteur est beaucoup plus simple que de libérer toute la puissance de Magento pour chaque rafraîchissement du navigateur.
Types de cache
Magento en a beaucoup en place comme vous pouvez le voir ci-dessous.
Magento 1.x:19-cache-types
Magento 2.x:2-cache-types
Tous sont significatifs, mais le plus influent est le cache pleine page.
Pourquoi le cache est-il si important ?
Il offre une stabilité lorsque de nombreux utilisateurs naviguent sur le site web.
Voici un test LoadImpact pour un site web Magento avec tous les caches désactivés :
no-cache
À environ 30 utilisateurs simultanés, le serveur web a planté.
Voici le même site web avec toutes les caches actives :
all-caches-vernish
C’est mieux comme ça ! Le temps de chargement a été stable à un peu plus de 800 ms.
Nous obtenons un temps de réponse du serveur beaucoup plus rapide, également connu sous le nom de TTFB (Time-to-first-byte)
Nous comparons ci-dessous les temps de réponse d’un site web Magento 2 utilisant différents types de caches (testés avec WebPageTest.org) :
ttfb-fpc-m2
Il semblerait que les moteurs Varnish et Redis Full Page Cache soient nos meilleures options. Les deux utilisent des moteurs de stockage en mémoire, ce qui rend le cache plus rapide que les options de système de fichiers.
Même si Redis est pris en charge comme un cache sauvegardé depuis Magento 1.8, Varnish n’est disponible par défaut que dans Magento 2.
Si vous utilisez Magento 1.x et que vous avez à cœur d’utiliser Varnish, il existe des modules comme Turpentine (pour les serveurs récents) ou Phoenix (pour les anciens serveurs) pour faciliter l’intégration.
Cela permet de soulager le serveur, ce qui a un impact direct sur votre budget, ce qui est un sujet important pour les moyennes et grandes entreprises.
Le cache est également crucial pour le référencement. Dans l’article sur l’analyse des logs, nous expliquons qu’il est essentiel de faciliter la vie de Googlebot si nous voulons obtenir un bon référencement.
Vous trouverez ci-dessous un diagramme de journal du serveur avec les temps de réponse du crawler de Google.
La couleur vert foncé représente les pages qui se chargent le plus rapidement. Vous pouvez voir le 26 mars comment le nombre de pages à chargement rapide augmente :
speed-cache-engine
Vous l’avez deviné, c’est là que nous avons ajouté le cache pleine page.
Comme vous le savez sans doute, la vitesse a été officiellement annoncée comme un facteur de classement par Google. Il est impossible d’y échapper pour l’instant !
Conseil avancé : Réchauffement du cache
Pour que le cache fonctionne sur toutes nos pages, il faut d’abord que quelqu’un les visite. Avoir une première vue lente ne serait pas la fin du monde, mais chaque visiteur compte !
Y aurait-il un moyen d’offrir une expérience de navigation rapide à la première personne qui voit la page ? Bien sûr qu’il y en a un ! Nous les visiterons nous-mêmes tous les soirs.
Enfin, pas tout à fait.
Nous pouvons créer un « cronjob » pour faire le travail à notre place.
Notre méthode consiste à créer un script de bash qui récupère chaque URL du plan du site XML. Vous trouverez ci-dessous le code avec lequel nous travaillons :
Il serait préférable de l’exécuter la nuit, lorsque le trafic est au plus bas.
Optimisation du front-end
JS & CSS
Les fonctions intégrées de Magento ont l’air bien à première vue ! Dans un monde révolu, la fusion de tous les fichiers CSS en un seul, ainsi que les fichiers JS, fera des merveilles pour votre frontend.
Au lieu que le navigateur de l’utilisateur envoie 50 à 100 requêtes, nous n’en aurions que 2. En plus, si nous les réduisons, nous pourrions également bénéficier d’une taille de requête plus faible.
La situation actuelle nous confronte à de nouveaux obstacles tels que la lenteur des connexions mobiles, les configurations https médiocres, les idées fausses sur HTTP/2, etc.
Cependant, nous aimons toujours les considérer comme des opportunités. Vous devriez en faire autant !
L’astuce consiste à faire des tests approfondis et à examiner les données de manière objective.
Et c’est ce que nous avons fait !
Magento 1.X
Dans l’admin, nous avons les options dans Système > Configuration > Avancé > Développeur :
merge js css m1
Magento 1 ne dispose pas de la fonctionnalité de minification, vous devrez donc utiliser un module (comme celui-ci, gratuit) ou des méthodes plus avancées.
Maintenant, les tests !
Nous avons tout testé en utilisant Google Pagespeed Insights, WebPageTest.org, Google Lighthouse et Google Chrome via une connexion 3G rapide.
Sur Magento 1, les résultats des tests semblent indiquer une direction de fusion et de réduction des fichiers JS et CSS :
m1-tests
Le code Javascript et CSS est très diversifié dans le monde réel. Nous vous recommandons de faire les tests pour votre cas particulier.
Si vous souhaitez utiliser notre visualisation, cliquez dessus et téléchargez le cahier de travail sur Tableau Public.
Et le plus important : assurez-vous que votre site web fonctionne après avoir effectué les modifications !
Magento 2.X
Sur Magento 2, nous avons une toute autre histoire.
