juin 24

Les soldes, ce moment critique

La grande majorité d’entre vous ne l’ignore pas : c’est les soldes.

Et la plupart du temps, les soldes, c’est un moment de grandes ventes pour les sites de E-commerce, de 15 à 30% du CA de l’année peut se jouer sur cette étroite période de 15 jours. En fait, techniquement, le CA est même concentré sur les deux premiers jours majoritairement.

C’est donc un moment à ne rater sous aucun prétexte.

Bien que ce blog ait été dédié à Magento pendant des années, nous (NBS System) travaillons aujourd’hui  avec de nombreux frameworks : Drupal Commerce, Prestashop, Hybris, Oxid et bien sûr toujours avec Magento.

Actuellement sur 800+ sites hébergés, nous avons 4 sites avec des problèmes. Les 4 sont des soucis applicatifs et nous n’avons (je touche du bois) aucun pépin en exploitation, hébergement, infogérance. Mais ces problèmes proviennent de cas classiques alors autant vous faire profiter de notre expérience. Le seul glitch important, c’est le plantage d’un noeud majeur de routage en France, qui nous a impacté indirectement 10 minutes avant que nous ne passions par d’autres routes.

Mettre en production son site de E-commerce

Il est tentant de mettre en place son nouveau site pour les soldes mais c’est une très très mauvaise idée.

Conseil 1 : ne pas mettre un site en production « juste avant les soldes »

Une nouvelle release d’un site peut tout changer.

Changement de comportement, changement de design, de charge de travail pour les serveurs, c’est tout un art délicat. Le principe de précaution veut que l’on mette en place le site quelques semaines avant, disons deux au minimum. Ensuite un petit test de monté en charge, simulé avec des outils ou directement avec un mailing d’animation commercial sera un garant du bon comportement (ou non) du nouveau site.

Rater le premier jour des soldes est un désastre que l’on ne peut se permettre, mieux vaut tourner avec la version précédente du site pour assurer dans le doute plutot que de tenter par tous les moyens d’avoir le tout dernier gadget ou le nouveau tunnel de vente. Au pire, un mailing qui montre un soucis sur le site 15 jours avant laisse le temps aux experts de se concerter et corriger le tir. PRECAUTION on vous dit !

Conseil 2 : Analyser avec quelques outils simples

Afin de partir tranquille, vous pouvez par vous même faire quelques tests simples.

W3C validator

Le W3C c’est l’organisme de validation de la norme HTML. This is the law.

http://www.W3C.org/validator

Si votre site n’est pas propre, cela rendra des erreurs dans les différents navigateurs et la pollution visuelle et/ou technique pour le visiteur sera désagréable. Le site permet de valider le site en HTML et au niveau de ces CSS. Le gros avantage, c’est qu’il vous pointe les erreurs directement avec les lignes. Balises non fermées, problème de consistance, grammaire incorrecte.

C’est un minimum avant de partir en production que de passer ce test avec  succès ou au moins sans casse majeure.

W3C CSS validator

http://jigsaw.w3.org/css-validator/

même principe, mais pour les CSS.

Firebug, Dragonfly, Webdevelopper, etc.

Les navigateurs avancées (Firefox, Opera, Chrome) vous  permettent d’analyser vos pages et les temps de chargement des différents composants. Pour ne parler que du plus célèbre, Firebug est un outil en or. Vous pourrez y trouver des informations très intéressantes sur le chargement de vos pages. Ce qui y est chargé, comment, à quel vitesse (parfois combien de fois).

Si vous chargez 2 fois une librairie JS de chez Jquery, vous aurez peut être des conflits, si vous avez 20 javascripts cela va compliquer la tache du browser. Avoir des CSS bourrés d’erreurs de grammaire complique (et donc ralentit) le rendu par le navigateur. Charger des composants externes (depuis d’autres sites/serveurs) peut ralentir votre page, voir la bloquer parfois.

Les consoles de debug des browsers peuvent vous aider sur tous ces points alors profitez en, de plus le rendu est assez lisible et compréhensible, même si vous n’êtes pas développeur (comme moi par exemple).

Ça ressemble à ca :

On est sur un site très bien conçu dans le cas présent, je n’ai montré aussi que le début du load mais il y a beaucoup plus d’éléments.

Sur la console nous pouvons voir les onglets Tous (tous les éléments) puis chacun d’entres eux un par un. Vous pouvez aussi analyser votre HTML, vos CSS, vos JS, votre DOM et tout cela en un seul outil.

Les erreurs faciles à détecter avec cet outil :

  • Ressources dont le chargement ne se finit pas (petit cercle qui tourne en continu et barre qui s’allonge)
  • Ressources externes lentes à charger (logo paypal depuis le site us par exemple ou un JS sur le serveur d’un prestataire)
  • Ressources chargées de multiples fois (CSS/JS, parfois même la homepage rappelée par la homepage, sisi ca s’est vu)
  • Erreurs 404, 501, 201, ou code de redirection 301/302 par exemple
  • Temps de chargement du core (première ligne, sur cet exemple 317 ms, ce qui est un bon temps pour Magento)
  • Temps global de chargement
  • Poids global du chargement (on va parler des « valeurs » repères plus bas)
  • Temps des attentes, réception et résolutions DNS
  • Nombre de composants externes appelés
  • Temps avant le chargement complet du DOM Vs temps de chargement complet
  • Temps de rechargement une fois la page chargée une première fois

Pas mal pour un seul outil non ?

Yslow, Pagespeed, Gtmetrix,

Mes grands amis. Ils donnent des axes d’améliorations et d’optimisations de votre site tout en vous donnant une « note ». GTmetrix est une interface Web qui vous permet d’utiliser les plugins Yslow & Pagepeed (essentiellement compatibles Firefox) sans avoir Firefox. Ces deux jeux de règles d’optimisations de Yahoo et Google sont utiles, bien pensés et accompagnés de conseil en ligne ou directement dans l’interface. Vous pouvez avec ces outils :

  • Détecter les images non compressées (ou pas assez)
  • Les CSS mal codés
  • Les optimisations de type gzip/etag/expire headers
  • Le fait d’avoir ou non un usage des CDN/medias serveurs
  • la compression et minify des CSS/JS/HTML
  • les 404
  • et de nombreux autres points.

Avoir un B/B sur GTmetrix est relativement simple pour peut que l’on optimise un peu son site et son hébergement et c’est assez agréable au surf pour le visiteur au final.

Les sites web de tests

Trois très bons sites qui vont vous donner des indications précieuses : (n’oubliez pas que la plupart sont aux US et donc que les temps de chargements sont souvent plus élevés à cause de la latence réseau)

http://www.whichloadsfaster.com/

Comparaison entre deux sites sur les temps de chargements. C’est simple mais assez efficace. Si vous avez votre ancien site sur un serveur et votre nouveau sur un autre, cela peut être un très bon bench.

http://websiteoptimization.com & http://www.webpagetest.org/

Simple, efficace, beaucoup d’informations censées et lisibles ressortent de ces deux sites.

Munin & Google Analytics

Deux outils simples chacun de leur cotés. Munin (et d’autres) donnent des informations sur les statistiques vitales de vos serveurs (charge  CPU /RAM / DISQUE / BP etc). C’est un outil, qui est en général, mis à disposition par votre hébergeur (celui-ci ou un autre équivalent). L’intérêt est de pouvoir coupler les informations, par exemple slow queries, activité réseau et CPU pour avoir un diagnostique d’une panne ou d’un ralentissement.

De son coté, Google Analytics intègre maintenant le temps de chargement des pages. Très utile pour voir l’évolution dans le temps de ceux-ci. Voir mon précédent post ici.

Zend server

La console de Zend Server aide notoirement à identifier les coup de rame du site. Une des clefs : le code tracer. Cet outils permet d’analyser les exécutions PHP qui sont les plus lentes et à pointer directement les lignes en cause. C’est assez bluffant et cela réduit habituellement considérablement les temps de recherche des bugs.

D’autres outils ont été posté dans un précédent article ici.

Conseil 3 : Le Test de charge

Le test de charge c’est une clef de succès. Le fait de faire réaliser un test de charge par votre hébergeur avant la mise en ligne vous permet de savoir où vous aller.

Ce n’est pas une vérité absolue car on ne peut pas simuler tous les comportements utilisateurs mais, en général, si un gros pépin arrive à l’horizon en terme de performances, le test de charge le montrera. Sur les sites assez simple, on arrive même à une précision d’environ 5 à 10% de la réalité, ce qui est très intéressant.

Quelques points de repères

JS : 4/5 par page semble une valeur raisonnable. Concaténé cela peut se réduire à un si le site est bien codé mais dépasser 10 est, en général, une mauvaise idée.

CSS : 3/4 maximum, de la même façon, cela peut se concaténer en un fichier.

Images : 50/60 maximum, si possible. Après ca devient un peu lourd à télécharger et donc long pour peupler une page. Tout le monde n’a pas une 20 Mb/s à la maison.

Nombre total d’éléments sur la page : 80 semble un maximum, après on est dans une zone orange, à plus de 100 c’est exagéré.

Nombre de produit par page : Magento conseil quelques dizaines au maximum pour le load.

Taille de la page : 1 Mo max. C’est presque trop d’ailleurs. Au moins à l’initial loading, après du streaming peut arriver en route ou du javascript (Ajax) charger en background.

Temps de chargement : 1 seconde ou moins on est au top, 2 secondes c’est correct, 3 c’est limite, 4 ca comment à être trop, 7 ca devient insuportable, 10 le client est partit. Bien sur, c’est le temps avant que la page soit visible et les menus réactifs. Il peut continuer à se passer des choses après, c’est moins important.

GTmetrix : avoir une note de B/B est très faisable sans engager des sommes folles et cela améliore l’expérience client ! A/A cela demande plus de travail mais l’on obtient rien sans rien ;) Le site de NBS System en est à 96/94 et cela nous a prit 3 J/H de plus (mais c’est un peu notre dada).

Ratio entre visiteur uniques par jours et visiteur simultanés en pic : en général on considère un facteur 200 à 400 sur un site normal. Ce qui veut dire que si vous avez ~20 000 visiteurs uniques par jours, vous pouvez compter que votre crête de fréquentation à un moment donné sera de ~100 à ~200 personnes connectées simultanément. La valeur moyenne que nous retenons en général est 280.

Nb de visiteurs unique pour un serveur (valeur pour Magento CE) :

  • Petit VPS (2 cores 5650 / 2 Go) : ~5000 VU/j
  • Gros VPS (8 cores 5650 / 2 Go) : ~20 000 VU/j
  • Gros serveur  dédié : ~40 000 VU/j
  • Serveur dédié + DB dédiée : ~60 000 VU/j
  • Infrastructure : 50 000 Visiteurs uniques par jour par Web frontaux, 80 000 en enterprise ou avec Nitrogento.

Extend To Cloud (E.T.C)

Le système exclusif créé par NBS System permet, en 3 minutes 30, d’apporter du renfort avec des machines de Cloud. Avec l’usage de SAN, l’overhead de la virtualisation est réduit à 4% et les performances sont donc parfaitement comparable à une machine physique.

Par contre, le fait de pouvoir les mobiliser au moment du besoin, pour les soldes, pendant les ventes de fin d’années, c’est une force indéniable. Parfois, les clients nous préviennent au dernier moment d’un passage télé, pas de soucis, E.T.C amène des renforts en quelques minutes.

Le gros avantage, c’est que la facturation ne se fait que sur la consommation et non tout au long de l’année. Si un E-commerçant fait ~20 000 visites par jours en temps normal, il tient sur un serveur. Si il fait 100 000 pendant le premier jour des soldes, il n’a besoin de serveurs de Cloud que pendant un jour et n’est facturé que pour une journée. Économique et efficace !

Plus d’information ici.

Tools & méthodes d’optimisations

Data URI : Pour les petites images, moins de 2 K€, il est intéressant de les intégrer sous formes de chaine texte dans le CSS (en plus ca se compresse), pour la méthode, voir ici : CSS URI

Zend server : Le soft fournit une stack PHP robuste et optimisée avec des capacités de FPC et un accélérateur d’opcode du style APC.

Optimisation progressive et dégradation élégante, voir l’article ici.

Nitrogento : une extension spécifique pour Magento qui boost méchamment les performances. (Voir le lien sur les performances)

Magento Enterprise Edition : Elle embarque du Full Page Cache, ce qui aide pas mal au rendu des pages.

Serveur de Média ou CDN : cela permet au client de rappatrier les données plus vite et plus prêt de chez lui.

Fooman speedster : Un module qui fait la concaténation des JS et CSS (Nitrogento le fait aussi)

Après d’autres framework ont des extensions d’optimisation spécifiques (comme W3TC pour WordPress par exemple) et bien sûr il y a beaucoup à faire du coté serveur, ce que votre infogérant devrait faire pour vous. Par exemple pour Magento, nous avons environ 20 optims spécifiques aux serveurs ou dans l’architecture.

Conclusion

Don’t take any useless risks, optimize, sale !!!

écrit par Philippe Humeau \\ tags: , ,