Como ver donde demora una pagina WEB.

Cuando desarrollamos con GeneXus, trabajamos a un nivel alto de abstracción, que nos libera de estar pensando en muchos detalles técnicos que permite tener mucha mayor productividad.
Esto trae como consecuencia, que no somos del todo conscientes de todo las tareas que se realizan en la ejecución de las aplicaciones por nosotros desarrolladas.

Me preguntaron varios ( dos personas diferentes, ya son varios, no? ) como hacia para saber donde estaba demorando una pagina WEB y como podian hacer para mejorar su performance.

No tengo una metodología demasiado definida, ni me considero un especialista en el tema, pero cuento que es lo que uso, con la esperanza que les pueda servir a alguien mas.

Lo que me resulta mas facil, es probar la aplicacion con Chrome y usar la extension
Chrome Apps & Extension Developer Tool  que tiene algo mas de informacion que las herramientas que vienen que Chrome en forma nativa, pero tampoco hace la diferencia.

Cantidad de request

Después ejecuto la aplicación WEB que quiero optimizar, con la ventana de dicha herramienta activada y voy a la pestaña NETWORK y deshabilito el cache, para tener claro que es la peor demora que pueda tener un usuario al ejecutar por primera vez mi aplicación. 

Ahi miro la cantidad de request que se realizan, el tiempo que demora en cargarlo y la cantidad de KB que se transfieren, con el cache deshabilitado. Esto incluye todos los datos de la pagina, mas todo el javascript usado y tambien imagenes. Para tener cosas comparables, conviene probar siempre con los mismos datos. 

Tambien hay que mirar la Consola, (queda abajo) para ver si no hay errores o warnings de javascript en la pagina, que puedan influir en la ejecucion. 

Cantidad de KB transferidos (CACHE)

El siguiente paso, es tratar que se transfiera menos KB en la pagina, para lo cual hago una ejecucion con el Cache HABILITADO. Esto me va a permitir ver que cosas se esta cacheando correctamente y cuales no. 

En este caso, puedo ordenar por el Status y no preocuparme (por el momento) por los que son 304 (Not modified) , pues significa que van a ser tomados del cache, por lo que solamente van a demorar la primera vez que se ejecute la pagina, pero luego no van a tener problemas. 

Viendo los que tienen status 200 (OK), y que no tengan el (from cache) en size, puedo ver que tengo:

• El request de la aplicacion (esta bien que no se cachee pues es contenido dinamico)
• El CSS del menu que uso (se podria cachear, pues no cambia)
• GXResourceProvider.aspx... es el que traduce de codigos de imagenes a URL para cargarlas (dependen del idioma y del Theme que pueden cambiar). 
• La lalmada a collect... que es el Google Analytics
• El Favicon.ico de la pagina (se tendria que cachear, pero es chiquito y no joroba mucho). 

Una vez visto esto, trato de mejorar el cache del contenido, modificando el servidor WEB o algunas veces el codigo. 

Cantidad de KB transferidos (Size)

Despues veo si se puede achicar la cantidad de bytes que se transmiten. 

Para lograr esto, ordeno por Size en forma descendente, con el cache deshabilitado. 

Para aquellos que tengo dudas, trato de ver mas detalle, dando un click en el renglon, por ejemplo, me llama la atencion el bootstrap.css, y al mirarlo veo que si bien se esta tranmitiendo comprimido (en el header usa gzip) se podria pasar por un  CSS Minifier y pasa de 145 a 118 KB, con un resultado equivalente. 

Muchas veces al mirar este tipo de trafico, se descubre request innecesarios que pueden evitarse, por ejemplo, y muchas veces no sabemos ni que estaban. 

Velocidad de los Request. 

Cuando dejamos solo lo requests necesarios, lo que hago es ver que es lo que está demorando mas, ordenando los request de la pagina por la columna TIME. 

En esa pantalla veo cuales son los request que mas demoran y si hay alguno optimizable. 

Muchas veces pueden achicarse imagenes grandes, cambiarse referencias a javascript y tambien mejorar nuestros programas. 

Es comun por ejemplo que en transacciones podamos ver que determinadas llamadas ajax (relacionadas con validaciones o eventos que se disparan al moverse entre campos, sean las causantes de las demoras). 

Prueba de Aplicacion con diferentes resoluciones y ancho de banda. 

Otra cosa que me gusta probar, es como va a ser el acceso a la pagina, para usuarios que no tengan gran ancho de banda. Las herramientas de Chrome, permite simular desde WiFi (30Mbps) a GPRS (50Kb)

También permite cambiar la resolución de la pantalla y verla con zoom. Da una idea de que experiencia de usuario van a tener aquellos que no tengan la misma configuración que la nuestra.

Resumiendo,  es relativamente facil, detectar algunas demoras en programas y a veces tambien es facil solucionarlas. Con solo esta herramienta de Chrome se pueden ver muchas mas cosas, pero las explicadas en el post se puede optimizar lo mas obvio.