Hola Gente,
Si a alguien le interesa puede usar esta plugin de firefox (desarrollado
por google) para medir esos tiempos:
http://code.google.com/speed/page-speed/docs/using.html
Y se baja desde aca: http://code.google.com/speed/page-speed/
Tambien hay varios tips interesantes por ahi tirados..
Saludos
On Nov 26, 2009 9:55pm, Diego Jancic <[email protected]> wrote:
jajaja... si, la verdad que me gusta tirar preguntas complicadas, las
aburridas las busco en internet o las dejo para que las haga otro :-)
Me olvide de responder las preguntas que hiciste, que son interesantes:
1 y 2: no son preguntas.
3. ¿Cuál es el costo de productividad?
Alto, altisimo en principio. Pero imagino que si la tecnica funciona
(ver update abajo), se puede simplicar bastante haciendo un mini
framework, y estandarizando una forma de trabajo... no lo veo tan
tragico si vale la pena.
4. ¿Cuál es la curva de aprendizaje?
Estamos hablando de performance, lo cual es completamente opuesto a
aprendizaje rapido. Ej: vos podes usar javascript basico para usar
AJAX, y asi mejorar la performance. Si no queres aprender tanto, usa
jQuery/Prototype, pero bancate bajar un script de algunos 50kb
antes... y si realmente no queres aprender ya ese metodo, usa cosas
como MS Ajax, que basicamente te dice:
"bien!, estas usando AJAX!, ahora todo funciona 10 veces mas lento
que cuando no sabias usarme"
Update: el metodo se esta cayendo un poco, porque lo que puedo llegar
a ganar por cache lo voy a perder con latencia y mas requests.
Necesito una respuesta a esto:
http://stackoverflow.com/questions/1806228/browser-support-of-multipart-responses
Otra desventaja que descubri, es que el iPhone soporta 25kb por
archivo en cache solamente... asi que no funcionaria ahi..
Saludos!
2009/11/26 Gustavo Azcona [email protected]>:
> Diego:
>
> Quizás el título de este thread debería ser "Tiempo de valientes" ;-)
> ~Gus
>
>
> El 26 de noviembre de 2009 12:42, Gustavo Azcona
[email protected]>
> escribió:
>>
>> Que interesante!
>>
>> ¿Cómo medir los tiempos?
>> Supongo que ya sabrás que FireBug te muestra bastantes datos acerca de
>> cada request. Por ejemplo, muestra los ms de:
>>
>> DNS Lookup
>> Connecting
>> Queuing
>> Waiting for response
>> Receiving data
>> DOM content loaded
>> Load
>>
>> Adjunto imagen.
>>
>> Quizás esta data sea suficiente (o no) para las mediciones que intentás
>> realizar. Si no es suficiente habría que buscar otros complementos
(nosé si
>> Fiddler muestra este tipo de información).
>>
>> ¿Qué hay para medir?
>> Bueno, como bien indicás te interesa medir diferentes páginas generadas
>> con diferentes técnicas (WebForms basico, WebForms tuneado, MVC, HTML +
>> Javascript, serialización XML vs JSON vs Freddy Krueger ;-)
>>
>> Es un lindo laburito que ojalá lo puedas hacer y compartir los
resultados.
>> Aquí pienso que YSLOW sería una buena regla de medición.
>>
>> Pero estoy pensando en las conclusiones y me surgen nuevas preguntas...
>>
>> Un rendering optimizado, es muy beneficioso por temas de accesibilidad
y
>> SEO. Sin embargo, no es definitorio para la performance.
>> Sabemos que en la performance intervienen muchos otros aspectos y no
solo
>> el rendering (cache, acceso a datos, compresion, minificacion, pocos
>> request, CDN, etc)
>> ¿Cuál es el costo de productividad?
>> ¿Cuál es la curva de aprendizaje?
>>
>> Aún así, creo que esa prueba que intentás hacer arrojará resultados
>> interesantes.
>>
>> Buena suerte! Estaremos pendientes.
>> Saludos, Gus
>>
>> El 24 de noviembre de 2009 23:51, Diego Jancic [email protected]>
>> escribió:
>>>
>>> Hola gente!,
>>> Tengo ganas de hacer un "proof of concept" de un metodo para mostrar
>>> contenido en web (en general, no solo .net), de forma que sea lo mejor
>>> en cuanto a performance... Con mostrar contenido me refiero lo que
>>> pasa desde el primer byte de respuesta de un servidor HTTP, hasta que
>>> se muestra el contenido al cliente de forma completa.
>>> Hay varias formas de hacerlo, pero me surge la duda de como puedo
>>> realmente medir el metodo mas rapido en terminos de rendering del
>>> browser..
>>>
>>> Doy un ejemplo simple de lo que quiero medir. Supongamos que hay una
>>> pagina complicada que involucra muchos elementos (a nivel DOM), por lo
>>> que tengo varias formas diferentes de hacerlo:
>>> ** Voy a suponer que la pagina no puede tener cache, pero cualquier js
>>> o css si... Ademas la pagina tiene ~20% de contenido dinamico y todo
>>> el resto es mas o menos estatico (estimo que no va a cambiar en menos
>>> de 20 minutos).
>>>
>>> 1- Generar el layout basado en divs y enviar ese contenido al cliente.
>>> 2- idem anterior haciendo flushes intermedios
>>> 3- idem 1 pero usando tablas... puag! :P
>>> 4- Generar los datos, y solo los datos, que necesito para mostrar
>>> serializados en JSON, XML o lo que sea y con un js cacheado en el
>>> cliente hago toda la parte compleja de contruir el DOM.
>>> 5- Idem anterior pero creando el contenido con innerHTML (es mas
>>> rapido que el metodo anterior segun lei)
>>>
>>> La cantidad de requests hechos, la latencia, el encolamiento de los
>>> requests, etc es todo medible... por eso la pregunta especificamente a
>>> medir el tiempo de render del browser.
>>>
>>>
>>> Gracias!,
>>> Diego
>>>
>>
>>
>>
>> --
>> Gustavo Azcona
>
>
>
> --
> Gustavo Azcona
>
