Blog Ecommerce, ergonomie, open source

Ca y est, c’est officiel. Dans un billet de vendredi (Using site speed in web search ranking), Google annonce que désormais la vitesse de chargement des pages devient un élément du ranking. Voici une traduction rapide  d’un bout de l’article :

Rendre les sites est important – pas simplement pour leurs propriétaires, mais aussi pour les utilisateurs. La rapidité rend les utilisateurs heureux et nous avons constaté dans nos études internes que lorsqu’un site répond lentement les visiteurs y passent moins de temps. Rendre un site rapide n’augmente pas seulement l’expérience utilisateur; de ressentes données montrent que cela réduit également les coûts. Comme nous, nos utilisateurs placent beaucoup de valeur dans la vitesse – c’est pourquoi nous avons décidé de prendre la vitesse en compte dans le ranking.

On apprend également dans cet article que cela fait des mois que la fonctionnalité est en test, et que cela n’est actif pour l’instant que pour les recherches en anglais sur google.com. On s’en doutait un peu, Matt Cuts avait plus ou moins lâché l’info il y a quelques mois. D’autre part l’apparition dans Google Webmasters Tools des performances du site laissait supposer qu’il y avait quelque chose dans l’air (dans l’onglet labo).

En ce qui me concerne, c’est une évolution naturelle du moteur de recherche. Il est leader, et a tout intérêt à placer en tête les sites les plus rapides, à contenu égal entendons nous bien.

Si effectivement je considère que l’expérience utilisateur est un point crucial, cette annonce laisse pas mal de questions en suspend :

• A quel point cela va jouer sur le ranking ?
• Quelles sont les valeurs pénalisantes ?
• Quand on parle de réduction des coûts, j’ai l’impression qu’on se f@% de ma g£%le, c’est normal ?

Et oui, concernant la question des coûts, c’est probablement vrai quand on a un paquet de serveurs. Quand on a un hébergement mutualisé, c’est autre chose. C’est plutôt l’inverse, puisque passer d’un mutualisé sur un dédié induit un paquet de frais supplémentaires. Il n’y a que chez les très gros acteurs du ecommerce qu’on dispose des moyens pour faire des économies la dessus.

Alors que va-t-il se passer ? Deux cas de figure : tout le monde s’en fout ou il va y avoir du ménage. Il me semble évident que c’est la 2° option qui va gagner. Même si cette nouvelle donne ne change pas grand chose pour la plupart des sites. A mon avis, seuls seront pénalisés les boulets qui mettent des plombes avant de se charger.

Déjà, les pages html qui mettent 20 secondes à charger, il va falloir les revoir. Ensuite, fini les chargements de 50 .JS et 38 .CSS (ne riez pas, ça existe). Ça ne sera pas forcément un mal.

Reste que pour ceux qui font du ref nat un pivot de leur stratégie il va falloir se pencher sur la technique. Et même si le ranking ne sera pas chamboulé pour tout le monde. En tout cas pas tout de suite. Il va y avoir une course chez certains acteurs, c’est évident.

Par contre, si je regarde les graphs de google webmaster tools, j’ai peur. Le graph est séparé en 2 zones. Au dessus d’une seconde sur mon exemple, on est considéré comme lent. J’espère que c’est une blague d’un farceur de chez google.

Le conseil du jour : si votre site est un boulet, tremblez. Surtout si vous captez 50% de votre trafic via google. Sinon, commencez à penser à ce qu’il est possible de faire pour optimiser un poil tout ça, ça peut se faire dans le temps et sans douleurs. Il n’y a pas encore le feu au lac.

Sur internet le modèle qui consiste à développer son activité par le moyen « traditionnel » des abonnements ou de la diffusion de bannières publicitaires reste encore parfois fort décevant.

Dans ce contexte de crise il y a un phénomène qui semble clairement tirer son épingle du jeu : le micro paiement, lui même soutenu par des offres comme les produits virtuels et les jeux gratuits.  Il semble même que c’est bien la crise qui a accéléré cette tendance.

De plus en plus de développeurs et d’éditeurs vendent des biens virtuels embarqués dans des applications en ligne, des univers virtuels ou des jeux.

Deux catégories se distinguent :

La monnaie virtuelle :
elle peut être échangée contre des produits ou biens, l’évolution d’un abonnement, d’une application, d’un type de service. Ce sont par exemple des jetons, des joyaux, de l’or ou des points.

L’objet virtuel ou bien virtuel :
il propose la possibilité d’améliorer le niveau ou les performances dans un jeu, de faire des présents, de faire valoir sa présence ou d’améliorer son espace virtuel.

Photo de Tom Purves

A cela se greffe de nouvelles possibilités de suivi des scores de chacun des joueurs, par l’utilisation d’outils ou d’APIs qui gèrent aussi le lien avec chaque profil dans les réseaux sociaux. Ainsi, les amis d’un gamer constatent son évolution et ses scores lesquels s’affichent sur son mur Facebook.

Quelles motivations poussent des internautes à dépenser de l’argent bien réel pour des biens virtuels ?

Dans un article publié dans le Wall Street Journal (rubrique tech) en février 2009, Jeremy Liew indique trois raisons principales qui expliquent  les motivations des consommateurs de biens virtuels :

-Ils veulent plus qu’ils n’ont déjà : cela concerne essentiellement celles et ceux qui s’adonnent aux jeux en ligne et qui souhaitent se donner plus de « force », « d’habilité », bref d’opportunités pour relever et remporter un défi, gagner une partie, remporter une victoire.

-Ils veulent construire un réseau de relations : chacun sait qu’à l’image du monde réel, nous aimons nous faire de nouveaux amis et être appréciés pour nous mêmes, et c’est encore le cas dans des mondes virtuels ou au sein des réseaux sociaux, des communautés en ligne ou des jeux. Dans ce cas les biens virtuels vont faciliter la mise en relation avec d’autres à l’image des cadeaux proposés par la plateforme Facebook.

-Ils veulent construire leur identité : Enrichir sa propre identité personnelle en ligne ne peut se concrétiser que par l’ajout des biens virtuels qui sont en vente au sein d’un monde virtuel ou d’une communauté. Ces biens virtuels sont aussi bien des artefacts, des univers ou des décors que des habits. Pour aller plus loin avec l’identité, pensez à lire cet article indiquant qu’un profil Facebook reflète la réalité et non une identité idéalisée, référencé sous ce billet.

Ainsi, les biens virtuels font partie intégrante de notre expérience en ligne.

Les utilisateurs consommeront de plus en plus de biens virtuels. cela modifiera leur mode de consommation en ligne avec un usage grandissant du micro paiement.

D’après une étude Forrester (Novembre 2009) une majorité des consommateurs exprime le souhait de pouvoir choisir entre un abonnement et un accès temporaire via micro paiement quand ils souhaitent lire un article précis, cela d’autant plus quand ils surfent depuis leur téléphone.

Alors qu’est ce donc que le micro paiement et quelles sont les méthodes de paiement alternatives ?

Les méthodes alternatives de paiement regroupent tous le modes de paiement excepté celui opéré par carte de crédit :

Beaucoup d’entre vous sont surement coutumier de quelques unes qui suivent :

• PayPal:
Grand don d’ubiquité pour le moins, et celui qui nécessite le moins d’être expliqué.

• Mobile:
Paiement possible par l’utilisation du téléphone portable. Le montant est prélevé directement sur l’abonnement mobile parfois en indiquant son numéro de téléphone.

• Cartes pré payées :
Même concept que les cartes ou chèques cadeau ou les cartes de téléphone que l’on trouve dans les librairies ou même les centres commerciaux.

• UGVP (Unified Global Virtual Payment) :
aux EU et en Asie et qui est un moyen global de micro paiement dans les mondes virtuels avec par exemple un acteur comme CherryCredits.

• Les bandeaux publicitaires :
Un moyen qui demande une participation de l’acheteur sous la forme d’un ou plusieurs clics sur un ou plusieurs bandeaux publicitaires. Pour les jeux notamment le passage d’une annonce commerciale est imposé avant le début d’une partie.

Et aussi les agrégateurs de paiements de type clickandbuy, PaybyCash, …

Les chiffres annoncés donnent le tournis et présage d’une tendance à la hausse pour les années qui viennent.
Pensez donc que suite à la catastrophe d’Haïti, la Croix Rouge a reçu 22 M$ de dons…par SMS. Un niveau jamais atteint à ce jour puisque les appels aux dons via SMS produisaient jusqu’alors un total qui ne dépassait jamais 2 M$.

Récemment, Farmville l’un des social game de Facebook, annonçait 80 millions d’utilisateurs mensuels mais… ! Alors qu’un jeu comme Playfish sur Facebook connaît un excellent niveau de transactions grace au micro paiement, Farmville ne proposait que le paiement par carte de crédits et générait un revenu bien en deça de son potentiel. Fin février 2010 Facebook a annoncé le déployement à grande échelle d’un système de paiement plus souple : le micro paiement par achat de crédits.

Liens :

Le jeu Farmville plus populaire que Twitter avec 69 millions d’utilisateurs : ici

Les profils Facebook reflètent votre personnalité, pas son idéalisation : ici

Maintenant que les fêtes sont finies, et que vos foies sont à nouveau au repos, il est temps de se remettre au boulot.D’autant qu’aujourd’hui c’est les soldes ! Les serveurs vont chauffer, je me doute qu’il va y avoir des crises de nerf .

On commence léger avec la suite  du billet ou je vous parlais de firebug et pagespeed. Etant donné que je suis votre seul et unique gourou, et que bien évidemment vous faîtes absolument tout ce que je dit, vous avez déjà optimisé au possible votre site.

Alors aujourd’hui, penchons nous un peu sur les outils pour webmasters de notre ami Google, afin de vérifier les résultats, et plus particulièrement sur 2 options :

• Diagnostic>Statistiques sur l’exploration
• Labos>Performances du site.

Les données de ‘performances du site’ sont obtenues directement auprès des internautes ayant installé la barre d’outils Google et activé la fonctionnalité PageRank . Donc c’est une moyenne qui est présentée sur les graphs. A leur côté vous trouverez maxi, mini et moyenne. Attention, cette méthode ne sert qu’à vous les pauvres. Les riches eux n’ont pas besoin de google, ils utilisent d’autres méthodes plus rapides et plus fiables.

Attention, cet article risque d’être totalement imbitable pour la majorité de notre lectorat. Que la direction générale de cet auguste blog me pardonne.

Ko téléchargés

La première donnée intéressante concerne le nombre de kilos octets téléchargés par jour.

Franchement, j’ignore totalement comment est calculé cette donnée. Et cela n’a aucune importance puisque l’on se basera plutot sur des ratios que sur des valeurs absolues calculées finement.

Tout ce que je peut dire, c’est que limiter les téléchargements a 2 impacts principaux. Le premier est l’impression de fluidité lors du chargement d’une page. Le second est que la bande passante, si vous la payez, coûte cher. Sur un mutualisé cela à également de l’importance, puisque qu’en cas de saturation de cette même bande passante, vous fournirez plus rapidement certains contenus, la BP n’est pas extensible à l’infini.

Devinez quand la compression et le caching ont été activés. Non, pas en Aout.

Activer la compression

Voici le premier moyen simple de limiter le poids des données transférées : la compression. Même si vous confondez la gauche de la droite, vous connaissez surement winzip qui permet de diminuer fortement la taille des fichiers. Ici c’est pareil. Le gain est sensible particulièrement sur les fichiers de type texte (html, js, css, xml).

Sur un serveur Apache, il est assez simple d’activer la compression, sans toucher au code (genre avec un obscur ob_start(‘ob_gzhandler’) à claquer sur toutes les pages. Un petit tour dans le .htaccess en racine et hop, d’un coup les gros on active le mode deflate pour l’ensemble du site et pour les .html, .ico, .js, .css, .xml (ici un exemple avec deflate) :

AddOutputFilterByType DEFLATE text/ico text/html text/plain text/xml text/css application/javascript application/x-javascript application/x-httpd-php application/rss+xml application/atom_xml text/javascript

Vous pouvez également activer le mode gzip. En cas d’erreur 500, votre config Apache demande l’activation des extensions nécessaire (à voir à l’aide d’un phpinfo() ou auprès de l’hébergeur). Tout ça est un poil technique je le convient, mais c’est vite fait et ça ne mange pas de pain.

Sur IIS c’est aussi simple (voir plus encore, c’est une case à cocher). Bref, c’est simple et pas prise de tête pour peu que vous cherchiez un poil.

Activation du cache

Le deuxième point facile à mettre en place est l’activation du cache navigateur et ce n’est pas plus compliqué, puisqu’il suffit encore une fois d’utiliser le .htaccess :

# cache 1 semaine
<FilesMatch « \.(jpg|jpeg|png|gif|swf|js|css|png)$ »>
Header set Cache-Control « max-age=604800, public »
</FilesMatch>

# cache 1 an
<FilesMatch « \.(ico)$ »>
Header set Cache-Control « max-age=29030400, public »
</FilesMatch>

En fonction du type de fichier, votre navigateur mettra en cache au premier accès les images, les flash, les javascripts et compagnie. Au deuxième accès, le navigateur n’ira pas les chercher sur le serveur, mais sur le disque dur. C’est plus rapide (pour l’internaute dès la 2° page) et économe en bande passante (pour vous).

Temps de téléchargement d’une page

Je vais aller vite, parce que nous sommes dans une partie bien plus technique. La donnée représentée ici est le temps de délivrance du HTML. On le voit sur le graph, ici c’est très lent puisqu’il faut environ 1.5 s pour obtenir le HTML. Ensuite il faut au navigateur aller chercher les éléments indiqués dans ce même HTML (images, js, css…). C’est long, d’autant qu’avec l’ADSL nous sommes particulièrement habitués à la vitesse.

Il n’y a pas une solution simple pour optimiser la génération du HTML. C’est un boulot de longue haleine qui demande pas mal de compétences et de temps. Donc, malheureusement on passe. Je ne vais pas non plus écrire un billet de 15000 pages sur le dév, faut pas pousser mémé dans les horties. Il faut voir cela après avoir mis en place les techniques les moins couteuses. Optimiser le code pourrait dans notre cas faire gagner éventuellement 1 seconde, les autres techniques le triple sur le temps total, tout en coutant moins cher. Le calcul est vite fait, pas besoin de réviser la règle de 3 pour comprendre quel est votre intérêt.

Petit bémol quand même puisqu’ici on parle uniquement de temps de génération, pas de volume. Si un site délivre le HTML en 5 secondes ou tombe avec 100 utilisateurs, il faudra y passer quand même (et il faudra aussi penser à envoyer les devs et le chef de projet en formation, ou à l’ANPE).

Performances du site

Voilà une page intéressante au possible, puisqu’elle réuni en son sein un graph sur la durée des temps de chargement de tous les éléments d’une page (alors qu’auparavant nous parlions uniquement du HTML) et un ensemble de conseils pour quelques pages, quasi les mêmes qu’yslow ou pagespeed.

Y a eu de l'optimisation non ?

Sur le graph ci dessus, vous pouvez voir que les temps de chargement de tous les éléments constitutifs d’une page ont considérablement baissés. Dans cet exemple, sur certaines pages, on observe  un temps de chargement 10 fois plus rapide, mais surtout une impression de chargement quasi instantané.

En premier lieu, il a été mis en place les actions les plus simples et rapides à mettre en oeuvre : compression, activation de la mise en cache navigateur, optimisation des images, indications des tailles des images,  regroupement et compression physique des css et js (minify). Bref du facile, qui rapporte gros rapidement.

Ensuite suppression ou déplacement de fonctionnalités sans aucune valeur ajoutée. C’est également simple à faire. C’est d’ailleurs quelque chose à surveiller à l’aide d’outils de web analytics. La rapidité aide à la conversion. C’est donc également le bon moment pour dépoussiérer le site et virer les fanfreluches (vous savez, les trucs bling bling) qui semblaient trop top géniales  kikoo lol au début et qui se révèlent au final de gros boulets. Eventuellement certaines fonctionnalités peuvent être supprimées pendant un gros pic de trafic, puis ré implémentées par la suite.

Les autres actions sont plus affaire de dév qu’autre chose (revue des requêtes SQL, mise en cache serveur, nettoyage de code, mise en place d’un cdn…) et ne sont pas toujours indispensables. Si votre site est assez ancien et qu’il a connu pas mal de modifs, le code est probablement devenu illisible, difficile à maintenir. Bref un gros tas de pus. C’est l’occasion de casser la tirelire et d’y consacrer un peu de temps. C’est vraiment à faire en dernier recours, tant le rapport perf/cout est souvent bas.

Si vous ne l’avez pas encore vue, regardez cette vidéo indispensable à qui voudrait en savoir plus et aller plus loin. Pour vous convaincre de la nécessité de tout cela, lisez cette article qui explique que près de la moitié des visiteurs d’un site n’attendent pas plus de 2 secondes pour qu’une page se charge (les fourbes).

Alors, vous vous y mettez quand ?

Question annexe : des billets techniques ça vous intéresse ? Quel niveau ?