[Analyses] Pourquoi optimiser le temps de chargement

[Madrileño]

Optimiser le temps de chargement d'un site internet est important pour l'utilisateur (tout le monde n'est pas en haut débit et penser aussi à ceux qui utilisent des systèmes mobiles) et pour les moteurs (les robots crawls plus vite et facilement les sites).

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 !

qui sont disponibles sur la présentation de Monsieur Eric Daspet (blog du créateur : Performance web).

Le document est disponible à l'adresse :
slideshare.net/edaspet/performances-web-afup-2008-presentation
et d'autres informations sur la source.

Source : Pourquoi optimiser le temps de chargement de son site internet est-il super important ? | Korben.

 

[RiPSO]

Où agir?
-Changer de developpeur

:lol:

 

[screuscreu]

Merci beaucoup pour le partage, l'info et tout et tout.
Je lis cela au plus vite !

une reco

 

[Michel]

Merci encore une fois Madri, ça m'intéresse beaucoup ce sujet.

+1 reco

Oups ! j'ai "signalé", par erreur, en 1er

 

[ybet]

J'ai nettoyé mes codes il y a déjà quelques années -> pas de modifications dans mes stats visiteurs, ni même de temps passé sur les pages (en plus j'ai descendu les images pour que le texte apparaissent tout de suite).

Pour les mobiles, le % d'utilisateurs est finalement très faible et ils ont du s'habitué (rien qu'une animation pub en flash ...).
Avec FrontPage configuré comme 28.800K (on rève, plus personne n'utilise ca), des pages font jusque 180 secondes mais pas de différence de taux de rebond par rapport aux autres ...

Les vitesses sont suffisamment rapides actuellement pour ne plus trop s'amuser à bricoler les codes, un bon hébergement suffit.
J'avoue être passsé depuis 3 ans sur un petit dédié (500 € / an ) avec une quinzaine de sites hébergés (mais pas que les miens) ety fini les temps de réponse genre lézard suisse.
Site trop lent? plutôt un changement d'hébergement qu'une grosse modification du code.
Me souvient d'une entreprise d'hébergement basée à Strasbourg ... le forum de mon site était très lent ... et chaque fois la réponse était c'est mon forum :evil: . Transféré le site sur un dédié (et plus de problèmes) mais restait lmes autres sites. Un deuxième devient lent et réponse du servive techinque, c'est le forum du site WWW -> réponse: un peu facile, le site n'est plus hébergé chez vous depuis des mois :lol:
Lenteur d'un site = hébergement dans 80 % des cas + plus bloquer les aspirateurs (et oui, là c'est momentané mais qu'est ce que ca bouffe de la bande passante)

 

[zepatente]

Bonsoir,

les statistiques sur les gros sites et la perte que cela pourrait engendrer sont impressionnantes .
+ 1 reco

@+

 

[dd32]

Oups ! j'ai "signalé", par erreur, en 1er

Pas de problème, merci pour l'info

 

[goldo60]

Merci Madri je vais de ce pas...

 

[raljx]

d'ou mon sondage https://www.webrankinfo.com/forum/t/etude-de-cas-url-rewriting-php-ou-htaccess.103833/ qui peut egalement faire gagner quelque ms

Un outil interressant aussi :
http://websiteoptimization.com/services/analyze/

on peut énormément optimiser la vitesse nottament le nombre de requetes HTTP

 

[Advisto]

Un taux de rebond faible est important pour les sites de type e-commerce.
La présentation est un bon exemple pour mieux comprendre les enjeux pour les entreprises.

 

[jeanluc]

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

 

[djout]

merci pour ce joli poste madri :wink:

 

[screuscreu]

Pour l'optimisation, vos images sont :
-jpg
-jpg2000
-png24
-png8
-gif
-autre ?

Moi perso je suis en train de tester full png8

 

[Madrileño]

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

C'est une bonne question.

Pour l'optimisation [...].

C'est un peu suivant les images.

 

[Bigb06]

J'ai nettoyé mes codes il y a déjà quelques années -> pas de modifications dans mes stats visiteurs, ni même de temps passé sur les pages (en plus j'ai descendu les images pour que le texte apparaissent tout de suite).

Pour les mobiles, le % d'utilisateurs est finalement très faible et ils ont du s'habitué (rien qu'une animation pub en flash ...).
Avec FrontPage configuré comme 28.800K (on rève, plus personne n'utilise ca), des pages font jusque 180 secondes mais pas de différence de taux de rebond par rapport aux autres ...

Les vitesses sont suffisamment rapides actuellement pour ne plus trop s'amuser à bricoler les codes, un bon hébergement suffit.
J'avoue être passsé depuis 3 ans sur un petit dédié (500 € / an ) avec une quinzaine de sites hébergés (mais pas que les miens) ety fini les temps de réponse genre lézard suisse.
Site trop lent? plutôt un changement d'hébergement qu'une grosse modification du code.
Me souvient d'une entreprise d'hébergement basée à Strasbourg ... le forum de mon site était très lent ... et chaque fois la réponse était c'est mon forum :evil: . Transféré le site sur un dédié (et plus de problèmes) mais restait lmes autres sites. Un deuxième devient lent et réponse du servive techinque, c'est le forum du site WWW -> réponse: un peu facile, le site n'est plus hébergé chez vous depuis des mois :lol:
Lenteur d'un site = hébergement dans 80 % des cas + plus bloquer les aspirateurs (et oui, là c'est momentané mais qu'est ce que ca bouffe de la bande passante)

Je ne suis pas du tout d'accord, et ce n'est d'ailleurs pas du tout le thème du blog présenté. En dehors de tout problème de temps d'accès et de temps de génération de pages (script exécuté, BD,...) et donc même avec des fichiers statiques, 80% du temps de chargement d'une page a lieu côté client. Donc l'hébergement ne joue au maximum que sur 20% de la vitesse d'un site!

L'optimisation des performances est un gain énorme pour l'utilisateur. Personnellement et pour exemple, je n'aime pas surfer sur le forum de WRI depuis mon iphone car les pages sont trop lentes à charger. Donc le temps de chargement joue sur ma navigation.

Pour les crawlers, le fait d'optimiser la mise en cache des éléments CSS/JS/Javascripts avec des date d'expiration très éloignée permet d'optimiser les composants crawlés par les bots. Si on indique aux bots que toutes les images du site et autres composants ne changeront pas avant 2015, il ne vérifiera plus le contenu et ne téléchargera plus ces composants inutilement.
Les principales règles à mettre en place, facile et très efficace : http://developer.yahoo.com/performance/rules.html

 

[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/

 

[Ursu-Charlie]

Un article complémentaire sur le site pour optimiser le temps de chargement d'un site web

 

[Taranis]

[mode café]
Mais pourquoi donc optimiser le temps de chargement des sites ? Oui, pourquoi ?

Alors qu'avec Google Chrome :
Démarrage rapide (Google Chrome se lance à la vitesse de l'éclair)
Chargement rapide (Google Chrome charge les pages Web en un instant)
Recherche rapide (Effectuez des recherches sur le Web directement à partir de la barre d'adresse)

Mais il n'y a sûrement aucun rapport, vu que c'est pas Google qui a lancé la problématique hein

Des fois je pense : Google tient une majorité de webmasters par les c... , Google lance son giga rapide navigateur... Zut ça rame encore un peu , Google lance "le big plan speed optimisation" qui fait peur parce que PEUT-ETRE ça va influencer les SERPs, mais surtout c'est perte sèche de sous ! ... Et hop, les webmasters, les hébergeurs, les ingénieurs va falloir optimiser tout votre bazard.
C'est marrant comme c'est Internet qui doit changer et jamais Google s'adapter . Ça me rappelle quelque chose mais quoi... Ha ! Travailler plus pour surfer plus ! Le grand capital perché l'a dit !

Parce que depuis l'avènement de l'informatique, l'optimisation du code et la bonne gestion du poids des fichiers ont toujours été primordiales, presque la quintessence du numérique (mais ça les jeunes geeks ne le savent même pas).
Cependant il faut se mettre au goût du jour : la fibre optique c'est bien, les réseaux en Giga/s aussi, mais ça pèse combien en équivalent carbone ? Je vous le demande .

Merci Google consulting !
[/mode café]