C’est le résumé de Steve Souders qui a été publié récemment. On y retrouve quatre affirmations tirées des conférences. Toutes parlent d’une corrélation importante entre les performances et le trafic ou le business du site web :

Microsoft

Microsoft a trouvé qu’un ralentissement de deux secondes implique une réduction 1,8 % du nombre de recherches par utilisateur. Cela semble peu, mais c’est accompagné aussi d’une réduction de 4,3 % du revenu par utilisateur, et là ça fait moins rire. Autrement formulé : un utilisateur clique moins sur les publicités d’un site lent que sur les publicités d’un site rapide.

Ça rejoint d’ailleurs Google qui prend en compte la performance dans son « quality score » pour adword (en gros un site lent paiera plus cher ses publicités parce que le pourcentage de clic est plus faible) et c’est finalement logique, on hésitera à partir ailleurs et à se laisser tenter si on remet pas en cause une longue et pénible session de navigation qui nous a permis d’arriver jusqu’à la page en cours. Si la navigation est rapide on hésitera moins à partir dans diverses directions pour revenir ensuite.

Avis aux sites qui se rémunèrent sur la pub, et aux agences de comm qui font des publicités ultra lentes sous prétexte d’avoir une meilleur qualité d’image.

Google

Google lui a affirmé que 400 ms diminuait de 0,59 % le nombre de recherches par utilisateur. Là je suis un peu étonné parce que finalement ce n’est pas très significatif (sauf à ralentir de plusieurs secondes, et encore) et parce que leur dernière communication à ce sujet était d’un tout autre ordre de grandeur. Ils refont d’ailleurs état de chiffres bien plus importants dans une autre conférence dans le même événement. J’attends donc de lire leur communication complètement pour juger de ce que cela implique et de comment comprendre leurs différents chiffres qui ne semblent pas dire la même chose.

Par contre Google fait état d’un fait d’importance : les utilisateurs qui ont subit ce ralentissement minime de 400 ms continuent de faire moins de recherche sur le long terme même après que ce ralentissement soit supprimé. En gros vos performances actuelles vous impactent non seulement maintenant mais aussi dans le futur. Le chiffre avancé parait faible mais il a beaucoup d’implications et le contexte de Google est très particulier, j’y reviendrai donc certainement dans un billet dédié.

AOL

Sur le réseau AOL les 10 % d’utilisateurs qui ont les meilleures performances visitent moitié plus de page par session que les 10 % avec les moins bonnes performances.

Autant dire que cela a un impact sur le trafic des sites, et donc forcément la conversion en clic publicitaires ou en achats. Le chiffre est important mais il peut revêtir plusieurs formes, je vous en dirai plus quand j’aurai là aussi lu leur présentation à tête reposée.

Shopzilla

Enfin, Shopzilla a réduit le temps de chargement de 7 secondes à 2 secondes. C’est une différence importante et ça a donc du nécessiter des efforts conséquents, mais le résultat est là : 25 % d’augmentation de trafic, 7 à 12 % d’augmentation sur les revenus, et 50 % de réduction sur les coûts matériels.

À défaut d’être une formule magique, investir dans l’amélioration de la performance *doit* être considéré après lecture de ces chiffres. Payer une étude quelques milliers d’euros et un développeur interne pendant quelques jours/semaines pour corriger ce qui a été trouvé, cela peut assez facilement se révéler un investissement payant à court terme.

Firefox faisait déjà du préchargement, intelligemment, et ça sera probablement spécifié dans HTML 5. J’en reparlerai plus tard.

Aujourd’hui c’est de DNS que je souhaite parler. Chrome et Firefox 3.5 ont en effet tous deux la bonne idée de précharger les requêtes DNS. Pour les versions plus anciennes de Firefox il existe même une extension. Etonnamment (et malheureusement) ce n’est pas encore dans les brouillons HTML 5 par contre.

Comment ?

Trois types de préchargement sont identifiés :

Tout d’abord le navigateur identifie les liens vers toutes les ressources à charger et tente de résoudre le nom de domaine au plus tôt, en parallèle des autres téléchargements afin que cette résolution soit disponible quand il y en a besoin. Je suppose que l’effet sera ici très restreint car très fréquemment dès qu’un ressource vers un nouveau domaine est identifiée alors le téléchargement est immédiatement lancé. Les seules effets que je vois c’est si vous épuisez la totalité des fils de téléchargements du navigateur, ou si une ressource bloque les files de téléchargement (par exemple un javascript bloquant). Le premier cas ne doit quasiment jamais arriver, sur Firefox il faudrait 30 téléchargements simultanés répartis équitablement sur 5 domaines différents, sur Chrome c’est plus de 60 répartis équitablement sur plus de 10 domaines. Le second cas arrive de moins en moins (chrome 2 et Firefox 3.5 ne bloquent plus les téléchargements sur les javascript).

Le second type de préchargement c’est analyser tous les liens sur lesquels l’utilisateur peut cliquer, pour résoudre par avance le nom de domaine. Il y aura un gain réel dès que vous utilisez un lien entre deux sites distincts, c’est à dire très fréquemment quand même.. L’effet est réduit (on ne gagne que le temps de la résolution DNS) mais il vous fera effectivement gagner du temps.

Le troisième type de préchargement est déclaratif. Le navigateur repère les liens de type <link rel="dns-prefetch" href="//example.org"> et précharge la résolution DNS. Charge à l’auteur de faire les déclarations pertinentes en sachant ce qu’il précharge et pourquoi.

Chrome a en fait un quatrième type de préchargement DNS. Il retient à chaque fois les dix domaines résolus au précédent démarage, et les précharge pour vous immédiatement. Vos deux ou trois premiers clics à l’ouverture du navigateur seront donc magiquement accélérés. C’est peut être aussi ça qui donne l’impression de performance ressentis par certains. Mieux, il précharge les sites proposés dans l’autocomplétion de la barre d’adresse et de recherche. Le temps que vous preniez votre décision, l’option a déjà été préchargée et la page s’affichera d’autant plus rapidement. Là si l’effet lui même n’est pas plus important que les précédents, le ressenti utilisateur est clairement grandement amélioré, on donne une impression de continuité et de réactivité dans tout le navigateur, ce qui est exactement le ressenti exprimé par les utilisateurs de Chrome.

Pour quoi ?

Une résolution DNS c’est couramment entre 30 et 200 ms. Sur des sites américains, c’est assez souvent plus de 100 ms. Ces mécanismes de préchargement peuvent faire gagner la résolution DNS initiale, et donc la latence de la première requête, la plus importante. Pouvoir avancer dans le temps une ou deux résolutions DNS dans la page peut aussi améliorer les choses, mais je crains que là l’effet soit plus restreint. Dans l’ensemble c’est jusqu’à 150 ms qu’on peut gagner. Ce n’est pas grand chose mais ça reste quand même significatif.

Pour d’autres pays le résultat peut être encore plus important. Ainsi Google a ses propres statistiques récoltées avec Chrome où on voit que la moitié de des requêtes DNS des utilisateurs test se font en plus de 100 ms. Là où ça devient vraiment inacceptable c’est de voir que la moyenne est de 217 ms et qu’il y a encore pas loin de 10 % des requêtes qui dépassent la demi seconde. Même si ça arrive rarement, pouvoir gagner cette demi seconde est une victoire incontestable pour le confort utilisateur.

Vie privée et désactivation

Les petits malins auront remarqué qu’avec ce principe, en installant un mouchard dans son serveur DNS et en générant un nom de domaine unique différent à chaque utilisateur on peut traquer l’utilisateur. L’intérêt par rapport à une bête balise image est cependant assez faible. On peut déjà faire la même chose, mais en plus simple.

Si toutefois la chose vous gêne, vous pouvez le désactiver dans vos préférences Firefox (cherchez network.dns.disablePrefetch), ou ajouter une balise meta sur vos pages : <meta http-equiv="x-dns-prefetch-control" content="off">. Mais pourquoi voudriez-vous diminuer l’expérience utilisateur de toutes façons ?

Voilà donc Page Speed, en gros un Gslow avec quelques règles en plus et une ergonomie différente. On y trouve les même préconisations, avec un système de vérification automatique similaire.

Les mieux

• Vérification automatique de la compression des images (un petit équivalent smushit bienvenu), avec mise à disposition des fichiers recompressés
• Pourcentage d’utilisation du contenu des CSS, avec la liste des sélecteurs non utilisés dans la page
• Une règle pour inciter à préciser les dimensions des images pour éviter d’avoir à refaire plusieurs reflow dans la page
• Identification des sélecteurs CSS inefficaces (mais ils ont l’air un peu trop radical là dessus pour moi)
• Minification des javascripts (on vous propose la version minifiée pour remplacer la votre)
• Proposition pour retarder le chargement de javascript

Clairement il y a du bon. Mais surtout il y a un nouvel outil pour tracer le graphique en cascade des téléchargements. Celui de Page Speed propose tout ce qu’à Firebug 1.4 (DNS, connexion, queue, attente, téléchargement) mais on y ajoute les ressources prises depuis le cache (cache hit), une couleur spécifique à l’envoi de la requête (différente de l’attente de la réponse) et deux couleurs pour le temps d’analyse et le temps d’exécution des javascript. On a là le graphique en cascade le plus complet parmis tous les outils que j’ai vu jusqu’à présent. Ce sera un plaisir de travailler dessus.

Et le moins bon

Au niveau du mauvais il manque certaines règles et fonctions par rapport à Yslow2 :

• L’utilisation d’un CDN
• Présence de 404
• Présence d’AlphaImageLoader
• Redimensionnement des images dans le navigateur
• Règle spécifique au favicon
• Externalisation des composants
• Des notes plus précises

Des notes plus précises ça peut paraître inutile (Page Speed n’a que les catégories : bon, mauvais, moyen et informatif) mais c’est indispensable quand on ne travaille pas seul, ou quand la direction souhaite avoir un aperçu de l’avancement. Quand bien même une note sur 100 n’est pas extraordinairement pertinente, elle montre un avancement, permet de prioritiser les efforts entre plusieurs sites. Même la note Yslow de A à F est importante pour cela. Page Speed demande de compter les points en rouge et les points en vert pour se faire une idée, sans savoir lesquels sont vraiment importants et lesquels non. Bref, c’est un manque sérieux pour une réelle exploitation en entreprise.

Ouverture et extensibilité

Mais surtout il manque l’extensibilité de Yslow2. Implémenter les quelques règles supplémentaires de Google Page Speed dans Yslow 2 doit être faisable en une semaine de travail au plus, seul le graphique en cascade représente un réel développement non reprenable.

Et du coup c’est un peu décevant. Je suis un éternel idéaliste mais un tel outil est compréhensible au début. Google Page Speed arrive en dernier, après plusieurs autres outils. Il aurait été agréable de soit étendre l’existant (mais je suppose que la rivalité Google/Yahoo! a pris le pas sur les belles paroles d’ouverture et de « on veut aider les gens ») au au moins de prévoir d’être soi-même extensible (vu que Yslow 2 l’est).

Heureusement le code lui-même est sous licence libre (ceci est un appel du pied à Stoyan Stefanov à propos de Smushit), mais c’est tout de même dommage qu’ils aient loupé le coche de l’ouverture.

Compatibilité

Seconde note : La compatibilité avec Firefox 3.5 ou Firebug 1.4 est pour l’instant assez mauvaise, je ne sais pas lequel des deux est le coupable, mais testez sur un Firefox 3.0 avec Firebug 1.3 pour pouvoir tout utiliser. C’est dommage d’ailleurs parce que vu ce que m’apportent Firefox 3.5 et Firebug 1.4 au jour le jour, quand bien même ils sont en version de développement, je n’aime pas avoir à choisir entre eux et un autre bon outil.

Oui mais, mieux ou moins bien ?

Là il va falloir attendre. Je n’ai pas pu résister à publier un premier de billet de présentation. C’est un peu d’excitation mais aussi que sinon on va m’envoyer des liens vers Page Speed jusqu’à ce que je publie quelque chose. Pour la réelle analyse, savoir si les règles mises en place sont pertinentes (est-ce que regarder la complexité des sélecteurs CSS est une bonne chose ?), si les réglages fins sont corrects (si oui, qu’est-ce qu’on considère comme un sélecteur CSS complexe ?), il va falloir un bon mois de retour d’expérience. À dans un mois donc…

Oui il faut, quand vous le pouvez, utiliser les liens centralisés de Google ou de Yahoo pour vos bibliothèques javascript. Je parle de ne pas recopier jquery ou yui directement sur vos serveurs, mais d’utiliser les liens centralisés proposés par les deux moteurs de recherche.

Voilà pour la réponse générique, ensuite on peut détailler un peu.

Content delivery network

Le premier gain c’est l’utilisation des CDN de Yahoo! et de Google. Le principe du CDN c’est plus ou moins placer des serveurs dans plusieurs pays, voire directement chez les FAI, pour que le trajet fait sur le réseau soit le plus court possible. On vise une latence réduite. La latence ça peut tuer un site web.

Seuls les plus gros sites web peuvent s’offrir des CDN. Profiter de Yahoo! ou Google c’est toujours appréciable.

Maintenant vous n’utiliserez qu’une seule grosse bibliothèque javascript. En échange vous allez utiliser un nom de domaine supplémentaire, donc une requête DNS supplémentaire et une connexion de plus. Le deal est intéressant si ce qu’on gagne en latence dépasse ce que coûte la requête DNS.

Soyons clairs, si vos contenus ne sont pas sur le même continent qu’une partie sensible de vos clients, alors c’est un bon deal, n’hésitez pas. Aux États-Unis, éviter de traverser de l’Alaska vers New-York, c’est du temps gagné, non négligeable. Mais en même temps les sociétés vraiment internationales ont déjà souvent un hébergement par pays ou continent, ou utilisent déjà un CDN.

Si vous restez en Europe occidentale ça devient déjà moins clair. Si vous êtes hébergés en France dans un gros datacenter et que vos clients sont en France … là pas sur que le bénéfice du CDN soit réel. Les FAI ont des liens de peering entre eux et avec les hébergeurs français, la latence est globalement faible dès le départ. (Note: ceci n’a pas été vérifié par des tests, je suis preneur d’avis et de retours d’expérience sur la pertinence de CDN pour un trafic français avec un hébergement en France)

Nombre de domaines

Le second aspect de ces caches centralisés c’est le fait qu’ils sont justement sur un domaine séparé. Il y a du pour et du contre.

Dans le pour, votre Javascript peut être téléchargé immédiatement même si les files de téléchargement sont déjà occupées avec d’autres éléments de votre site. Maintenant comme on définit souvent ce genre de bibliothèques javascript tout en haut de page, les files de téléchargement sont généralement vides à ce moment là de toutes façons. Bref, je ne suis pas convaincu.

Toujours dans le pour, si votre navigateur est très récent (comprendre : IE 8, Safari 4, Firefox 3.1) le javascript ne bloque pas les autres téléchargements. Là aussi, avoir un domaine différent évite d’utiliser un slot dans vos autres téléchargements. En pratique, avec six slots simultanés minimum sur ces navigateurs, je ne suis pas convaincu que cela fasse une différence fondamentale.

Bref, pas convaincu, sachant qu’il y a du contre qui s’ajoute : avec un nom de domaine en plus, comme on l’a vu, il y a une requête DNS supplémentaire. Est-ce que ça vaut le coup pour un unique fichier ? pas sûr du tout.

Cache centralisé

Troisième aspect, en utilisant les liens de Google et Yahoo! on finit par tous utiliser les mêmes URL pour nos bibliothèques javascript.

Le résultat c’est que pour les bibliothèques les plus populaires, cela augmente la probabilité que vous l’ayez déjà en cache à cause d’un site précédent. Là le gain est important, surtout pour vos pages d’accueil (celles qui ont le plus gros trafic « cache vide »). Reste qu’en réalité l’URL contient la version de la bibliothèque et tous les sites n’utilisent pas les mêmes versions, ou même les mêmes bibliothèques. La mutualisation est assez limitée et le gain reste à prouver.

L’avantage concret est par contre visible pour les entreprises et pour les universités. Ces dernières ont des proxys cache qui auront toutes les chance d’avoir déjà votre bibliothèque en cache, dans la bonne version. Sur la cinquantaine (ou le millier) de collègues, il y en aura bien un qui aura téléchargé la bibliothèque avant vous.

La question est donc, vos visiteurs sont-ils sur des lignes professionnelles ou des lignes de particuliers ? dans ce second cas le gain n’est pas évident.

Mais alors, pourquoi répondre « oui » ?

Parce que je parlais jusqu’à maintenant du cas idéal. Si vous avez déjà un CDN, que vos ressources statiques sont déjà sur domaine séparé, et que vos entêtes de cache sont bien réglées, alors gardez vos bibliothèques chez vous. Mais … ce n’était le cas pour aucun de ceux qui m’ont posé la question.

En fait je doute que ce soit le cas pour quiconque se pose la question. Ceux qui ont déjà fait tout le chemin de performance avec CDN, domaine tiers et entêtes de cache, ils ont souvent les moyens de tester eux même quelle est la meilleure solution. Ou mieux, ils ont déjà réalisé que pour éliminer une requête HTTP il faut déjà fusionner leur bibliothèque javascript avec leur code javascript spécifique. Bref, la question est sans objet pour eux.

Pour les autres, qui n’ont pas les moyens d’utiliser un CDN quand bien même ils en auraient besoin, ou qui n’ont pas déjà un domaine séparé pour les ressources statiques, ou qui ne gèrent pas correctement leurs entêtes de cache, pour eux c’est intéressant. Ce n’est pas parfait, mais c’est un mieux, une démarche d’amélioration progressive. Pour vous, qui vous posez la question, la réponse est probablement « oui, utilisez les liens de Yahoo et Google pour vos bibliothèques javascript ». Et puis … ça fait autant de bande passante en moins à payer.

En cas de doute, le « oui » a plus de chance d’être positif ou sans effet que de réellement être négatif.

Google propose donc un codage supplémentaire pour HTTP qui s’appelle SDCH, et qui peut s’ajouter avant gzip ou deflate. Le serveur découpe sa page en paquets, qui peuvent chacun avoir des métadonnées et une expiration explicite. Le tout est stocké dans un dictionnaire du côté du navigateur, un peu comme les cookies actuellement. Quand le navigateur demande une page il envoie les identifiants de paquet qu’il connaît déjà, le serveur peut donc se contenter de compléter ce qui manque. On a donc le même fonctionnement que les Etag du point de vue de la négociation.

Les entêtes HTTP en jeu sont Avail-Dictionnary (l’équivalent de Etag pour SDCH) et X-SDHC (pour déclarer la version et l’implémentation de SDCH utilisée) du côté du navigateur, et X-SDCH-Dictionary du côté du serveur.

Reste que cela implique que la réponse du serveur soit codée suivant une forme bien particulière, non compatible avec les anciens clients HTTP. Google a donc prévu une auto-négociation et la réutilisation de l’entête Accept-Encoding. Grâce à cela, les navigateurs qui le peuvent auront un contenu SDCH puis compressé par gzip, les autres se contenteront du gzip.

Si vous voyez passer un Accept-Encoding: sdch, gzip c’est que votre navigateur supporte ce codage. Si en plus vous voyez une réponse Content-Encoding: sdch, gzip c’est que le serveur a bien compris que vous supportiez SDCH et va utiliser ce codage.

Je n’ai vu aucun mouvement ni aucune volonté de mouvement de la part de Mozilla, en fait depuis la communication de Google l’idée n’a pas l’air d’avoir fait recette où que ce soit. Seul un groupe de discussion, quasi vide, a fait suite à la communication de juin 2008.

Chrome a un premier support de SDCH (non activé par défaut pour la version publique actuelle) mais ça ne changera pas la face du monde. Le point intéressant est toutefois que SDCH est automatiquement intégré à Microsoft Internet Explorer si la Google toolbar est installée. La page d’aide de Google indique comment désactiver tout ça.

Si l’idée peut être intéressante, je suis un peu étonné que Google tente de l’imposer de lui-même sans avoir le support d’au moins un intervenant (Mozilla, Opera, Apple, Microsoft) ou une publication normative officielle de type RFC. La seule chose qui sauve cet unilatéralisme est la présence d’une version dans l’auto-négociation (donc on pourra gérer d’éventuelles évolutions dans les spécifications si jamais tout le monde se met autour de la table pour en rediscuter).

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

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.

Les chiffres de base

Je me base souvent sur des chiffres glanés je ne sais plus où (probablement Jackob Nielsen mais je ne retrouve pas la référence) : moins de 100ms c’est instantané, entre 100ms et 1s on perçoit la notion de téléchargement ou de calcul de la page qui arrive, et supérieur à 1s on a l’impression d’attendre.

Reste que dans ma mémoire ces chiffres n’étaient pas spécifiques au web. L’utilisateur web est habitué à attendre dans certains contextes, et habitué à avoir ce qu’il cherche immédiatement dans d’autre contextes. La bonne question c’est donc de savoir en dessous de quelle valeur on a un avantage concurrentiel sur les autres, et à partir de quelle valeur nos visiteurs partiront effectivement chez les concurrents.

Ceux qui font prendre conscience

Je vous avais donné des chiffres il y a quelques temps. Ils permettent de sensibiliser les gens : Montrer que Google perd 30% de traffic quand sa page passe de 400ms à 900ms est assez percutant. Montrer que 100ms a un impact concret sur les ventes d’Amazon impose de ne pas compter qu’en secondes.

Maintenant ces chiffres là non plus ne sont pas suffisants. Un moteur de recherche est un site bien à part. Lire ces données permet de prendre conscience de l’importance des performances mais cela ne vous donne toujours aucune référence, enfin sauf si vous développez un moteur de recherche.

Et ceux qui peuvent servir de seuil d’alerte

C’est Akamai qui va nous donner une dernière catégorie de chiffres. Dans un communiqué de 2006 ils identifiaient un palier à 4 secondes. Au delà de ce chiffre, les utilisateurs commencent à abandonner. Voilà un exemple de limite haute, qui doit générer une alerte quand vous la dépasser.

Maintenant n’oubliez pas que les choses ont évoluées depuis 2006. Le français moyen a une connexion avec un meilleur débit qu’à l’époque, sa machine est plus puissante et il a moins l’habitude d’attendre. Bref, dépasser 4 secondes est probablement plus grave qu’avant.

Gardez aussi le contexte à l’esprit. Un utilisateur qui cherche une information et vient à partir d’un moteur de recherche risque de ne pas attendre 4 secondes, là chaque dixième de seconde compte.

Quoi faire de ces chiffres ?

Tous ces chiffres sont déduis de mesures réelles et à prendre en compte. Ils sont donc vrais en même temps. Surtout ne gardez pas à l’esprit que ces 4 secondes.

Vous devez toujours viser de meilleures performances, et garder à l’esprit que 100ms ou 500ms peuvent représenter une perte de chiffre d’affaire ou un tiers de traffic en moins. Vous devez toujours vous rendre compte à partir de quel moment l’utilisateur percevra l’attente. Mais en plus, maintenant, vous avez un palier à partir duquel vous pouvez juger la page inacceptable.

Alors voilà, j’assume. Mais peut être que ça vaut le coup de rappeler trois chiffres qui permettront à chacun d’avoir des arguments quand on ne les prend pas au sérieux :

• Perdre 500ms c’est perdre 20% de trafic pour Google (ou pourquoi il n’y a que dix résultats par page dans les recherches).
• Augmenter la latence de 100ms c’est perdre 1% de ventes pour Amazon.
• Réduire de 25% le poids de la page c’est gagner 25% d’utilisateurs à moyen terme pour Google.
• Perdre 400ms c’est avoir 5 à 9% d’abandon en plus pour Yahoo! sur un site éditorial

Enfin, pour convaincre rien ne vaut une bonne citation :

Users really respond to speed.

– Marissa Mayer, Google, vice présidente de la section recherche et expérience utilisateur.