Performances sites web

Bonjour.

"Pierre Goiffon" <pgoiffon@free.fr.invalid> a écrit dans le message
de news 493e50c5$0$14412$426a74cc@news.free.fr

Salut, un post pour 2 questions :

- j'ai lu régulièrement que sur la majorité des sites le traitement
du back-end ne représente qu'une toute petite partie du temps de
rendu
total d'une page, et que donc c'est bien le front-end qu'il faut
améliorer. Ok mais... je cherche une page avec des chiffres
concrets histoire de confirmer cette théorie avec la réalité.

Je n'ai pas de telle documentation, mais un exemple visible:

J'ai installé sur le Firefox de ma station de développement une extension
nommée LoadTimeAnalyser.

Elle trace un graphe de la totalité du process de chargement d'une page.
Ceci met bien en évidence les temps de traitement du corps et de chaque
média, et on y voit notamment la sérialisation OU parallélisation de
certaines requêtes ainsi que, pour chaque requête, des phases d'attente
avant traitement effectif qui représentent bien plus de la moitié du délai.

Le lien exact avec la répartition frontend/backend n'est pas forcément
direct, mais ça peut donner des indices.

--

Cordialement.
--
* Patrick BRUNET www.ipzb.fr www.ipzb-pro.com
* E-mail: lien sur http://zener131.eu/ContactMe

Patrick 'Zener' Brunet wrote:

J'ai installé sur le Firefox de ma station de développement une extension
nommée LoadTimeAnalyser.

Elle trace un graphe de la totalité du process de chargement d'une page.
Ceci met bien en évidence les temps de traitement du corps et de chaque
média, et on y voit notamment la sérialisation OU parallélisation de
certaines requêtes ainsi que, pour chaque requête, des phases d'attente
avant traitement effectif qui représentent bien plus de la moitié du délai.

Ca semble intéressant merci !

AOL Page test comble justement un des manques de Firebug+YSlow : le
temps "Time to first byte", mais c'est uniquement sur la page, ça n'est
pas présenté sur des JS générés dynamiquement par exemple

Le 12/9/08 12:04 PM, Pierre Goiffon a écrit :

Salut, un post pour 2 questions :

- j'ai lu régulièrement que sur la majorité des sites le traitement du
back-end ne représente qu'une toute petite partie du temps de rendu
total d'une page, et que donc c'est bien le front-end qu'il faut améliorer.
Ok mais... je cherche une page avec des chiffres concrets histoire de
confirmer cette théorie avec la réalité.

- question outils : je viens de tomber sur AOL Page test
(http://pagetest.wiki.sourceforge.net/). Ca semble faire la même chose
que l'onglet Net de Firebug... de ce que j'ai pu lire on utiliserai cet
outil plutôt que Firebug car ce dernier ralentirai considérablement le
rendu et aurait donc un impact sur la mesure... Là encore je cherche de
quoi savoir à quoi m'en tenir !

Merci de vos réponses !

Personnellement, je n'ai absolument pas l'impression que FireBug
ralentisse quoique ce soit.
Justement hier je me demandais comment ce truc pouvait réagir aussi
promptement.

L'histoire des back/front-end en Fr ça donne quoi ?

De ttes façons, moi, faut que j'attende que les bits me parviennent,
donc au moins y en a au plus vite le end.
(ça a l'air d'aller dans l'allègement du front non?)

Tout ça dépend de ce qui est envoyé et du navigateur qui assurera le
traitement (ex des tables bien en soupe de balises et imbriquées et
fournies, avec mon IE .... ! )

Et bien sûr de la propention à vouloir disposer de toutes les biblis JS
des fois que ...

--
sm

Le 12/9/08 3:09 PM, Patrick 'Zener' Brunet a écrit :

Bonjour.

"Pierre Goiffon" <pgoiffon@free.fr.invalid> a écrit dans le message
de news 493e50c5$0$14412$426a74cc@news.free.fr

Salut, un post pour 2 questions :

- j'ai lu régulièrement que sur la majorité des sites le traitement
du back-end ne représente qu'une toute petite partie du temps de
rendu
total d'une page, et que donc c'est bien le front-end qu'il faut
améliorer. Ok mais... je cherche une page avec des chiffres
concrets histoire de confirmer cette théorie avec la réalité.

Je n'ai pas de telle documentation, mais un exemple visible:

J'ai installé sur le Firefox de ma station de développement une extension
nommée LoadTimeAnalyser.

à propos,
Safari dispose d'un outil assez semblable
dès qu'on a débloqué son Web developpeur.

Hop! le site Apple.fr (qui n'a jamais fait dans le trop léger) :

- 3,6 secondes pour le trouver
- 5 secondes pour charger prototype
- 2 seconds pour scriptaculous (*merci les biblis ! ! !*)
- 1,5 secondes pour une autre chiée de JS maison
- 3 secondes de CSS
- 3 autres secondes de JS
- et enfin 3 secondes de contenu ! ! !
- plus 4 secondes de trucs à la traine (RSS et gif)

Total = 15 secondes (des trucs heureusement se chargent de concert)
dont les 11 premières pour le JS et les CSS :-(

Document : 4 kb
CSS : 17 kb
Images : 358 kb
Scripts : 320 kb (mais kessk'yz'ont besoin de tt ça ?)
Autre : 16 kb
Total = 475 kb


Je change de page (ça va profiter du cache ?)
- 1,2 seconde d'attente de réaction
- 2 secondes de JS et CSS
- 2,5 secondes d'images
- 2 secondes pour affichage et réflexion de la console
Total = 6 secondes.

300kb d'images et 412kb de JS pour un poids total de 780kb

Les retours (back-end ?) sur pages se font en :
- Page 2 : 1,2 seconde (une grosse image à afficher)
- Page 1 : 0,4 seconde

iMac-Intel duo core 2,16Ghz - 2Go RAM - système 10.4.11
ADSL 4Mbits/s

--
sm

SAM wrote:

Personnellement, je n'ai absolument pas l'impression que FireBug
ralentisse quoique ce soit.

En fait de mon côté Firebug n'est activé que sur certains domaines (eu
qq gros crash au début quand il était activé en permanence)
Mais quant il est activé, je n'ai pas eu de constat flagrant non plus de
différence mais ça ne veut pas dire qu'il n'y en ait pas :)

L'histoire des back/front-end en Fr ça donne quoi ?

L'idée c'est séparer le traitement pour la logique métier et tout le
traitement client pour la présentation. Enfin en gros et un peu
schématiquement la génération de la page côté serveur, et tout ce qui va
être affichage à l'utilisateur final (téléchargement des ressources,
rendu de la page, traitements JS, ...)

De ttes façons, moi, faut que j'attende que les bits me parviennent,
donc au moins y en a au plus vite le end.
(ça a l'air d'aller dans l'allègement du front non?)

Et justement, il semble que dans la majorité des cas si tu as 10s pour
rendre une page, il n'y aura qu'une infime partie de ce temps lié aux
traitements côté serveur.
Pour tout ce qui est "front-end", il y a un grand nombre de bonnes
pratiques, tu en cite certaines. C'est souvent (relativement) peu
coûteux à mettre en place.

Pierre Goiffon wrote:

Merci de vos réponses !

Pas de réponses, mais une question en plus:
La qualité de la liaison, comment ils la prennent en compte?
Parcequ'un site sera forcément moins veloce si le client est sur une
ligne à 56K que sur un autre type de ligne

--
Huile Essentielle de Camphre http://www.huile-camphre.fr
Infogerance http://www.infogerance.us
(Serveurs, Postes de travail, Développement logiciel)

Mihamina Rakotomandimby wrote:

La qualité de la liaison, comment ils la prennent en compte?
Parcequ'un site sera forcément moins veloce si le client est sur une
ligne à 56K que sur un autre type de ligne

Qui ça ils ??

Pierre Goiffon a écrit :

Salut, un post pour 2 questions :

- j'ai lu régulièrement que sur la majorité des sites le traitement du
back-end ne représente qu'une toute petite partie du temps de rendu
total d'une page,

Ca dépend de pas mal de paramètres... Dont la lourdeur du traitement à
effectuer côté serveur pour générer la page. J'ai (hélas) des examples
où le plus lourd est clairement le traitement côté serveur :(

et que donc c'est bien le front-end qu'il faut améliorer.

Disons que c'est _aussi_ un aspect à prendre en compte. De plus en plus,
d'ailleurs, vu la lourdeur croissante des scripts côtés client.

Ok mais... je cherche une page avec des chiffres concrets histoire de
confirmer cette théorie avec la réalité.

Tu ne pourra pas "confirmer" grand chose dans l'absolu, cf ma première
remarque. Par contre, il est clair qu'il y a un certain nombre
d'optimisations possibles (et connues) pour la partie client - la plus
évidente étant de minimiser le nombre de requêtes HTTP nécessaires pour
récupérer les ressources liée à la page (css, scripts, images etc), et
la seconde étant de jouer sur les noms de domaines servant ces
ressources de façon à augmenter le nombre de requêtes "parallèles".

- question outils : je viens de tomber sur AOL Page test
(http://pagetest.wiki.sourceforge.net/). Ca semble faire la même chose
que l'onglet Net de Firebug... de ce que j'ai pu lire on utiliserai cet
outil plutôt que Firebug car ce dernier ralentirai considérablement le
rendu et aurait donc un impact sur la mesure... Là encore je cherche de
quoi savoir à quoi m'en tenir !

Je n'ai pas été voir cette page - Firebug m'étant de toutes façons utile
(pour ne pas dire indispensable) pour d'autres raisons - mais de toutes
façons, tous les outils de mesure tendent à influer ce qu'ils mesurent.
L'essentiel, en tout état de cause, n'étant pas le résultat absolu, mais
l'évolutions entre plusieurs résultats. En d'autres termes, même si ton
outil de mesure ralenti le traitement, ce qui importe, c'est de mesurer
(relativement) l'impact moyen de telle ou telle modification dans telle
ou telle configuration.

HTH

Bruno Desthuilliers wrote:

- j'ai lu régulièrement que sur la majorité des sites le traitement du
back-end ne représente qu'une toute petite partie du temps de rendu
total d'une page,

Ca dépend de pas mal de paramètres... Dont la lourdeur du traitement à
effectuer côté serveur pour générer la page. J'ai (hélas) des examples
où le plus lourd est clairement le traitement côté serveur :(

C'est en tout cas bien plus simple d'améliorer les choses avec peu
d'actions sur le front-end que de revoir l'ensemble des traitements côté
serveur !
Au final il faut que les pages soient affichées vite, donc intervenir là
où il faut sans considération bien sûr :)

Ok mais... je cherche une page avec des chiffres concrets histoire de
confirmer cette théorie avec la réalité.

Tu ne pourra pas "confirmer" grand chose dans l'absolu

Des "chiffres généraux" donnent des tendances. Après on est
systématiquement face à un cas particulier.
J'avais vu passer une étude comparant les tailles des pages des n plus
gros sites mondiaux, je suppose que l'on aurait l'équivalent pour les
temps de chargement ?

de toutes
façons, tous les outils de mesure tendent à influer ce qu'ils mesurent.
L'essentiel, en tout état de cause, n'étant pas le résultat absolu, mais
l'évolutions entre plusieurs résultats. En d'autres termes, même si ton
outil de mesure ralenti le traitement, ce qui importe, c'est de mesurer
(relativement) l'impact moyen de telle ou telle modification dans telle
ou telle configuration.

Bonnes remarques !

Pierre Goiffon a écrit :

Bruno Desthuilliers wrote:

- j'ai lu régulièrement que sur la majorité des sites le traitement
du back-end ne représente qu'une toute petite partie du temps de
rendu total d'une page,

Ca dépend de pas mal de paramètres... Dont la lourdeur du traitement à
effectuer côté serveur pour générer la page. J'ai (hélas) des examples
où le plus lourd est clairement le traitement côté serveur :(

C'est en tout cas bien plus simple d'améliorer les choses avec peu
d'actions sur le front-end que de revoir l'ensemble des traitements côté
serveur !

Pas nécessairement... Des fois, de simples optimisations d'algorithme,
ou d'index dans une base SQL, ou de paramétrage du serveur - bref, des
opération qui n'impacte que quelques lignes d'un fichier-, peuvent
améliorer très drastiquement les perfs côté serveur. Alors qu'optimiser
le temps de chargement et rendu à proprement parler (c'est à dire le
délais entre le moment où le client reçoit le premier bit de la requête
HTTP et le moment où la page est intégralement rendue) peut nécessiter
de reprendre tous les templates (en partant du principe qu'on génère le
HTML à la volée...) _et_ tous les javascripts _et_ toutes les css _et_
le paramétrage du serveur (gzip, noms de domaines distincts pour les
scripts, css et ressources statiques etc).

Mais ce que je voulais surtout dire, c'est que l'affirmation selon
laquelle le traitement côté serveur ne représenterait qu'une petite
partie du temps total du cycle requete => page rendue est en soi
discutable. Ca dépend vraiment du type de site. Si ton appli mets 10
secondes à traiter une requête, tu peux optimiser ce que tu veux sur le
client, ça ne changera pas grand chose au résultat final !-)

Au final il faut que les pages soient affichées vite, donc intervenir là
où il faut sans considération bien sûr :)

<aol />

Ok mais... je cherche une page avec des chiffres concrets histoire de
confirmer cette théorie avec la réalité.

Tu ne pourra pas "confirmer" grand chose dans l'absolu

Des "chiffres généraux" donnent des tendances. Après on est
systématiquement face à un cas particulier.
J'avais vu passer une étude comparant les tailles des pages des n plus
gros sites mondiaux, je suppose que l'on aurait l'équivalent pour les
temps de chargement ?

En testant d'où, avec quelle connection, quelle bande passante, à quelle
heure, quel jour (et de quelle année...), quel navigateur, sur quelle
machine, avec quoi d'autre tournant sur la machine, avec ou sans firewall ?

Le poids total d'une page est une donnée absolue. Le temps total
nécessaire au cycle requete => page rendu dépend de bien trop de
variables pour avoir une signification en soi. Au mieux, tu peux prendre
une liste de sites, et faire plusieurs séries d'essais, avec des
conditions aussi similaires que possible[1] pour chaque série, et faire
quelques moyennes.

[1] chaque série devrait être faite dans un laps de temps aussi bref que
possible (pour minimiser les variations de variables non contrôlables
comme la bande passante réelle etc), avec le même navigateur sur la même
machine, avec le minimum vital d'autres applis tournant simultanément.

de toutes façons, tous les outils de mesure tendent à influer ce
qu'ils mesurent. L'essentiel, en tout état de cause, n'étant pas le
résultat absolu, mais l'évolutions entre plusieurs résultats. En
d'autres termes, même si ton outil de mesure ralenti le traitement, ce
qui importe, c'est de mesurer (relativement) l'impact moyen de telle
ou telle modification dans telle ou telle configuration.

Bonnes remarques !