Afin d’avoir des chiffres réels archivés, j’ai fait un bref état des lieux du web français. Il s’agit de mesurer 12 pages d’accueil à fort trafic représentatives des usages français. Le résultat n’est pas glorieux :
Les mesures
Aux sites représentatifs j’ai arbitrairement ajouté France Telecom. Il s’agit pour moi d’ajouter une valeur haute, pas si rare que cela. J’ai d’ailleurs aussi compté la redirection de leur page d’accueil et je tiens à signaler que leur performance est très aléatoire, de 5 à 17 secondes.
Les mesures sont toutes prises avec Yslow, en premier accès (cache vide), en retenant la médiane d’une dizaine de tentatives. Là aussi j’ai eu parfois des résultats assez aléatoires, principalement à causes des publicités (mais l’utilisation de la médiane permet qu’ils ne faussent pas les résultats).
J’ai pris comme base un navigateur à deux connexions simultanées (Firefox 2, Internet Explorer 6), ce qui reste encore le mode d’accès le plus fréquent. Le réseau est un réseau wifi G 54mb/s à quelques mètres de la borne, et derrière une ligne ADSL avec une bonne connexion. La latence aller-retour lors du test est de 7ms entre mon poste sous WIFI et free.fr, mon FAI. Mon poste est récent, le processeur non utilisé, et suffisament de RAM libre pour faire tout ce que je souhaite. Bref, certains ont des conditions plus avantageuses mais les mesures sont prises dans des conditions plus que favorables, meilleures que la moyenne des français.
Le résultat
| TF1 | 5,0 secondes |
| AlloCiné | 4,0 secondes |
| 4,6 secondes | |
| Skyrock | 3,7 secondes |
| France Telecom | 10,1 secondes |
| Free | 4,4 secondes |
| Google France (résultats de recherche) | 0,24 secondes |
| Yahoo! France | 1,8 secondes |
| Daily Motion | 2,4 secondes |
| Le Monde | 7,9 secondes |
| Amazon France | 3,7 secondes |
| MSN France | 0,9 secondes |
On perçoit tout de même trois catégories, avec les trois gros qui sont en dessous des 2 secondes parce qu’ils ont compris que c’est critique, les suivants qui prennent en compte les problématiques de performance et qui sont en dessous des 4 secondes, et les autres avec quelques résultats dramatiques. Je reste toutefois surpris du mauvais score de Le Monde, sachant que dans l’équipe il y a au moins un technicien au fait de ces problématiques et très compétent.
N’oubliez pas, 3 secondes c’est important, à partir de 4 secondes les abandons sont fréquents. Les gros remarquent des impacts significatifs sur leurs ventes et sur leur trafic pour des dixièmes de secondes.
Tu aurais des URLs précises des pages testées ? Je connais des gens que ça intéresse…
Les pages d’accueil FR, à chaque fois. Le plus souvent après redirection quand la redirection a du sens, sauf pour FT où j’ai inclus la redirection parce qu’elle n’était pas une simple redirection de type fr.* vers */fr (ici il y a 3 redirections coup sur coup) et parce que ça bouffe 3 secondes rien que pour ça.
Ce serait sympa de trier le tableau pour faciliter la lecture 🙂
Mettre le poids de ces pages pourrait-être intéressant aussi. Le deuxième chargement peut aussi changer la hiérarchie.
Sinon, on essaye de faire toujours mieux de notre côté mais y a évidemment plein de contraintes qui ne facilitent pas la tâche.
Je compte faire un suivi sur ces sites là. Si je trie sur ce critère ça ne sera pas trié sur les suivants. Du coup j’ai laissé en vrac.
Si je devais vraiment trier je ferai deux parties, ceux qui vraissemblablement ont fait du boulot sur les perfs, et les autres. Ca se résume assez bien ici avec « inférieur à 4s ou supérieur à 4s » et ça correspond avec ce que je sais/suppose des différentes équipes de développement.
A terme oui, il y aura aussi la stat du second chargement et des valeurs pour de multiples configurations. Si quelqu’un veut me fournir ses chiffres je les ajouterai avec plaisir, sinon il faudra attendre que j’en ai besoin et que je les fasse.
@Rik: Il y a toujours plein de contraintes et personne n’a dit que tout est toujours facile, je ne sais bien. Coté sky ce qu’il manque est probablement quelques sprites, et un CDN (avec un ou deux domaines pour répartir) mais déjà sur un navigateur plus récent avec 6 connexions simultanées vous tombez en dessous des 2 secondes, ce qui est plutot positif.
Concernant les sprites, ça ne sera pas super efficace sur la home (mais toujours ça de gagné). On a un souci avec les images qui sont celles des utilisateurs donc difficilement spritables.
Pour le CDN, hormis la répartition géographique, on a déjà plusieurs domaines même parfois trop (mais là encore, problème d’images utilisateurs).
En même temps, si les mesures ont été prises avec YSlow, cela veut dire que Firebug était activé. Or, Firebug est connu pour ralentir le chargement de n’importe quel site un tant soit peu chargé en JS.
@Boris: c’est vrai et faux.
* Sur les dernières versions de Firebug les onglets réseau, debug javascript et console sont désactivés. L’onglet de debug js est toujours désactivé chez moi. Le javascript n’est donc pas ralenti.
Il faudrait que je retente les tests pour confirmer les chiffres avec et sans l’onglet réseau (qui était activé) mais j’ai bon espoir de penser que son influence est assez faible.
En attendant je considère les chiffres relativement corrects, mais surtout quelle que soit la valeur absolue, les chiffres relatifs eux sont tout à fait flagrants.
* Comme je suis bon joueur et dans une phase de recherche, je t’ai pris au mot et j’ai utilisé AOL Page Test. Ce dernier se branche sur les API de Microsoft Internet Explorer et ne fait aucun traitement (donc à priori pas de ralentissement notable).
Les chiffres sont similaires (en fait exactement pour France Telecom AOL Page Test trouve 12s avant le début du rendu, et 28s pour le document complet, donc bien plus que je n’ai avec mon Firefox/yslow
A priori on peut donc considérer les chiffres comme valides.
Si tu les trouves toujours bancales je te laisse mener tes propres tests, avec le protocole de ton choix pour peu que tu le documentes. Je les publierai avec plaisir.
* Mais surtout on est dans un domaine de recherche/expérimentation. C’est à dire que le chiffre absolu importe peu. Ce qui importe c’est que tout le monde utilise la même référence.
Quand Yahoo! dit que +400ms implique de son côté 5 à 9% d’abandon sur un de ses sites éditoriaux, ils utilisent yslow aussi. Je sais donc que 4 secondes c’est important.
Tu peux oublier les millisecondes et considérer qu’on compte en gloubiboulga, au final ça revient au même : ces chiffres sont important, avec des outils similaires (Page Test, Page Detailer, Yslow) ceux qui ont fait des corrélations traffic/ventes/performance trouvent que des différences de 1/10ième ou 1/40ième de nos chiffres ont des impacts dramatiques. Que ce soit des millisecondes, des gloubiboulga ou pas, ça ne change rien.
Bref, peu importe la valeur du chiffre, ce qui m’intéresse c’est la comparaison. Que Firebug ralentisse ou pas, si les autres mesurent avec le même type d’outils et que mes différents outils me donnent le même type de mesure, ça me suffit.
TRès intéressant de voir que les moteurs de recherche sont ceux qui ont le plus besoin de la rapidité d’affichage. Probablement aussi que des sites d’infos comme le monde sont aussi bourrés de codes pour actualiser les pages, ainsi que les publicités, avec beaucoup de petits cadres affichant des infos venant d’autres sites, et ainsi multipliant les requêtes http. En tout cas ça conforte l’idée précédement évoquée d’améliorer la rapidité d’affichage. Je pense que je vais enlever un ou deux post pour l’arrivée sur la page d’entrée. Ce sera toujours ça de gagner.