Par Philippe Humeau – 

S’il est bien une question qui revient régulièrement au support, c’est bien celle-ci.

Les causes peuvent bien évidemment être multiples mais le diagnostique est parfois complexe. Afin de vous aider à mieux cerner les sources de lenteurs potentielles, ce petit article va vous donner une synthèse des actions que vous pouvez mener par vous même, même si vous n’êtes pas développeurs.

En premier lieu, si je me réfère à notre parc, toutes les distributions Linux utilisées sont optimisées et très proches en terme de configuration. Malgré cette homogénéité, il est facile de constater qu’un site optimisé peut accueillir 40 000 visiteurs par jours par serveurs, le tout en chargeant une page en 1 à 1,5 seconde en moyenne, et qu’un autre peut mettre 7 secondes à charger avec 5 personnes connectées.

Plus de puissance = plus de performance

Oui et non. Mais principalement, non. Plus de puissance = plus de visiteurs en parallèle, à la même vitesse qu’un seul.

En fait, même sur un serveur qui ne fait rien, en charge très basse ou nulle ou avec un seul visiteur concourant, une page peut mettre plusieurs secondes à charger, 5 à 10 pour les sites les plus lents.

En premier lieu, l’interprétation d’une page, le passage de l’interpréteur PHP sur le fichier index.php par exemple, prend du temps. Plus ou moins en fonction de la qualité du code. Mais si le code est lent, l’interpréteur PHP ne peut pas utiliser plusieurs processeurs ou core pour aller plus vite. Donc la limite est vite atteinte et de plus, cela est processus assez lourd. Donc que vous ayez plein de gros serveurs ou un tout petit, à peu de chose prêt, sur le rendu d’une page pour un visiteur, cela ne change rien.

Bien sur la génération et la fréquence du processeur joue, mais le principe est là. Ensuite, si votre site est bien fait, le fait que vous ayez plus de puissance, plus de serveurs, vous aidera juste à délivrer la même performance unitaire à un plus grand nombre de personne. En général, 150 à 200 en simultané (faisant une action au même moment) par serveur Web frontal, si votre site est optimisé et que votre serveur à 8 cores / 16 Go de RAM.

Comment auditer son Magento soi-même ?

Le processus

Alors comme ça, votre site Magento est lent ?

On va se faire un petit audit « à la main », « maison », que vous pouvez faire à la maison, sans compétences techniques particulières, pour savoir d’où viennent les problèmes.

  • Etape 1 : Chrome (ou Firefox ou Opera)
  • Etape 2 : Evaluations W3C
  • Etape 3 : Google Pagespeed
  • Etape 4 : Les fichiers de logs Systèmes et Magento
  • Etape 5 : Le recours aux pros

Etape 1 : le temps de chargement de la homepage

Sur un site Magento, ce moment dit « d’interprétation PHP » peut aller de 40 ms pour les sites les plus optimisés (et avec Full Page Cache) jusqu’à 800 ms pour les sites ayant des soucis, voir 2,5 secondes ou plus pour ceux qui sont totalement en carafe.

Comment mesurer tout cela ?

Avec Chrome par exemple !

Firefox et Opera le font aussi mais la console de Chrome est là par défaut et elle est extrêmement complète. Vous pouvez y accéder en cliquant avec le bouton de droite n’importe où dans une page et ensuite, choisissez « Inspecter l’élément ». Ensuite, cliquer sur le 3° onglet qui devrait s’appeler « Network ». Maintenant, recliquez sur votre page et faite un CTRL+R (pour recharger la page).

Ce que vous devriez avoir devrait ressembler à ça : 

Sur cette exemple pris avec news.google.fr, on voit que le premier élément est http://news.google.fr qui est en fait l’index.php de Google news.

Quand on passe la souris au dessus de la barre bleue, on obtient un détail, le temps « Waiting » et le temps « receiving ». Le temps qui nous intéresse est le « Waiting ». En combien de temps le serveur à générer le contenu HTML à partir du PHP pour ensuite nous le donner à télécharger (le « receiving »).

Une petite échelle pour se donner une idée

  • 50 ms ou moins : votre site est une star. Superbement optimisé sur son « core », son fichier principal PHP et aidé par du cache statique (soit du FPC de Magento, Nitrogento ou litespeed, soit celui d’un Varnish). Vous êtes au top.
  • 50 à 150 ms : sur du Magento ou tout autre framework un peu solide (wordpress, drupal etc.), c’est un très bon temps.
  • 150 à 350 ms : c’est la moyenne des sites en Magento CE, correctement développé mais sans FPC.
  • 350 à 800 ms : vous êtes lent. Il y a un manque d’optimisation du code.
  • plus de 800 ms : vous avez un problème de code.

Qu’est-ce qui contribue au temps de chargement ?

Ensuite, le temps de l’interprétation PHP n’est pas tout. Déjà, vous ne devriez pas trouver d’autres appels à PHP plus loin dans le chargement, sinon c’est globalement un soucis en général.
Une fois que votre navigateur à reçu le HTML de la page, il va savoir quelles images, quels CSS et quels JS il va devoir charger pour remplir la page et la rendre « active ».

Les bonnes pratiques

En général, les experts s’accordent à dire qu’il ne faut pas charger plus de :
  • 5 JS
  • 5 CSS
  • 70 images
  • 700 Ko d’information

Au delà, votre page devient lourde.

J’ai vu des hérésies avec 180 fichiers chargés, ou 1,2 Mo de données, ou 25 fichiers Javascript ou encore 15 JS. C’est une erreur clef. En premier lieu car il faut le temps de les récupérer, temps quasi incompressible puisqu’il dépend de la connexion du visiteur et de son navigateur (qui fera 6 à 12 récupération en parallèle).

Ensuite, ramener les informations c’est bien, mais après votre ordinateur et son navigateur vont devoir les interpréter, ce qui prend aussi du temps. Pour aider à diminuer le nombre d’éléments à charger, deux méthodes :

  • Le Minify (pour les JS et CSS), qui consiste à regrouper les fichiers en un et à l’optimiser
  • Le Sprite, qui va réunir plusieurs images (en général les 2/3) en une seule grande, qui sera découpée par le CSS

 Dans la console Chrome, vous pouvez voir ces paramètres ici :

Ici, on est dans les meilleures pratiques (guess what, Google), 57 requêtes, 118 Ko. Bon les 11 min de chargement c’est parce que la page charge en continue. Mais en fait, j’avais le tout à l’écran après 425 ms.

Ensuite, si vous cliquez sur chacun des onglets, Stylesheets, images et scripts, vous verrez ce qui est chargé en terme de CSS, PNG/JPG/GIF, et JS (Javascript). (Ici, 5 CSS et 7 JS)

ça, c’est du code et de la conception. C’est à la Web Agency de s’en occuper.

ETAPE 2 : Vérification de la grammaire HTML & CSS

Les normes d’Internet, ce n’est pas moi, pas les développeurs ou pas Microsoft qui les fixe.

C’est le W3C. Ce qu’ils disent, c’est la norme et elle vaut pour TOUT le monde. Pour vérifier que les choses sont faites correctement, il existe 2 sites que le consortium W3C met à votre disposition :

Bon, l’heure du bilan sonne. Vous avez des erreurs ? Ce n’est pas forcément très grave. Tout dépend du type et du nombre.

Au validator HTML, avoir moins de 10 erreurs mineures n’est pas très grave (à corriger malgré tout). Au delà de 10, ou si vous avez des balises HTML non fermées, il y a eu du laissé-aller dans la conception du template HTML et donc, probablement, ailleurs dans le code PHP aussi. Au delà de 20 erreurs, c’est dommageable, au delà de 50, c’est inacceptable.

Au validator CSS, c’est plus complexe. La machine CSS est un peu complexe et avoir tout bon est très difficile. Mais là encore, des échelles existent et des erreurs plus ou moins graves mènent à des pertes de performances plus ou moins importantes. Un vingtaine d’erreurs mineures sont tolérable. A partir de 30/40 ca devient mauvais et cela ralentit l’affichage de la page dans le navigateur du client.

D’une manière générale, la qualité et le nombre d’erreur HTML / CSS en disent souvent très long sur la qualité globale du code du site Web. Si vos templates HTML/CSS sont truffés d’erreurs, il est très probable que votre code PHP ait subit le même traitement qualitatif.

Ca, HTML & CSS, c’est du CODE, c’est à la Web agency de s’en occuper.

ETAPE 3 : Pagespeed

Google a fixé un « ruleset » un groupe de règle de bonnes pratiques en terme de performances. Elles sont logiques et appréciables, rien à redire, c’est du bon boulot de pro et exhaustif avec ça.

Afin de tester si votre site est optimal, au regard de ce jeu de règles d’optimisation, vous pouvez aller à l’adresse suivante : https://developers.google.com/pagespeed/

Ça, c’est parfois du Code, parfois de de l’hébergement.

Web agency, pour tout ce qui est :

  • Combine image…
  • Use Efficient CSS selector (une horreur à faire)
  • Remove unused CSS
  • Minify CSS
  • Defer parsing of Javascript
  • Minify Javascript
  • Avoid bad requests
  • Inline small CSS
  • Inline small Javascript
  • Minify HTML
  • Minimize redirects
  • Optimize images
  • Optimize the order of styles…
  • Put CSS in the doc head
  • Served scaled images
  • Specify a character set early
  • Specify Image dimensions
  • Avoid CSS Import
  • Prefer asynchronous resources

Hébergeur, pour tout ce qui est :

  • Leverage browser caching
  • Enable Gzip compression
  • Enable Keep alive
  • Minimize request size
  • Remove query strings…
  • Specify a cache validator
  • Specify a Vary:Accept…

Contacter celui qui est concerné par la question soulevé par Google Pagespeed.

Il faut également souligner que Yahoo à un bon jeu de règles aussi appelé Yslow, disponible notamment en extension pour Firefox. Beaucoup d’informations sont communes aux deux plugins mais certaines sont uniques à chacun d’entres eux. Je vous recommande l’usage de www.gtmetrix.com si vous voulez avez l’analyse des deux jeux de règles, peu importe votre navigateur.

En prime, ces plugins vous fournissent des éléments intéressants, comme les images de votre site, déjà ré optimisées :

Bon, il reste à cliquer, télécharger l’image optimisée et l’envoyer au site. Simple non ?

Etape 4 : Les fichiers de Logs

Les fichiers de Logs sont une mine d’information. Elle est un peu plus complexe à comprendre mais sur le fond, beaucoup de choses sont explicites. En premier lieu, les fichiers de logs Magento. Ils se trouvent dans l’arborescence de votre site Magento :

  • Ils se situent dans le répertoire var/log de Magento
  • Le premier s’appelle : exception.log et le second system.log
  • Si ils contiennent des :
    • Debug : c’est que le mode debug est activé, ca consomme beaucoup de ressources
    • Warning : c’est pas idéal, cela dénote un problème mais le site peu fonctionner. A corriger cependant.
    • Notice : rien de trop grave en général. En tenir compte mais souvent anodin.
    • General error : si vous trouvez cela, c’est très mauvais
    • ERR : c’est très mal et souvent symptomatique de gros soucis

Bon si vous avez une erreur tous les trois mois, ce n’est pas un soucis, si c’est trois par jour, c’est un (probablement un gros) problème.

Ces points relèvent de la Web Agency, c’est le code le problème.

Il existe aussi quelques fichiers intéressants liés au système LAMP (Linux, Apache, Mysql, PHP) :

  • Apache access.log
  • Apache error.log
  • Php error.log

Ces trois fichiers contiennent des informations en général un peu plus techniquesµ. Si dans le fichier access.log ou error.log vous avez des 404 ou 500, en général il manque des ressources ou PHP fait planter apache, dans les deux cas, appelez la web agency. Dans les autres cas, appelez l’hébergeur pour avoir un diagnostique.

Etape 5 : Le recours au pros

Si ces pistes vous ont été utiles et vous souhaitez être assisté plus avant, ou si vous n’avez pas trouvé les soucis de fond, vous pouvez appeler des experts :

  • NBS System (contact[at]nbs-system.com) pour la configuration système, réseau, les tests de charge et l’optimisation
  • L’Ecommerce Academy (contact[at]academy-ecommerce.com) pour l’audit de code, notamment avec AuditGento

Les 10 erreurs les plus communes

Elles ne sont pas dans l’ordre d’importance, mais les voici :
  1. Le code PHP où on trouve des erreurs ou boucles non optimisées, on en trouve souvent trace dans le fichiers de logs. Encore une fois, ne jamais modifier le CORE de Magento. (on en voit encore, si si)
  2. Les taches Cron mal développées qui envoient les serveurs dans le mur
  3. Les templates CSS / HTML mal conçus et buggés
  4. Les php_memory_limit beaucoup trop élevés (type 1 ou 2 Go, très dangereux)
  5. Les pages surchargées (trop de CSS, JS, images)
  6. Les inclusions de tout et n’importe quoi. Par exemple sur la home Google +1, Facebook, affiliation, criteo, lengow, retargetting, tags de comptage, régies publicitaire, géolocalisation, etc. Certain sites comportent 5 à 10 includes externes (visible dans la console Chrome) mais cela induit un autre soucis. Si un de ces tags rame ou est indisponible et qu’il est bloquant ou mal placé, il ralentit tout le site.
  7. Le mauvais paramétrage du fichier local.xml de Magento. Par exemple, le plus typique, avoir un slow backend qui soit mal déclaré (à autre chose que Database ou File) et donc non structurable par Magento, qui rend tout le cache Magento inefficace…
  8. Les mauvais appels au cache (abonnements à des tags trop larges) ou tout simplement l’oublie de l’ajout au cache (qui doit être explicite dans Magento)
  9. La mauvaise configuration du serveur (non optimisation, usage des disques durs, etc.)
  10. L’usage de version lib_memached et memcached qui sont en conflit (typiquement dans le fichier system.log, on retrouve « can’t get filing percentage)

Quelques accélérateurs de diagnostiques

  • Zend server. En version pro, il contient Zend Code Tracer. Cet outil va vous aider à pointer directement où se trouvent les fonctions les plus lentes
  • Mysql Enterprise Console. Elle contient aussi des informations sensibles. A défaut, regarder les « Slow Query » peut vous indiquer rapidement où se trouvent les soucis
  • En général, les hébergeurs donnent accès à des outils de type Munin ou équivalent. Cela donne des informations précieuses sur l’utilisation des CPU, RAM, Disques, le nombre d’interrupts etc. Précieux.
  • Les Logs Magento. Ils contiennent beaucoup d’informations très intéressantes
  • Les méthodes décrites dans cet articles sont aussi très utiles pour se faire une idée et aller vers les bonnes pistes