[Analyses] Pourquoi optimiser le temps de chargement

[tonguide]

Voici quelques éléments utiles à savoir :

- Rajoutez 100 ms de temps de chargement à Amazon et vous perdez 1 % des ventes
- 400 ms de plus à Yahoo! et 5 à 9 % des gens s’en iront avant que le site soit chargé
- 500 ms de plus lors d’une recherche Google et c’est 20 % de recherches en moins (enorme !)
- Et si par miracle vous arriviez à alléger Google de 30 % de son poids, c’est 30 % de trafic supplémentaire que vous gagnerez !

Je ne vois pas d'explication sur l'origine de ces chiffres et les méthodes de mesure. Ai-je mal regardé ?

Jean-Luc

Le document que tu vois là est une synthèse du travail mené par son auteur qui est disponible sur son blog.

Il ne fait ici que résumé de façon très accessible (du moins, je trouve) ce que son blog présente dans les détails et bien plus techniquement que dans ce PDF. Je n'ai pas vérifié, mais je suis quasi sûr que tu retrouveras ces chiffres sur son site ainsi que les sources. Le chiffre d'Amazon par exemple est assez connu et fournit par Amazon lui même, d'où le fait qu'il soit très light d'ailleurs en terme de présentation.

J'ai quand même pris le temps 5sec et je suis tombé sur ça http://performance.survol.fr/2008/06/a-quoi-ca-sert/ (c'est son blog justement)

[TOMHTML]

J'ai quand même pris le temps 5sec et je suis tombé sur ça http://performance.survol.fr/2008/06/a-quoi-ca-sert/ (c'est son blog justement)

que des exemples qui datent de 2006 ou avant. Je reste donc méfiant, même si je ne conteste pas l'intérêt de réduire le poids de ses pages.

Néanmoins j'ai récemment multiplié par 3 le poids des pages d'un site. Pourtant j'ai aussi multiplié par 2,5 le nombre de visiteurs dans le même temps. Plus de poids = plus de contenu = plus d'intérêt = plus de visiteurs. CQFD.

[blman]

Une vidéo à regarder pour ceux que le sujet interresse :
http://www.camilleroux.com/2008/07/08/o ... -video-hd/

[e-kiwi]

11 secondes pour la page totalement chargée, pas mal, pas mal

[ofaurax]

Juste pour ajouter quelques chiffres, voici comment sont perçus les temps de réponse :
- 0,1s : réponse instantanée, l'utilisateur ne voit même pas le délai
- 1s : acceptable, l'utilisateur ressent le délai
- 10s : soit il fait autre chose, soit il ferme et cherche ailleurs

Source: http://www.useit.com/papers/responsetime.html

[raljx]

La video date un peu maintenant mais les regles de bases sont la ... en plus de l'augmentation des visites, l'optimisation de la vitesse est bénéfique par rapport aux bots ... une optmim des requetes HTTP (du moins en nombre) et, suivant le site, amène a booster les bots sur l'indexation. A voir les GWT sur les stats d'exploration, on voit une difference non negligeable entre un tps de reponse important et une optim. Ci-joint un printscreen des visites du bot de GG juste apres une optim sur les requetes Http (passées de 42 à 7 sur la page d'accueil)

l'optim est en rouge (a vous de faire le calcul de progression avec les chiffres du graph)
la grosse progression est du au mouvement qui se ressent actuellement au niveai des majs




petit rappel : le bleu : nb pages exporées par jour; le vert nb kilo par jour; le rouge tps de telechargement par jour:)

[emilia123]

bonjour,

je me permets de donner mon petit point de vue.
j'ai aussi des critiques sur les chiffres fournis, meme si le ne les remets pas en cause.
au niveau professionnel je surveille fréquemment des sites utilisant un CMS assez lourd avec parfois 4 à 5 secondes pour commencer à envoyer le contenu de la page.
pourtant les sites étaient à 200 000 visiteurs en moyenne avant le CMS et pas plus pas moins peu de temps après le ralentissement énorme du site, et ça garde la courbe de fréquentation apres quelques mois (augmentation constante).
si ça devait être 10 ou 20% de visiteurs en moins par 500ms ou même par secondes, il n'y aurait plus de visiteurs
effectivement cela fait fuir un nombre certain de visiteur, mais par contre la grande majorité (les non informaticiens=>pas nous) ne fait pas de différence entre 0.5 seconde et 5 secondes de chargement, même parfois avec 10 secondes (au delà ça commence à ne plus être la même chose).

c'est pas très "pro" comme discourt mais c'est un point de vue plus proche de ce que je constate souvent comparé aux chiffres annoncés

A bientôt

EM

[Ganf]

Effectivement, les -20% ne sont pas cumulatifs directement (sinon certains sites n'auraient plus personne), et dépendent de la cible comme du contenu. Par contre quand tu dis que les utilisateurs informaticiens ne font pas la différence entre 0.5s et 5s ou même 10s, tu es dans le faux.

Là c'est factuel, pas mal de gros sites ont des résultats fiables, avec des mesures de tests établies, sérieuses. On parle de sites grand public comme Yahoo, Amazon, ESPN, Google et plein d'autres. Eux ont tous vu une corrélation directe et automatique entre la performance en temps de réponse et le trafic, l'abandon, ou le taux de transformation. On parle là partout de différentiels inférieur à la seconde, et de résultats franchement pas négligeables.

Après vous en faites ce que vous voulez, mais en interne c'est vérifié et revérifié avec des mesures témoin et tout ce qu'il faut à des études sérieuses ; au point que c'est une priorité des équipes désormais.

Pour l'origine des citations quelqu'un a habilement pointé un billet. Certaines sont anciennes (quoi que deux ans, vu les courbes comparées de bande passante et d'augmentation de poids des pages, j'aurai tendance à dire que la situation n'a pu que empirer) mais la mesure yahoo (+400ms -> 5 à 9% d'abandons) est elle de ces derniers mois, encore une fois sur un site très grand public.

Mais plus que ces chiffres (qui sont volontairement là pour choquer), l'important à retenir c'est que quelques jours d'investissement permettent en général une très nette amélioration des choses. Le retour sur investissement est bien plus fort que la plupart des travaux habituels.

(maintenant si ton CMS fait 5s de génération de la page principal, tu as un gros problème backend à régler avant de passer à la suite)

[Leonick]

le problème, c'est qu'ils n'"analysent" qu'une petite partie de la génération d'une page web sur un navigateur.
C'est bien beau de parler de temps de création de page, de compression de données, de transfert de données allégé car gzip, etc...
mais quid du délais d'affichage de la page, des tonnes de js à faire ingurgiter au navigateur pour afficher la page ?
le ouebdeuxzéro, c'est ajouter des effets Prototype, Scriptaculous, jquery qui fait "tomber" pas mal de configuration de pc pas trop puissante. Tout ça pour quoi ? obtenir un effet que l'on pourrait avoir juste avec du css avancé.
Et pour moi, l'optimisation passe déjà par là.
Et puis, franchement, quand je vais sur myspace, je suis très loin d'obtenir un affichage de page en moins d'un seconde.

[Ganf]

Lisez les études avant de les commenter, c'est toujours mieux. Alors oui, ça prend en compte les temps de rendu de la page, les tonnes de js à ingurgiter et tout le reste.

[Leonick]

Lisez les études avant de les commenter, c'est toujours mieux. Alors oui, ça prend en compte les temps de rendu de la page, les tonnes de js à ingurgiter et tout le reste.

c'est pas vraiment ce qui est dit. A aucun moment je n'ai vu une invitation à restreindre les effets js, juste à mettre le js en fin de page (ou le charger dynamiquement) pour charger plus vite la page.
Mais alors, qu'est-ce que le chargement de la page ? c'est quand tout le code html est chargé ou bien quand la totalité de la page est opérationnelle (javascript, images, css, flash,...)
En plus, ils nous sortent des chiffres de hausse ou baisse d'audience, mais d'où les tirent-ils ?
Quand on augmente ou baisse fortement la taille d'une page, c'est que l'on a revnu, en même temps, certaines fonctionnalités. Est-ce ce changement de fonctionnalités ou le changement de taille qui fait que l'audience change ?
Si le temps de chargement était aussi important, pourquoi y a-t-il encore autant de sites développés en flash, surtout en considérant le fait que son référencement est bien moins évident qu'en html classique ?

[Ganf]

A aucun moment je n'ai vu une invitation à restreindre les effets js, juste à mettre le js en fin de page (ou le charger dynamiquement) pour charger plus vite la page.

Parce que un js bien fait ne coute pas grand chose. Il y a moyen de faire en sorte que ces javascript ne pénalisent pas trop l'utilisateur (en chargeant en asynchrone, en évitant de lancer trop souvent le rendu, en diminuant le temps de téléchargement bloquant). Certes, ça fonctionne aussi en retirant les javascript et les fonctionnalités mais ce n'est pas nécessaire d'aller jusque là (et surtout les gens ne sont généralement pas prêts à retirer des fonctionnalités, alors leur proposer de les faire "bien", ça permet déjà d'améliorer la situation).

Mais alors, qu'est-ce que le chargement de la page ? c'est quand tout le code html est chargé ou bien quand la totalité de la page est opérationnelle (javascript, images, css, flash,...)

Ca c'est une très bonne question par contre. Le plus souvent on compte le temps de chargement complet de la page et de tous les composants. Si vous ne chargez rien en asynchrone ça correspond souvent à la fin de l'événment onload. Sinon c'est le moment où plus rien ne télécharge en tache de fond. C'est la mesure la plus utilisée parce que la plus objective.
Cette mesure est en général obtenue avec Yslow, IBM Page Detailer ou AOL Page Test.

Mais on joue sur le ressenti utilisateur donc quand il s'agit de modifier les choses pour vous (et pas d'expliquer aux autres des choses objectives), on regarde aussi le temps de premier rendu, le temps de rendu nécessaire à ce que les éléments "visibles" soient chargés (ceux qui ne nécessitent pas un scroll ou une action pour être vus), et le temps pour que la page soit utilisable avec son contenu (quitte à ce que tout ne soit pas chargé/visible dans les images ou les js). Généralement on ne fait que en parler parce que justement c'est subjectif, donc on ne peut pas apporter de chiffres sur la table.

En plus, ils nous sortent des chiffres de hausse ou baisse d'audience, mais d'où les tirent-ils ?

De leurs mesures d'audience, tout simplement.

Pour beaucoup de choses un test utilisateur en labo n'est pas pertinent, c'est le cas des performances vu que ça joue sur le ressenti et "l'envie" d'aller sur le site (ce qui est à la base faussé par l'expérience). Du coup on joue sur les sites réels et on modifie un truc ou un autre pour certains utilisateurs. La plupart des grosses mises en prod sur les pages critiques (genre les pages d'accueil, les refontes de design) sont testes ainsi. On traque toute une série de comportements suivant ce qu'on cherche et on compare avec ceux qui ont le site habituel : temps de visite, clics sur les liens (tentés ou réussis), .... et temps de chargement

Google et Yahoo font comme ça en tout cas, mais la plupart des gros sites mettent en place ce genre de procédures un jour ou l'autre (des fois avec une vrai procédure, des fois plus artisanalement uniquement pour une fonctionnalité bien précise)

Quand on augmente ou baisse fortement la taille d'une page, c'est que l'on a revnu, en même temps, certaines fonctionnalités. Est-ce ce changement de fonctionnalités ou le changement de taille qui fait que l'audience change ?

Pas forcément justement. Un coup de gzip, un coup de minimification, c'est déjà 95% de tes fichiers html/js/xml/css/json qui vient d'être éliminé. Un coup de smushit c'est souvent entre 10 et 50% du poids de tes images qui vient d'être retiré. Pas besoin de toucher aux fonctionnalités là.

Mais oui, dans le cas de Google on parle bien de changer la fonctionnalité sur la première mesure. Si vous suivez le lien c'est un test pour savoir s'il faut faire des pages de 10 ou 30 résultats pour les recherches. Le contenu influe clairement sur le test, mais logiquement passer à 30 devrait plutot augmenter l'intérêt utilisateur. Visiblement c'est le contraire qui se passe.
Le second chiffre Google est lui obtenu sur Maps, à fonctionnalité quasiment égales. Il s'agit de savoir ce qui est préchargé ou non, d'optimiser le poids de ce qui est chargé.

Si le temps de chargement était aussi important, pourquoi y a-t-il encore autant de sites développés en flash, surtout en considérant le fait que son référencement est bien moins évident qu'en html classique ?

Tous les gros qui parlent performance ont déjà choisis des sites en HTML classique, donc je vais manquer de base pour répondre. Déjà je ne suis pas certain que tous les sites en flash aient forcément un temps de réponse pourri, mais en même temps je n'ai aucun chiffre sur les sites flash dont je ne vais pas m'aventurer à trop en parler.

Maintenant ce qui est certain, c'est que le fait que quelque chose soit mauvais n'a jamais empêcher plein de gens de le faire quand même, quel que soit le sujet, même si on ne parle pas des perf.

[J Lock]

Slt,
C'est vrai que c'est important d'avoir une page assez rapide (legere) pour avoir des temps de telechargement corrects.
Mais je dirais quand meme que pour un site qui doit vendre ou qui doit etre agreable, il est important d'avoir des images en quantité.
J'imagine mal un site d'information sans illustration ou un site marchand sans image descriptive...
De mon coté, je test en continue le temps de telechargement de mes pages pour m'assurer que les modifs de la plateforme ou des images n'a pas trop d'impact sur mes temps / performances.

[Bigb06]

Les images peuvent être de bonne qualité mais doivent être optimisées, par exemple avec cet outil:
http://smushit.com/
beaucoup d'exemples et d'études de cas ici:
http://graphicsoptimization.com/blog/