oct 20

Vous vous souvenez surement des Darwin Awards si vous êtes des lecteurs réguliers de ce blog.

Le concept des Darwin Awards est de prendre les plus gros échecs de sites, d’intégration ou de support, c’est de la détente mais ces articles (le MDA I et le MDA II) ont attiré beaucoup de lecteurs.

Aujourd’hui, Vincent et l’équipe d’infogérance NBS System vous propose l’inverse, le top des sites qui envoient le plus ! Ils sont rapides, très très rapides et ces sites sont des petites merveilles de régularité, de l’horlogerie du Ecommerce, sous Magento. Magento c’est lourd ? C’est lent ? En fait c’est surtout dépendant de la qualité du code, comme nous le prouve les exemples suivants et ca peut être très rapide un Magento.

Une démarche positive donc, qui montre qu’avec Magento, une bonne équipe d’intégration, un client sérieux dans ses demandes et un hébergeur qui connait son boulot, on peut tirer le meilleur de Magento. Attention, cet article ne parle que de performances et pas de fonctionnel. C’est la rapidité perçue par l’utilisateur qui m’intéressait.

Voici donc quelques sites, mesurés selon le baromètre suivant :

  • Avec la console de Google Chrome
  • Chargement complet à l’écran
  • Hors streaming
  • Hors appels externes (maps, régie pub, trackers, etc)

http://www.linea-chic.fr/
DOM complet : 632ms
Home complète à l’écran : 987ms
Consultation d’un article : 1.43 s / 665 Ko (soit 465 Ko/s, échelle qui ne mesure pas un débit mais un temps de rendu)

Développé par Gabriel Bouhatous. Le site est sur une version CE 1.4 de Magento.
Le développement a prit énormément de temps mais le résultat est là et bien là, un chargement redoutable.

http://www.gazzar.ch
DOM complet : 638ms
Home complète à l’écran : 1.24 s
Consultation d’un article : 1.29s / 324 Ko (soit 251 Ko/s)

Ouch, sous la barre de la seconde et demi, même pour une page produit… C’est un résultat impressionant. Un site qui utilise par ailleurs Nitrogento et donc un Full Page Cache et de nombreuses optimisations. Le résultat est là, le code est également propre, rien à dire c’est un avion de chasse.

http://www.easyparapharmacie.com
DOM complet : 1s
Home complète à l’écran : 2,13 s
Consultation d’un article : 2.1s / 368 Ko (soit 175 Ko/s)

Développé par … Eux. Enfin lui, le patron et deux stagiaires…
Le développement n’est pas parfait, il reste des requêtes qui ne se finissent pas ou des choses un peu étrange mais la rapidité est indéniablement là. Au final, avec peu de moyen et tout en interne, Easy para pharmacie se dote d’un site très efficace. Le temps de chargement d’un produit pourrait être optimisé et le nombre de plugins allégé mais dans l’ensemble, c’est très rapide.

http://www.zadig-et-voltaire.com/eu/fr/eshop/
DOM complet : 489ms
Home complète à l’écran : 1,13 s
Consultation d’Article : 1.7s / 1.18 Mo (694 Ko/s)

Développé par Baobaz sur une version EE (1.8 de mémoire). Le site est riche fonctionnellement, élaboré graphiquement mais toujours rapide et efficace, le FPC de la version EE aide mais ca reste une très belle intégration. On remarque, notamment au temps de load du DOM, que des optimisations ont été menées, Zadig y met les moyens et ca se sent.

http://www.whisky.fr
DOM complet : 1.07 s
Home complète à l’écran : 2.21 s
Consultation d’Article : 753 ms / 450 ko (597 Ko/s)

Un site repris récemment en main par l’Agence DnD après un mauvais départ. La version n’est pas encore complètement nettoyée de ses précédentes souffrances mais ca avance dans le bon sens. Après seulement 3 semaines de travail, l’Agence DnD livre un site déjà nettement plus optimisé, qui charge trèssss vite. Beau boulot, as usual. Bientôt Nitrogento on top, ca va faire très mal.

http://www.lancaster.fr
DOM complet : 1.89 s
Home complète à l’écran : 2.24 s
Consultation d’Article : 2.75 s / 1.5 Mo (540 Ko/s)

A nouveau un site DnD mais avec la particularité de tourner en CE et d’avoir énormément de graphismes, de vidéos, de flash etc. Au final la fiche produit trinque, mais à la demande du client, elle est très graphique, élégante et design. Quand c’est lourd, il faut le charger, mais le débit de rendu reste de 540 Ko/s ce qui est assez impressionnant avec une page (home ou produit) aussi lourde. Bientôt en EE et avec Nitrogento, c’est partit pour être une Ferrari.

http://www.debonix.fr/
DOM complet : 836ms
Home complète à l’écran : 2.6 s
Consultation d’Article : 1.32s / 683 Ko (483 Ko/s)

Au delà du look graphique qui n’est pas très sexy (d’un autre coté c’est de l’outillage, pas des sous tif), le site de debonix charge vite. Là encore, comme Easy para Pharmacie, pas de débauche de moyen et pourtant un résultat très satisfaisant, le site pourrait avoir de nombreuses optimisations et notamment sa home pourrait passer sous la barre des 2 secondes facilement avec juste quelques optimisation et un coup de Nitrogento.

http://www.gemo.fr
DOM complet : 1.11 s
Home complète à l’écran : 1.53 s
Consultation d’Article : 1.68s / 400 ko (238 Ko)

Un site qui est à la fois complet, fonctionnel, graphique et en Magento Enterprise Edition mais qui reste d’une rapidité impressionnante. Malgré des streamings, des appels externe, des graphiques lourds en home, la homepage charge en 1.5 seconde… Wow… La page article elle soufre un peu plus avec un débit de rendu assez moyen mais le site est réactif, particulièrement la home. Bel effort, beau résultat, développé par Adfab.

http://www.motorisationplus.com
DOM complet : 1.05 s
Home complète à l’écran : 1.21 s
Consultation d’Article : 2.41s / 1.37 Mo (560 Ko/s)

Quelques petites erreurs programmatique sur la fiche produit semble être la seule ombre au tableau pour ce site dont la home défit les statistiques. 1.21 secondes, c’est très rapide et tous les sites de la maison sont de la même eau. Simple, épuré, efficace.

Voici donc une  dizaine de sites, qui prouvent clairement que charger en moins de 2,5 secondes c’est très faisable, moins de 2 secondes également et que quand on y passe du temps, qu’on a des codeurs de pointe, un hébergeur spécilisé et quelques optimisation bien placés, éventuellement une version EE, on peut passer sous la barre de la seconde et demi voir même de la seconde. Alors ? Magento ? Toujours aussi lent ?

écrit par Philippe Humeau \\ tags: , ,

sept 21

J’ai enfin eu le temps de le terminer, j’espère qu’il vous sera utile, vous pourrez le trouver ici :

http://www.nbs-system.com/blog/magento-optimization-howto.html

écrit par Philippe Humeau \\ tags: , , ,

mai 19

Foreword

After some months in the field of Magento managed hosting, NBS System decided to create a new Magento extension : Nitrogento.

This extension aims at giving more performances to Magento shops. Mainly, 7 points are covered (more will come with our strong roadmap) :

  1. Full Page Cache
  2. Block Cache
  3. Custom Bloc Cache
  4. Auto Sprite
  5. HTML, JS & CSS minifying & compression
  6. HTaccess fine tuning
  7. CDN auto deploy

Magento Benchmark with Nitrogento

The benchmark context

This said, the main key here is the performance. So what best way than making benchmarks ? Well we tryied almost all of them ! And I’ve to say that there is a lot of benchmarks around !

We installed a basic demostore on http://demostore.nitrogento.com and did the same demostore with Nitrogento on http://nitrostore.nitrogento.com. The server hosting the demo/nitro stores is the very same, actually, it’s even the same machine. The machine was a Quad core 5650 VPS with 8 Go of RAM.

Benchmark used

We choosed to used the following benchmarks, which are considered the most accurate and renowned :

PS : We know some of you love our product but, please, can you consider doing your benchmarks on your own servers, or at least not to often on ours, because recently we had a lot of people benching both sites (http://nitrostore.nitrogento.com and http://demostore.nitrogento.com).

The benchmark issues to be considered

Some tests gave a false results for two reasons :

- First, the  server is located in France. So when you use GTmetrix (for exemple) the test server is located in the US. This means that we have a bit of lag between the test machine and the target machine. One in the other, this is not a big issue since only the real load time is false but the comparison stay exact since both Nitro & Demo stores are located in France so they are in the exact same situation.

- We also found a funny problem. Google and Yahoo (and many others) recommand using multiple CNAMES/HOST to host the static files. That way, your browser is able to download a lot of file at the same time and not only 8 by 8 or 12 by 12 (the exact multi thread number is browser dependant). But when you have several CNAMES pointers, this makes several DNS resolutions and … this can be a problem depending on various factors. The precise problem came up with www.wichloadsfaster.com (WLF). By make 5 DNS requests on Nitrostore and only 1 on Demostore, he claimed that Demostore was faster.

Actually this is not true, but the 4 more NS lookup took a bit more time (resolution from US to France) and as WLF only test the core load (don’t take the pictures, CSS, Js again) it found Nitrostore to be slower. So to get realistics results, the WLF test was made with the CDN feature of Nitrogento desactivated, to avoid having more DNS lookup to do than on a basic demostore. In real life, this CDN feature bring you a lot and we recommand it, of course :)

We noted these troubles in the table of results.

(*) stands for « longer time than real since test machine and bench machine are in US and FR »

(**) stands for « desactivated CDN not to compromise results »

Results

www.whichloadsfaster.com (500 runs)
Time (*)
Demostore 327 ms
Nitrostore 134 ms

Nitrostore : 2,4 times faster.

www.gtmetrix.com
Grade Time to full load
Demostore C/C (72/76) 3,15
Nitrostore A/A (96/94) 2,18

Nitrostore : 43% faster
Nitrostore : +20% to yslow/pagespeed tests

www.MageSpeedTest.com (*)
Trans/sec Time / request
Demostore 12,38 1,86
Nitrostore 28 0,55

Nitrostore : 2,2 times more transaction per seconds
Nitrostore : 3,38 times faster per request

Firebug – Network load time
Requests Time (s) Size (Ko)
Demostore 49 2,14 556
Nitrostore 28 1,35 293

Nitrostore : 42% less HTTP resquests
Nitrogento : 37% faster to load
Nitrostore : 40% less bandwidth / transfer

Funkload (home hammering – 200 users)
Page / sec Page time APDEX
Demostore 25 16 s 0,4
Nitrostore 300 0,7s 1
Funkload (Full scenario – 50 users)
Page / sec Page time APDEX
Demostore 35 10 s 0,55
Nitrostore 100 3,5 s 0,65

Under heavy load,
Nitrostore : up to 18 times faster on the homepage and 3 times faster in the full scenario
Nitrostore : up to 12 time more home page served and 3 times more full scenario
Nitrostore : Continuous perfect APDEX on homepage and 15% better APDEX indice (user experience) on complexe scenario

www.webpagetest.org
Document complete Fully Loaded
Load time (**) First Byte (**) Start render Dom Elements Time (**) Requests KBytes In Time (**) Requests KBytes In
Demostore first 5,7 10 s 0,55 332 5,7 50 574 5,7 50 574
Demostore repeat 1,9 10 s 0,55 332 1,9 2 7 1,9 2 7
Nitrostore first 3,6 3,5 s 0,65 318 3,6 29 303 3,6 29 303
Nitrostore repeat 1,5 3,5 s 0,65 318 1,5 4 18 1,5 4 18

Trial version

But you know what ? Test it by yourself, there is a Trial version there : www.nitrogento.com

écrit par Philippe Humeau \\ tags: , , , , ,

avr 27

Quelques outils intéressants

Nitrogento

Eh oui, il arrive…

Après 6 mois développement et deux de Beta tests, des semaines de création de sites et de traduction de documentations, de benchmarks et de tests, voici qu’approche la sortie de Nitrogento !

Cette toute nouvelle extension pour Magento va vous permettre d’obtenir un « All in one » d’optimisation :

  • Création du Sprite et patch du thème
  • Ventilation des ressources statiques sur les CDN
  • Concaténation, Minify et Compression des JS & CSS et du HTML
  • Block caching des blocs qui ne sont pas déjà dans le cache Magento
  • Custom Caching, mettez votre propres blocs « maison » dans le système de Cache Magento
  • Full Page Cache, ehhhhh oui, même pour la CE !

Autant dire que ca va légèrement dynamiser votre site… De plus, les fameux blocs maisons (custom) qui ne sont pas gérés actuellement par le cache de Magento pourront y être intégrés grâce aux Hooks que crée Nitrogento pour vous.

On va passer de Moogento à Maaaaagento, moi je vous le dis !

Date prévue de sortie : le 3 mai 2011 !

Jetprofiler

Cet outil est une vraie petite merveille. Un bon monitoring de son Mysql, rien de tel.

Comme expliqué dans mon précédent Post, le problème de mysql c’est qu’on ne peut pas le faire grossir proprement. En fait au dela de 4 cores, c’est inutile voir nuisible. Donc on multiplie les serveurs. Même si Magento ne tape pas très intensément sur la DB (en général) c’est parfois un des points de contention.

Une implémentation particulièrement complexe au niveau SQL peut aussi provoquer des surcharges ou une Cron un peu gourmande. Bilan, le Mysql rame et on se demande pourquoi.

Avec Jetprofiler, vous pourrez rapidement trouver plus d’information, qualifier le problème en quelques clics.

Pagespeed Online (by Google )

Alors ce n’est pas exactement nouveau, Google Pagespeed, on l’aime à la maison mais là, c’est le petit plus à la Google.

Après le plugin pour Firefox, le GT Metrix, on a maintenant un chouette site dédié chez Google à Pagepseed. Rien de révolutionnaire mais c’est très pratique, notamment pour les gens comme moi qui ne sont pas fan de Firefox, car c’est en ligne. Mais en plus, c’est directement linké au niveau de la KB de Google et CA, c’est sympa.

On ne sait pas ce que c’est que le Defer Javacript blablabla ? Eh ben on clic sur le lien « learn more » et c’est expliqué, merci Google. Allez, un petit exemple :

http://pagespeed.googlelabs.com/#url=www.nbs-system.com

Mytop (mysqltop)

Aussi simple que possible, Mytop, c’est comme le top d’unix mais pour Mysql.

Voila, tout est dit, un petit outil CLI (Command Line) pour permettre de monitorer en un clin d’oeil son Mysql. Ca ne va pas faire le même boulot que Jetprofiler mais c’est light et c’est déjà pas mal. http://jeremy.zawodny.com/mysql/mytop/

Innotop

Dans la série « top est notre ami », innotop, ca parle, ca parle… de Top pour innodb. XAPRB nous délivre son outil plus avancé que mytop, bien plus avancé même, mais c’est un bonheur car pour les amoureux de la command line, il y a tout ou presque.

http://www.xaprb.com/blog/2006/07/02/innotop-mysql-innodb-monitor/

Atop

Désolé, ca doit être le chocolat de paques, je fais une petite fixation sur les top en ce moment. Atop, c’est comme top, mais en plus sympa. Les process sont mieux triés, le package est disponible en debian stable, alors comment parler de trucs qui font des top sans parler d’atop ?

écrit par Philippe Humeau \\ tags: , , , , ,

avr 22

Quelques optimisations


A la suite d’Imagine US et des technical tracks ainsi que de plusieurs lectures récentes, je vous propose quelques informations ou techniques que j’ai trouvé intéressantes.

J’allais également oublier, les slides de ma conférence à Imagine sont disponibles ici et la vidéo a été mise en ligne ici.

Zend asynchronous

Lors des tech tracks d’Imagine, j’ai aussi pu voir le passionnant papier de Kevin de Zend. Le principe est de faire des requêtes qui seront servies de manière Asynchrone, ni plus ni moins qu’un Job manager en fait. actuellement je recommandais l’usage de Gearman pour la plupart de gestions de Queue mais quand on a pas besoin d’un fonctionnalité aussi avancé, Zend Asynchronous peut être une ressource à la fois simple et efficace.

Le papier de Kevin est disponible ici.

Mysql, ca ne se scale pas…

On commence de plus en plus a avoir des sites énormes en hébergement. Que ce soit du Ecommerce ou des médias, un gros site va très clairement faire chauffer la base de données. Le soucis avec Mysql, largement reporté déjà mais visible entre autre dans ce thread sur le forum Mysql, c’est que InnoDB et MyISAM se scale très très mal.

Quand on a un serveur qui a plus de 4 processeurs (plus de 4 cores pour être précis), Mysql ne sait pas en tirer partie. Pire, c’est même parfois un handicape. Alors en attendant la version 5.4 qui nous promet une refonte massive de l’architecture multi thread de Mysql, on va devoir faire avec. En plus, depuis le rachat de Sun par Oracle et la politique mené par ce dernier, doublé du mouvement NoSQL, il n’est pas certain qu’on voit un jour cette version.

Pire, avec Oracle derrière, le principe de limitation de Mysql pourrait même faire les affaires du titan qui aurait un intérêt évident à ne pas corriger ce point afin de vendre de l’Oracle.

Alors il reste le moyen de chainer les serveurs à 4 cores… Master/Master/Master etc. Ou de séparer les Read et Write et on fait un Master / Slave. Mais rien de bien brillant pour des sites qui consomment de plus en plus de ressources.

La conception, encore et toujours

Shawan mon amour

On a eu un problème assez original il y a quelques semaines à NBS System. Un client a eu des soucis délirant de charge de sa base de données. Tout le monde s’est posé la question, Moooo gento ou problème plus technique ?

Une première réponse au problème a été une découverte (faite par la web agency), d’un soucis atypique… Quand on fait un mailing pour une vente privée ou des clients existants, il est possible de les authentifier automatiquement quand ils suivent le lien. C’est très confortable pour eux et plusieurs systèmes existent qui facilitent la vie des intégrateurs.

Oui mais…

Quand on fait ca sur une très large clientèle, selon la façon de le faire, cela peut avoir des incidences très sensibles. L’exemple ici c’est que la base de données se retrouvait à décoder des centaines de Shawan (Hash SHA1) à la secondes au moment du pic d’ouverture des mailings. Résultat, à chaque clic, la DB devait décoder le SHA1 et vérifier son authenticité et … ca la cassait en deux.

Ce travail doublé du travail normal de DB la mettait totalement à genoux. Une analyse des logs, des slow queries, des paramètres vitaux de serveurs et une collaboration entre l’infogérant (nous) et la web agency a permis de mettre un nom sur le problème et de le corriger. Vicieux celui-ci.

Conception de Home

Bien concevoir sa home reste une clef du succès d’un site. La charge imposé par la Home sur l’ensemble de la charge serveur dépasse souvent les 40%, il est donc important de concevoir de manière optimale  cette page qui est le premier accueil qu’un client reçoit.

Pleinnnnn de produits

Eh oui ma bonne dame, plus y’en a, mieux c’est.

Faux. Lisez ce qu’en penses mes amis les pros comme Capitaine Commerce, François Ziserman ou Catherine Barba, assommer les clients sous 200 produits en homepage, ca n’apporte rien sinon un client perdu. Et plus on charge de produits, plus on fait travailler la base de données et les CPU pour interpréter le PHP et plus… ca rame.

Donc on a des clients perdus sur un site qui rame. Êtes vous bien persuadé que c’est  ce que vous voulez ???
(Press Y to continue if you are sure)

Dynamique, non mieux, random !

Bien tiens… J’ai une ligne de conduite précise, je sais ce que je vend et à qui. Aucun doute à ce sujet, j’ai profiler ma clientèle alors pour optimiser mes ventes, je charge mes produits en random…

Alors je veux bien que dans certains cas cela puisse avoir, à l’occasion, du sens mais clairement pas en home et pas tout le temps. Amazon, notre maitre à tous, ils envoient pas des produits en random à leurs clients. Ce qui a boosté leurs ventes et surtout le panier moyen de chaque acheteurs, c’est tout l’inverse, c’est l’envoie de produits ciblés.

Alors charger dynamiquement oui, dans certain cas pour s’adapter au client mais en random… ?

Car oui, le random et le dynamique sont des ennemis des caches, ces fameux caches (reverse proxy, celui de votre system de e-commerce, memcached, le Full Page  Cache et dans une moindre mesure celui des processeurs et des opcode cache de PHP) sont assez allergiques au hasard.

Et le statique ?

Vous y avez pensé ? Une landing statique bien faite, qui a la calculer chaque nuit en Cron, ca peut faire la différence. Sincèrement, afficher moins et mieux pour fournir à tout le monde une expérience utilisateur plus fluide, efficace et rapide, c’est une stratégie payante.

Plus votre site est véloce, plus et mieux il vend, c’est plus que démontré.

Inline URI

Alors celui-ci de tricks, il est soooo sexy.

Il faudrait tester en live la chose et étudier si c’est rentable mais le principe est marrant. En gros, dans votre CSS, plutot que de mettre la référence à une image externe, vous allez mettre en place une  chaine de caractère encodée en base64 :

url(data:image/gif;base64,R0lGODlhEAAQAMQAAORHHOVSKudfOulrSOp3WOyDZu6QdvCchPGolfO0o/XBs/fNwfjZ0frl3/zy7)

Ca donne un texte certe un peu chargé mais… Le Gzip est là pour nous aider. En gros le CSS va grossir, certes mais en contrepartie on peut le compresser en mod_gzip ou mod_deflate et finalement on n’a qu’une légère augmentation. Par contre, on économise autant de GET HTTP, ce qui n’est pas négligeable.

A vue de nez, je pense qu’il est valable de le faire pour les petites images, icones ou petits thumbnails. Il est possible aussi de faire un Sprite bien sûr, mais cette  technique alternative peut aussi avoir ses cotés sympas. Je dois avouer que c’est tout neuf pour moi alors je n’ai pas penssé à tous les points qui pourraient profiter des ces Data URIs.

(Beaucoup) plus d’infos sur cette technique ici : http://css-tricks.com/data-uris/

écrit par Philippe Humeau \\ tags: , , , , ,

jan 23

Après plusieurs mois de travail, on peut commencer à en parler car Nitrogento va enfin voir le jour !

Depuis trois ans, NBS System s’est spécialisé dans l’hébergement de Magento, WordPress et Drupal, cela m’a donné l’occasion de faire de nombreuses conférences, pendant les Bargento notamment, sur la performance et l’optimisation. Ce blog en est d’ailleurs le reflet, j’y ai souvent distillé des conseils sur ces sujets.

Mais nous avons voulu aller plus loin en mettant sur le marché une extension qui boost les performances de Magento. Les points clefs sont connus mais cela nécessitait beaucoup de travail. Voici donc un avant goût de Nitrogento, de son contenu et de ses performances.

Voici les quelques questions qui se posent probablement à la lecture de ces lignes :

Qui

J’ai commandité (par NBS System) la création d’une extension Magento auprès de L’academy et de l’Agence DnD.

Les deux maîtres codeurs derrière ce petit bijou sont essentiellement Matthieu Bouchot (Academy) et Aymeric Aitamer (Agence DnD). J’ai conçu le cahier des charges et demandé les fonctionnalités, la réalisation des caches (FPC / Bloc / Custom Bloc) a été faite par Matthieu, les CDN /Minify/Sprite et l’admin en Back office par Aymeric.

Ce sont des experts dans le domaine Magento et de vieux complices en matière de performances, j’ai notamment un peu co-écrit avec Aymeric sur ce blog et on aime beaucoup faire la course à l’optimisation tous les deux.

Quand

Tout est quasi finit en terme de développement, nous en sommes à la phase de beta test depuis quelques jours. Une fois celle-ci terminée on attaquera la phase de benchmark et la mise sur le marché se fera aux alentours de mi-février, tout début Mars au plus tard si on tombait sur un pépin.

Quand au « Quand cela a commencé » : depuis quelques mois, environ 6.

Sur le Web of course :)

Julien et Christophe (de DnD, aidé par notre illustrateur Flash de talent, Yoann Dondicol) m’ont monter le site Magento qui sera en ligne prochainement pour vendre l’extension sur www.nitrogento.com. (ouverture mi février normalement). Je pense qu’on le mettra peut être aussi dans Magento Connect. Les partenaires NBS System pourront aussi l’acheter directement auprès de leur interlocuteur habituel.

Pourquoi

Parce que Magento est flexible et puissant mais il est également assez lent et consommateur de ressources. Parce qu’un magasin rapide vend plus et offre une meilleure expérience à l’utilisateur.

Les chiffres et statistiques sont là :

  • Akamai & Forrester : 5 secondes de temps de chargement : 20% des personnes partent
  • Shopzilla a augmenté ses revenus de ~10% en chargeant en 2s au lieu de 7s
  • Yahoo perd 5 à 9% de trafic en chargent avec 400 ms de plus
  • Google : +500 ms, -20% trafic
  • Amazon : +100 ms, -1% de ventes
  • Les utilisateurs interrogés disent que 2 secondes c’est acceptable, 4s c’est trop
  • 52% des visiteurs considère que la vitesse de chargement d’un site est un critère essentiel pour revenir
  • En 2010, 75% des visiteurs ne reviennent pas si le site est lent (contre 64% in 2006) }
  • La vitesse influe directement sur votre SEO ET votre SEM
  • Google a divisé le web en deux clans (voir webmaster tools->labo->performances) : les sites rapides, qui chargent en moins de 1,5 secondes et les lents, qui chargent en plus de 1,5 secondes…

etc, etc, etc… Le web fourmille d’étude en ce sens, la vitesse joue sur tout, y compris massivement sur le taux de transformation, bien que là je n’ai pas retrouvé l’étude qui m’intéressait dans l’immédiat.

Quoi

Eh oui, ca reste le plus important en fait, ça fait quoi Nitrogento ?

Vous l’aurez voulu, on est partit :

  1. Full Page Cache pour la version CE et plus efficace (et moins buggé) que celui de la EE
  2. Bloc caching (y compris si les développeurs ont oublié de l’instancier)
  3. Custom Bloc Caching (cache des blocs non natifs à Magento)
  4. Auto Sprite : génération automatique du sprite lié au template pour diminuer le nombre de requêtes
  5. Déploiement automatique en CDN (pour paralléliser les downloads des ressources statiques)
  6. Concaténation des JS et CSS en un seul fichier
  7. Minify et compression de : HTML / JS / CSS
  8. Paramétrage depuis le backoffice des Expire headers, Etags et compression Gzip

Voila, j’ai oublié une ou deux choses involontairement, une ou deux de plus qui sont encore en gestation pour notre roadmap de la version 1.1.

Au final on atteint quoi ?

Pour le moment, ce sont des statistiques temporaires, le temps de finaliser les benchmarks réels :

  • -0,5 seconde en moyenne sur le temps de chargement des pages
  • ~8 fois moins de charge serveur sur la home (FPC)
  • ~2 fois moins de charge serveur sur les pages internes (bloc cache+custom bloc cache)
  • ~2 fois moins de requêtes HTTP (Sprite)
  • chargement des ressources statiques 2 à 3 fois plus rapides (CDN)
  • grade A/A sur Gtmetrix.com (98 en Yslow et 96 en Pagespeed) au lieu de C/C (78% Yslow / 76% pagespeed)
  • avec un serveur de base, on arrive à 1,9 seconde au lieu de 3,1 pour la home
  • avec un serveur optimisé pour Magento, on arrive sous la barre des 0,7 seconde pour la home
  • économie de ~15% de bande passage (sprite + minify + gzip)
  • pour un visiteur qui revient sur une page ou repasse sur la home, on atteint un temps de chargement qui en général est sous la barre des 0,4 secondes et moins de 20 Ko

Coté Serveur :

  • En période « normale », ça accélère le chargement
  • En période de pic (soldes, mailings, ventes privées) ça diminue considérablement la charge des serveurs et la bande passante utilisée

Coté Navigateur :

  • Ça accélère le rapatriement des données statiques (Minify + Gzip + CDN)
  • Ça optimise le cache du navigateur (ETags+Expire headers)
  • Ça diminue le temps d’affichage des pages

On peut vérifier ?

Oui, le Nitrogento store sera équipé aussi d’un demostore et d’un « Nitrostore » (un démostore sous Nitrogento) , sur la même machine, ce qui permettra à tout le monde de voir la performance, de tester et de vérifier avec GTmetrix, Pagespeed et /ou Yslow.

Vous pouvez aussi vous porter volontaire pour la phase de Beta, si vous êtes retenu, l’extension sera alors gratuite pour votre site une fois qu’elle sera commercialisée.

Voici déjà un shoot, pris pendant l’intégration :

L’image est un peu petite, mais la note du Yslow est bien à 98%…

Les limites

Pour être honnête, il faut aussi parler de  ce que le produit ne fait pas ou ne peut pas faire.

Par exemple, quand on est authentifié ou qu’on a un bloc contenant des informations de session, de panier ou d’authentification, le FPC (Full Page Cache) se désactive, ce qui est normal et indispensable.

Ensuite, la mise en cache des custom blocs nécessite d’appeler un helper pour être prise en compte dans le back office et donc visible pour activation / désactivation. Rien de compliquer à faire mais ce n’était pas automatisable.

Pour le moment seul le CDN accessible en CNAME par FTP est géré. Dans la v1.1, un support natif du CDN de NBS, de celui d’Akamaï et de MaxCDN devrait être intégré.

Enfin, pour le moment, nous avons pris le partit de le mettre en Anglais car la très grande majorité du marché est anglophone et que les intégrateurs Français parlent presque tous anglais.

Combien

500 $ par an pour un serveur frontal.

Si vous avez plusieurs serveurs frontaux, il faut avoir l’extension sur chacun d’entres eux mais les suivants seront facturés 100$ par an. Ce tarif intègre également les mises à jour et les évolutions.

(Les clients et partenaires NBS System profiterons d’une tarifications spéciale)

écrit par Philippe Humeau \\ tags: , , , , ,