Pourquoi un site de E-commerce se doit de charger en moins d’1,5 seconde ?

Tout simplement parce que Google possède plus de 90% de part de marché et que ses dirigeants ont décidé d’inclure la vitesse de chargement parmi plus de 200 facteurs pris en compte dans le référencement naturel.

Certes, ce nouveau facteur ne sera pas plus important que la pertinence du contenu, mais il va petit à petit monter en puissance.

Cette transformation est logique, nos environnements de travail et personnels sont de plus en plus connectés, toutes les générations travaillent maintenant sur Internet, pourquoi devrions nous attendre, dans une société où l’instantané à pris le pouvoir ?

Depuis que l’homme est équipé de pouces opposables, d’une connexion ADSL et d’une culture Internet, il est impatient.

Pourquoi cette limite d’1,5 seconde ?

Quand votre site charge en moins de 1,5 seconde, il est plus rapide que 90% des autres sites actuellement connus de Google. Il est donc difficile à ce jour d’infliger une lourde pénalité à ceux chargeant en plus d’une seconde et demi.

Par contre, si vos pages charge en moins d’1,5 seconde, il peut vous favoriser, de la même façon que si votre site est très propre en terme de HTML ou bien conçu en terme de mots clefs. A l’avenir, ce facteur va se renforcer puisque les sites vont en tenir compte et charger plus vite.

1,5 seconde, c’est le temps que Google a choisi comme référence.

Dans les graphiques mis à disposition par Google, la délimitation est claire :

À moins d’1,5 seconde, vous êtes dans la zone verte, vous êtes rapide. Au-dessus d’1,5 seconde, vous êtes dans l’équipe rouge, vous êtes lent. Nous vous y trompez pas, aucun mot, aucun chiffre chez Google n’est utilisé par hasard. Le temps d’1,5 seconde découle de plusieurs études précises, parmi lesquelles nous pouvons déjà citer celle-ci ou celle-ci.

Et quand le mot « Lent » est choisi par Google, il a un sens fort.

Que perd-on précisément ?

De très nombreuses autres  études ont été menées et elles sont toutes formelles, être lent, c’est vendre moins, décourager l’utilisateur, freiner son business.

Les études donnent parfois des résultats différents. Certaines annoncent 2,8% de perte de chiffre d’affaire pour 1 seconde de plus de chargement, -4,3% de CA pour 2 secondes.

Amazon avait déjà fait le constat auparavant : 0,1s de plus de temps de chargement en plus leur coutait 1% de chiffre d’affaire.

Eric Schuman (Microsoft) et Jake Brutlag (Google), ont réalisé une étude et fait une conférence à ce sujet également. Il en ressort le même principe de fond mais certaines subtilités supplémentaires apparaissent. Entre une page qui charge en 50 ms et un autre en 2 secondes, le revenu par clic baisse de 4,3%, la satisfaction baisse de 3,8% et le temps avant le clic suivant augmente de 3,1s.

Les dirigeants de Google ont d’ailleurs la volonté   exprimée de faire passer l’internaute de la page   de recherche au site de destination de la manière  la plus fluide possible. Le chargement, le  changement de monde, doit être le plus  imperceptible possible, « comme si l’on  tournait la page d’un livre ».

La publicité en ligne (SEM) et notamment les adwords sont également moins efficaces lorsque le site est lent, comme vous pouvez le lire dans l’aide de Google ici.

Phil Dixon de Shopzilla a pour sa part constaté, en passant le temps de chargement de son site de 7s à 2s :

• 25% de pages vues en plus
• 7 à 12% de ventes en plus

A l’inverse, quand le temps augmente, l’image de marque se dégrade elle aussi car les utilisateurs se plaignent et parlent entre eux, d’autant plus depuis l’avènement des réseaux sociaux.

Pourquoi ces pertes ?

Le cerveau humain a plusieurs « rythmes ».

• De un à cinq dixième(s) seconde : C’est la limite à laquelle nous estimons inconsciemment avoir une action immédiate sur ce que l’on manipule. Word, MacOS ou Windows ou encore l’interface d’un téléphone doivent réagir dans cette zone pour être apprécié. Le cerveau interprète, commande, reçoit, comme si l’outil utilisé était un prolongement du corps qu’il contrôle directement.

• De cinq dixièmes à 1 seconde : La perception se modifie, nous n’avons plus l’impression de contrôler « directement ». Le cerveau assimile l’information et n’a plus l’illusion de pouvoir contrôler l’interface comme il contrôlerait un membre du corps.

• De 1 à 5 secondes : C’est le temps habituel de chargement des sites. L’internaute l’accepte en générale relativement bien. Si un chargement doit durer plus de 5 secondes, il est intéressant d’occuper l’espace visuel de l’internaute pour garder son attention (une petite hélice, une barre de chargement, un pourcentage). Garder l’attention plus de 10 secondes sans occuper un des sens est illusoire.

• À partir de 10 secondes : Le cerveau n’attend plus la réponse et vagabonde. Le site visité n’a plus l’exclusivité de l’attention de l’internaute. Celui-ci se demande s’il ne va pas aller sur un autre site concurrent, s’il a payé ses impôts, si le webmaster lui envoie les pages par la poste ou à dos de hamster, bref, la vente ne se fera probablement pas.

L’âge de l’internaute et sa culture internet changent la donne.

Les adolescents qui n’ont jamais réellement connus l’attente avant d’avoir un résultat, tout au moins sur l’informatique. Le temps à laquelle la réponse est reçue, après que la demande ait été envoyé, est d’une importance colossale mais il doit être d’autant plus réduit que le potentiel acheteur est jeune.

Une grand mère attendra 20 secondes la page Web du site avec les gentils dauphins pour réserver ses vacances. Hugo, du haut de ses douze ans, au delà de la deuxième seconde, il se demande si les pages du site lui sont acheminé par pigeons voyageurs ou à dos de hamster.

Comment mesurer le temps de chargement ?

Vous pouvez mesurer la rapidité de chargement de votre site avec ces deux extensions Firefox :

• Google Pagespeed (dont le mode d’emploi se trouve ici)
• Yahoo Yslow

Ou avec ce site

Il est également possible de suivre l’évolution de la vitesse de chargement de son site dans les outils Google appelé « Webmaster tools ». Si vous n’avez pas de compte, créez en un et si vous en possédez déjà un, allez dans l’onglet Labo puis dans « Performances du site ».

Pourquoi les sites ne chargent pas plus vite ?

Avec le matériel toujours plus puissant et les connexions toujours plus rapides, la question se pose en effet.

Les sites qui ont vus le jour il y a dix ou quinze ans chargeraient très rapidement aujourd’hui, bien plus rapidement qu’à l’époque. Les connexions vont plus vite, nous sommes passés à l’ADSL du coté de clients et aux connexions très haut débit du côté des serveurs.

Alors avec de tels progrès, pourquoi un site prend-t-il toujours 4 à 20 secondes pour charger ?

Les machines ont évolué des deux coté également. Les ordinateurs sont plus puissants et les serveurs ont vus leurs capacités de traitement multiplié par plus de 1000. Par contre, la vitesse de la lumière n’a pas progressé. Elle met toujours plusieurs dizaines de milliseconde à traverser l’atlantique, de même, les connexions internet ont aussi une limite de progrès, tout comme les protocoles qui soutiennent internet. Tous ces facteurs font que l’ensemble a progressé de manière non homogène.

Un serveur 1000 fois plus rapide de nos jours est également 100 fois plus sollicité qu’avant. 3000 visites par jours il y a 15 ans, c’était un “grand site”, aujourd’hui, c’est un trafic modeste.

Composition du temps de chargement d’une page

Le temps de chargement d’une page est composé de plusieurs facteurs :

• L’initialisation de la connexion et la résolution du nom de domaine
• Le temps d’interprétation des scripts php / asp
• Le temps de chargement des éléments par le réseau
• La recherche des informations en bases de données
• Le formatage d’une sortie en HTML
• Le délai d’interprétation et d’affichage du navigateur

C’est un résumé puisque le temps est en fait découpé en plus de sous sections mais nous entrerions dans trop de détails.

Il y a quelques années, j’avais proposé le schéma suivant, résumé lui aussi :

Les performances des connexions et du matériel ont donc évolué mais au final, les programmes aussi. Les sites web modernes n’ont plus rien à voir avec ceux d’il y a quinze ans et ils ont apportés une souplesse sans égale au E-commerçant.

Gestion de catalogue avancée, page dynamique et agréable à regarder, outils d’administration poussés, les sites modernes sont définitivement plus efficaces. Cette efficacité a été apportée, notamment, par des langages de programmation plus évolués dont PHP et par l’usage de base de données, dont Mysql.

De plus les langages ont évolué vers de l’objet ce qui les a aidé à devenir plus flexibles et efficaces mais en contrepartie, toutes ces améliorations ont un coût en terme de performances.

Ces complexités et améliorations fonctionnelles additionnées nécessitent donc plus de puissance. Les graphismes et photos plus lourds ont, eux, demandé plus de vélocité à nos connexions.

Il faut également prendre en compte que la qualité du code source généré est inégale. Deux sociétés peuvent réaliser le même site et l’un sera optimisé tandis que l’autre sera lent, c’est une question de capacité technique et d’expérience. De la même façon tous les sites ne sont pas à égalité devant le temps de chargement, de part leur conception ou même leur usage.

Sur un site comme Amazon, 90% du surf se fait depuis  le moteur de recherche et il se doit d’être rapide sur ce point. Sur un autre site ce sera la “vitrine” virtuelle et son agencement qui déclencheront les ventes et ces deux approchent n’ont pas le même coût en terme de temps de chargement.

La technologie également joue énormément et enfin la capacité de l’infogérant à optimiser votre infrastructure et son usage.

La vitesse n’est pas tout

La disponibilité du site et la réactivité de l’infogérant en cas de soucis sont également des facteurs majeurs de succès.

Bien que l’ingénierie informatique et la programmation Web ne soient plus des secrets maîtrisés par un très petit nombre, les sites sont devenus de plus en plus complexes et les accidents peuvent arriver.

Sur un serveur, un disque dur, une barrette mémoire ou un autre élément technique peut céder. Du côté du site web, un élément logiciel peu avoir un défaut ou engendrer une erreur. Dans les deux cas, un internaute peut accepter un court délai d’indisponibilité mais ceci ne doit pas se prolonger.

Une interruption de plusieurs heures pendant les soldes peut être problématique, les ventes de fin d’année ou une animation commerciale. La perte de chiffre d’affaire et d’image de marque peut devenir très sensible.

Un infogérant spécialisé dans le E-commerce et une Web Agency sont des alliés précieux dans l’exploitation d’un site commerçant.

En conclusion

La rapidité de chargement joue donc 3 fois :

• sur l’expérience utilisateur
• sur le référencement naturel
• sur l’efficacité de la SEM (mots clefs sponsorisé dans les moteurs de recherches)
• sur le chiffre d’affaire généré

Il est donc clair que ce facteur est critique pour un site de E-commerce.

Philippe Humeau, NBS System, hébergement et sécurité du E-commerce.

écrit par Philippe Humeau \\ tags: 1, 5 seconde, optimisation, référencement, temps de chargement, temps de réponse

La dernière version de Magento est sortie cette nuit et avec elle arrive l’option tant attendue : le Flat Catalog!

Celle-ci a été annoncée par Varien comme salvatrice pour les performances de notre outil e-commerce préféré (le site annonce un bénéfice de 40% sur le temps de chargement des pages en front office et sur l’utilisation de la mémoire).

Concrètement, que se cache-t-il vraiment derrière cette option “magique” et quel impact aura-t-elle sur les prochains projets construits sur la base de cette version?

Avant toute chose, rappelons que Magento repose actuellement sur un modèle de données de type “EAV” (Entity-Attribute-Value). Ce qu’il faut comprendre c’est qu’un objet “Produit” dans Magento n’est pas stocké dans une seule table mais éclaté dans un ensemble de tables en fonction des attributs de notre produit. Cette complexification du modèle de données se justifie en grande partie par la souplesse que propose Magento dans le paramétrage de nouvelles caractéristiques pour un produit.

Mais cette souplesse a donc un coût puisqu’il multiplie de manière importante le nombre de requêtes effectués en base pour un seul produit. On touche donc très vite aux limites de ce modèle dès lors qu’on travaille avec un catalogue important (plus d’une dizaine de millier de références). Varien a donc annoncé en début d’année qu’ils proposeraient une simplification de ce modèle sous forme d’une option librement activable depuis le back office pour permettre de basculer vers un modèle de données “à plat”.

En regardant de plus près, cette option est un peu plus subtile que ce à quoi on pouvait s’attendre: une fois le mode ‘flat catalog’ activé dans l’administration, on se retrouve finalement avec deux catalogues: un pour le backoffice, et un pour le front:

• celui du backoffice reste le catalogue EAV tel qu’il existe dans la 1.2
• le front utilise des nouvelles tables catalog_category_flat et catalog_product_flat
• il y a une synchronisation type maître-esclave entre le catalogue backoffice et celui du front

Finalement, le “flat catalog” du front est en réalité une sorte de table de cache pour le vrai catalogue qui reste en EAV.

Les avantages de ce fonctionnement:

• la migration est bien plus simple puisqu’en réalité le format de la base n’a pas vraiment changé (les tables _flat sont générées à la demande depuis le backoffice)
• on peut imaginer facilement avoir une base de données front avec les tables _flat côté frontoffice, séparées physiquement de la base de backoffice, avec le moteur Federated de MySQL qui permet de présenter plusieurs bases de données comme en étant une seule aux applications. De ce fait, la charge sur le front n’impacte pas le back et inversement

Les inconvénients:

• avec des volumétries très élevées, (certains) écrans du backoffice vont être très lents puisqu’ils continueront à utiliser le système EAV
• les imports devront continuer à se faire dans les tables EAV, d’où une lenteur au moment de l’import (à nuancer: si les données importées ne sont pas destinées à être utilisées dans le backoffice, il est peut être possible de les importer directement dans les tables _flat du front)

Nos premiers tests sur la base de ce nouveau modèle et d’un catalogue de plus d’un million de produits devraient désormais nous fixer assez rapidement sur la pertinence de cette fonctionnalité…

A suivre donc!

écrit par Frederic de Gombert \\ tags: eav, flat-catalog, modele de données, optimisation

Durant nos différents échanges à Bargento, j’ai réévoqué la piste d’un “compilateur de site”.

C’est un projet qui peut prendre de multiples formes, du préloading d’un site pour rendre le cache du reverse proxy efficace immédiatemment ou encore appeler tous les liens avec une spider et sortir un site “Semi statique” à partir du site Dynamique originel.

Plusieurs personnes ont trouvé l’idée intéressantes, certains ont même déjà de l’expérience dans le domaine, un contributeur Drupal, l’admin du vendée Glob (de AFG je crois ?) un monsieur de chez Smile. Je n’ai pas retenu tous les noms ou toutes les bonnes volontées mais je suis prêt à créer un groupe de travail sur ce point avec les volontaires.

L’idée est la suivante :
Les langages interprétés comme PHP ne sont pas très optimisés pour les processeurs et leurs systèmes de cache.
Ce point peut se compenser en imaginant un site Web très dynamique (Zend/Magento par exemple) comme un “code source” de l’époque C++. Le but c’est que la version dynamique reste bien LA référence mais que pour des raisons de performances, ont “pré calcul”, on compile, une partie des pages du site. Du coup, le serveur Web fournit des pages HTML et non plus du PHP qui génère du HTML. Le rapport de puissance peut aller de 1 à 10 sans problème, comprenez qu’un même serveur Web frontal pourrait servir 10000 connexions simultanées au lieu de 1000.

Outre le gain de performances et l’économie de puissance, on constate également que le surfer reçoit une information quasi immédiatemment puisque le serveur n’a plus à générer du HTML puis à l’acheminer mais juste à l’acheminer.

Les limites :
En premier lieu, ceci ne permet d’optimiser que les performances des serveurs Web. En effet, ce qui est allégé, c’est le temps de rendu des pages et uniquement ce point. Rechercher un produit dans une base de données pas optimisée n’ira pas plus vite qu’avant. En poussant le vice, on pourrait précalculer les réponses aux 3 recherches les plus fréquentes dans le moteur selon une espèce de règle des 80/20.

Ensuite, il ne faut pas oublier que le site doit être généré à une fréquence suffisamment élevée pour que les changements importants soient visibles rapidement. Il faut également le “compiler” sur un autre serveur que celui de production car sinon on va entacher ses performances lors de la génération des pages semi-statiques. En fait il faudrait même pouvoir recompiler le site à la demande, sur tout ou partie (les prix uniquement, les articles et les prix, juste une page, comme avec un Makefile en fait)

Les obstacles :
La complexité du projet réside dans le fait que de nombreux élements nécessitent l’affichage d’informations dynamiques. Le caddie d’une personne, ses “choix pour plus tard”, les comparateurs de prix ou de produits etc… De même, interroger la base de données en faisant une recherche sur un site répondra forcément un contenu différent selon la recherche (sinon on risque de décevoir un peu le visiteur).

On ne peut pas non plus trop déporter le processus dynamique sur le poste client, cela peut dans certains cas engendrer des risques de sécurité. La business logic de traitement des commandes et ce genre de choses ne peut pas résider “customer side” dans la machine virtuelle javascript du browser sinon elle est aisée à corrompre.

Mais c’est un peu comme dans la pub pour une certaine carte de crédit :
“Il a ce que vous ne pouvez pas rendre statique, pour tout le reste, précompiler votre site !”

Alors ? Faisable ou pas ? Utile ou juste une idée en l’air ? J’en appel aux volontaires pour qu’on voit si un petit groupe de travail souhaite se pencher efficacement dessus.

écrit par Philippe Humeau \\ tags: compilation, dynamique, optimisation, statique

Comme nous allons parler essentiellement de performances et d’optimisation, il faut que nous convenions d’un vocabulaire commun et d’unité de mesure commune sinon cela va compliquer le dialogue et perturber les comparaisons. Je ne crois pas qu’il y ait réellement de normes en vigueur alors nous avons choisis, à plusieurs, d’utiliser le référentiel suivant :

Sessions Actives (SA) : nombre de personnes utilisant activement des ressources du serveur. Elles sont connectées et ont appuyées très récemment sur un bouton/lien/image, ce qui impose au serveur un traitement pour lui répondre, ou bien elles viennent de se connecter sur le site et attendent en retour la homepage. Lire la suite »

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