- 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 !
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...
Je ne me suis pas exprimé clairement : - pour le front-end on a un ensemble de bonnes pratiques et d'optimisations claires et identifiées. - les traitement serveur, il faut aller diagnostiquer, et une fois compris les problèmes, intervenir
C'est ce que je voulais dire par "bien plus simple" : les corrections sur le front end seront les plus immédiates à mettre en route.
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 !-)
Des dizaines de secondes pour télécharger les ressources et rendre une page, ça arrive facilement !
Concernant la part du traitement serveur et rendu, développeur j'ai plutôt l'habitude d'optimiser mes requetes et traitements. C'est bien pour ça que lisant autant de fois que les traitements serveurs ne représentent qu'une petite partie du temps d'affichage global je me pose des questions sur les raisons de cette affirmation très largement répandue.
Bruno Desthuilliers wrote:
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...
Je ne me suis pas exprimé clairement :
- pour le front-end on a un ensemble de bonnes pratiques et
d'optimisations claires et identifiées.
- les traitement serveur, il faut aller diagnostiquer, et une fois
compris les problèmes, intervenir
C'est ce que je voulais dire par "bien plus simple" : les corrections
sur le front end seront les plus immédiates à mettre en route.
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 !-)
Des dizaines de secondes pour télécharger les ressources et rendre une
page, ça arrive facilement !
Concernant la part du traitement serveur et rendu, développeur j'ai
plutôt l'habitude d'optimiser mes requetes et traitements. C'est bien
pour ça que lisant autant de fois que les traitements serveurs ne
représentent qu'une petite partie du temps d'affichage global je me pose
des questions sur les raisons de cette affirmation très largement répandue.
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...
Je ne me suis pas exprimé clairement : - pour le front-end on a un ensemble de bonnes pratiques et d'optimisations claires et identifiées. - les traitement serveur, il faut aller diagnostiquer, et une fois compris les problèmes, intervenir
C'est ce que je voulais dire par "bien plus simple" : les corrections sur le front end seront les plus immédiates à mettre en route.
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 !-)
Des dizaines de secondes pour télécharger les ressources et rendre une page, ça arrive facilement !
Concernant la part du traitement serveur et rendu, développeur j'ai plutôt l'habitude d'optimiser mes requetes et traitements. C'est bien pour ça que lisant autant de fois que les traitements serveurs ne représentent qu'une petite partie du temps d'affichage global je me pose des questions sur les raisons de cette affirmation très largement répandue.
Bruno Desthuilliers
Pierre Goiffon a écrit :
Bruno Desthuilliers wrote:
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...
Je ne me suis pas exprimé clairement : - pour le front-end on a un ensemble de bonnes pratiques et d'optimisations claires et identifiées. - les traitement serveur, il faut aller diagnostiquer, et une fois compris les problèmes, intervenir
yeps...
C'est ce que je voulais dire par "bien plus simple" : les corrections sur le front end seront les plus immédiates à mettre en route.
Là par contre, je persistes à ne pas être d'accord (cf plus bas). Mais bon, ce n'est pas très important, donc passons !-)
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 !-)
Des dizaines de secondes pour télécharger les ressources et rendre une page, ça arrive facilement !
Ca arrive hélas de plus en plus facilement sur des site qui freezent le navigateur pendant plusieurs seconde. <mode="grognon"> Le plus souvent, le temps de charger tous les flashs et javascripts pourris nécessaire à l'invasion de publicité débile et de gadgets inutiles. </mode>
Concernant la part du traitement serveur et rendu, développeur j'ai plutôt l'habitude d'optimiser mes requetes et traitements. C'est bien pour ça que lisant autant de fois que les traitements serveurs ne représentent qu'une petite partie du temps d'affichage global je me pose des questions sur les raisons de cette affirmation très largement répandue.
Ok. Je suis développeur aussi, mais pas seulement pour du code coté serveur, et effectivement, pour des sites gourmands en ressources "externes" (js, css, images etc) et traitements côté client - ce qui est de plus en plus souvent le cas -, il est important de prendre en compte le temps nécessaire au chargement de ces ressources et au rendu final de la page - en d'autres termes, le temps qu'il faut au navigateur pour rendre effectivement la page une fois qu'il l'a reçue. Et là, même si effectivement certaines "bonnes pratiques" commencent à émerger, ce n'est pas forcément trivial, surtout si ce n'est pas pris en compte dès le début.
Pierre Goiffon a écrit :
Bruno Desthuilliers wrote:
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...
Je ne me suis pas exprimé clairement :
- pour le front-end on a un ensemble de bonnes pratiques et
d'optimisations claires et identifiées.
- les traitement serveur, il faut aller diagnostiquer, et une fois
compris les problèmes, intervenir
yeps...
C'est ce que je voulais dire par "bien plus simple" : les corrections
sur le front end seront les plus immédiates à mettre en route.
Là par contre, je persistes à ne pas être d'accord (cf plus bas). Mais
bon, ce n'est pas très important, donc passons !-)
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 !-)
Des dizaines de secondes pour télécharger les ressources et rendre une
page, ça arrive facilement !
Ca arrive hélas de plus en plus facilement sur des site qui freezent le
navigateur pendant plusieurs seconde. <mode="grognon"> Le plus souvent,
le temps de charger tous les flashs et javascripts pourris nécessaire à
l'invasion de publicité débile et de gadgets inutiles.
</mode>
Concernant la part du traitement serveur et rendu, développeur j'ai
plutôt l'habitude d'optimiser mes requetes et traitements. C'est bien
pour ça que lisant autant de fois que les traitements serveurs ne
représentent qu'une petite partie du temps d'affichage global je me pose
des questions sur les raisons de cette affirmation très largement répandue.
Ok. Je suis développeur aussi, mais pas seulement pour du code coté
serveur, et effectivement, pour des sites gourmands en ressources
"externes" (js, css, images etc) et traitements côté client - ce qui est
de plus en plus souvent le cas -, il est important de prendre en compte
le temps nécessaire au chargement de ces ressources et au rendu final de
la page - en d'autres termes, le temps qu'il faut au navigateur pour
rendre effectivement la page une fois qu'il l'a reçue. Et là, même si
effectivement certaines "bonnes pratiques" commencent à émerger, ce
n'est pas forcément trivial, surtout si ce n'est pas pris en compte dès
le début.
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...
Je ne me suis pas exprimé clairement : - pour le front-end on a un ensemble de bonnes pratiques et d'optimisations claires et identifiées. - les traitement serveur, il faut aller diagnostiquer, et une fois compris les problèmes, intervenir
yeps...
C'est ce que je voulais dire par "bien plus simple" : les corrections sur le front end seront les plus immédiates à mettre en route.
Là par contre, je persistes à ne pas être d'accord (cf plus bas). Mais bon, ce n'est pas très important, donc passons !-)
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 !-)
Des dizaines de secondes pour télécharger les ressources et rendre une page, ça arrive facilement !
Ca arrive hélas de plus en plus facilement sur des site qui freezent le navigateur pendant plusieurs seconde. <mode="grognon"> Le plus souvent, le temps de charger tous les flashs et javascripts pourris nécessaire à l'invasion de publicité débile et de gadgets inutiles. </mode>
Concernant la part du traitement serveur et rendu, développeur j'ai plutôt l'habitude d'optimiser mes requetes et traitements. C'est bien pour ça que lisant autant de fois que les traitements serveurs ne représentent qu'une petite partie du temps d'affichage global je me pose des questions sur les raisons de cette affirmation très largement répandue.
Ok. Je suis développeur aussi, mais pas seulement pour du code coté serveur, et effectivement, pour des sites gourmands en ressources "externes" (js, css, images etc) et traitements côté client - ce qui est de plus en plus souvent le cas -, il est important de prendre en compte le temps nécessaire au chargement de ces ressources et au rendu final de la page - en d'autres termes, le temps qu'il faut au navigateur pour rendre effectivement la page une fois qu'il l'a reçue. Et là, même si effectivement certaines "bonnes pratiques" commencent à émerger, ce n'est pas forcément trivial, surtout si ce n'est pas pris en compte dès le début.
