Wextensible

Herramientas en línea para medir la velocidad de carga de una web

Page Speed on-line
Pagespeed Insights para www.wextensible.comImagen no disponible
PageSpeed Insights es un sitio de Google Developers para medir la velocidad de carga. La página inicial de este sitio consigue ahora 100/100.

Optimizar la velocidad de carga de una página web es una tarea que requiere medir esa característica. No podemos optimizar si no medimos. Hay algunas herramientas que podemos usar para esto. En la serie de imágenes adjuntas he puesto algunas capturas de pantalla de tests pasados a la página inicial de este sitio. La primera es del sitio PageSpeed Insights, observándose que con la última actualización de este sitio del 27 de Enero de 2014 he conseguido un 100/100 de puntuación.

Esta forma de medir la velocidad de carga podemos considerarla como una medición indirecta, en el sentido de que el test chequea unas reglas de optimización que deben seguirse con el objeto de que la página esté mejor preparada para cargar más rápidamente. PageSpeed Insights testea para móviles y para ordenadores al mismo tiempo, ofreciendo listas de reglas con explicaciones y enlaces a información adicional. He usado esta herramienta desde que empecé a optimizar este sitio, especialmente por la documentación de Google Developers PageSpeed. En la parte de Best Practices-Articles podemos encontrar un montón de información relacionada. También ahí se encuentran una lista de reglas para optimizar la velocidad de carga.

La siguiente imagen (ver original) es una captura del sitio Web Page Test, que ofrece varias clases de mediciones. Una de ellas chequea una lista de reglas como el tiempo para recibir el primer byte o la compresión de los recursos. La puntuación se presenta con las letras "A" a la "F". Con la página inicial de este sitio consigo pasar 5 de esos test, pero obtengo una una "F" para los JPEG's progresivos, técnica que no estoy usando. Además tampoco hago uso de un CDN (Content Delivery Network) y por lo tanto no puede ser objeto del test.

Web Page Test ofrece también mediciones directas, como se observa en la tercera imagen de la serie. Los números presentados son los del test de la página inicial de este sitio. Contando desde el inicio de la petición, con load time medimos el tiempo de carga de la página, first byte sería el tiempo hasta recibir el primer byte de la respuesta y start render el momento cuando el navegador empezó a renderizar el documento. Además hace dos tests, uno en primera vista con caché vacía y cookies borradas. Luego repite la acción sin borrar esos recursos. Una medida que también aparece en la imagen es speed index o índice de velocidad de carga de una página web. Se define como el promedio de tiempo en el cual una parte visible de la página es presentada en pantalla. Se expresa en milisegundos y depende del tamaño del viewport. Es un índice que nos puede servir para comparar entre antes y después de aplicar mejoras de optimización.

Algo importante de Web Page Test es que podemos configurar el tipo de conexión para la prueba. La prueba de antes es usando una conexión de cable 5/1 Mbps, con RTT de 28 ms. Podemos elegir por ejemplo una conexión 3G con RTT 300ms. Vea una imagen original de una prueba con la página inicial de este sitio Wextensible. El Speed Index ahora es de 1848ms, cuando con cable estaba por debajo de un segundo (700ms).

La evolución temporal de la carga se muestra en unos gráficos de carga o waterfall. Ubica en una gráfica temporal los puntos de medición señalados antes y otros más. Una lista de comprobación o checklist detalla el cumplimiento de las reglas de optimización por cada uno de los recursos. El sitio además tiene una parte para documentación e incluso un foro. En definitiva, una herramienta potente para optimizar la velocidad de carga de nuestro sitio.

En la cuarta imagen de la serie vemos el resultado del test pasado en el sitio Pingdom Website Speed Test. También consigo un 100/100 para la página inicial. Ofrece otros resultados como el waterfall, puntuación de reglas (Performance Grade) e incluso un histórico de pruebas realizadas.

Herramientas en los navegadores para medir la velocidad de carga de una web

Page Speed Chrome
Pagespeed Insights en navegador ChromeImagen no disponible
PageSpeed for Chrome es una extensión del navegador Chrome. La página inicial de este sitio cumple las 27 reglas propuestas.

Las imágenes de esta serie son herramientas del navegador Chrome. La primera es de la versión para navegador de Page Speed Insights (ver imagen completa). Aunque en versiones anteriores incorporaba puntuación, últimamente no aparece. En todo caso lo importante es el conjunto de 27 reglas que hemos de conseguir pasar. Esta herramienta hay que instalarla como una extensión, descargándola del sitio de PageSpeed Insights. La ventaja de usar esto en el navegador es que podemos pasar el test a dominios localhost, cosa que no podemos hacer con PageSpeed Insights en el sitio web.

Puntuación 100 en PageSpeed Insights

Julio 2014: Aclaración sobre puntuación en extensión PageSpeed Insights para Chrome

Dije antes que esta extensión no incorporaba puntuación, pero esto no es cierto porque viene desactivada por defecto. En la configuración de la extensión podemos volver a activarla. Vea en la imagen adjunta como la página principal de este sitio ya alcanza una puntuación 100/100.

La segunda imagen es de la herramienta Audits integrada en el navegador Chrome (ver imagen completa). Se ejecuta el test al uso de la red y al rendimiento de la página web, no sólo relacionado con la carga de la página. El test de la página inicial de este sitio muestra dos incidencias. La primera titulada con Leverage browser caching se refiere a que doce recursos tienen una corta duración de caché. Esto no supone un punto negativo en las reglas de optimización de velocidad de carga, pero este control considera que esas duraciones de caché deberían ser superiores. Otra incidencia que controla Audits es el número de reglas CSS que no se están usando. Ambos puntos requieren una exposición aparte de este tema.

Chrome y otros navegadores disponen también de la visualización del gráfico de carga o waterfall. En Chrome está en la pestaña Networks del que puede ver una captura de pantalla en la tercera imagen de la serie (ver la imagen completa). La línea vertical de color azul indica el momento en el que se activó el evento DOMContentLoaded. La línea roja indica la activación del evento Load. Se echa de menos otros eventos como cuando empieza a renderizar y pintar, tal como aparece en el gráfico de carga de Web Page Test. Pero dado que podemos usar esa herramienta de Chrome en localhost, es una de las que tendremos más a mano para hacer un primer seguimiento de las medidas DOMContentLoaded y Load mientras desarrollamos la página y antes de subirla al sitio en producción.

Desactiva Caché con Developers Tools abierto

No debemos olvidar que en todas las pruebas realizadas con el Devoloper Tools de Chrome relacionadas con la velocidad de carga hay que desactivar la caché. En la configuración podemos activar esa opción que se llevará a cabo mientras la herramienta esté abierta. Es lógico pensar que la peor situación que puede darse es con la caché desactivada, puesto que el navegador tendrá siempre que leer recursos directamente desde el servidor.

El Timeline de las herramientas de desarrollo del navegador Chrome

Reconozco que tratar con mediciones directas es díficil. Los gráficos de carga o waterfall y las mediciones de los distintos instrumentos no aparentan comportarse igual. La gran cantidad de parámetros que intervienen hace díficil homogeneizar un conjunto de pruebas. Además hay que entender bastante de redes, protocolo TCP/IP, comportamientos de las conexiones y un largo etcétera que nos harán desistir. Por eso es importante primero centrarse en realizar mediciones indirectas relativas al cumplimiento de reglas de optimización. Y en cuanto a mediciones directas, si acaso queremos atrevernos con ellas, podemos intentar optimizar el primer layout y pintado de la página con Web Page Test o el Timeline de Chrome, como veremos en este apartado.

Timeline en Chrome
Timeline en navegador ChromeImagen no disponible
En Timeline de Chrome podemos grabar todo lo que está sucediendo durante la carga de la página.

La herramienta Timeline en el navegador Chrome muestra una línea de tiempo grabando todo lo que está sucediendo. Puede ver esta imagen original de una grabación de la carga de la página inicial de este sitio. Para hacer esta grabación pulsaremos el botón circular de color gris con el ratón y luego refrescaremos la página con F5 sin mover el ratón. Dejaremos que aparezca el evento Load y detendremos la grabación. O bien podemos utilizar Ctrl+E para iniciar la grabación, Ctrl+R para refrescar la página, esperar a que cargue y luego nuevamente Ctrl+E para finalizar la grabación (puede consultar las teclas de método abreviado en Chrome). No podemos mover el ratón por la pantalla pues la herramienta grabará ese desplazamiento pintando ese movimiento. Es conveniente desactivar todas las extensiones, cerrar pestañas adicionales y, en definitiva, tener la menor cantidad de procesos activos para que no interfieran en la grabación.

El momento cuando se ejecuta el primer layout y pintado es el dato que ahora nos interesa. Del primer layout podemos ver una captura parcial en la segunda imagen de esta serie (ver imagen original), se produce en este ejemplo después del DOMContentLoaded y antes del Load. La tarea del layout se inicia cuando el navegador ya ha renderizado el documento o, al menos, una parte importante del mismo, pero los elementos no tienen posiciones ni tamaños. Calcular estos valores es precisamente hacer el layout o reflow de la página. Hemos de lograr que el primer layout se produzca cuanto antes, pues es una tarea previa al primer pintado de la página. En esta prueba el DOM se carga y renderiza a los 640ms y el layout empieza a los 848ms.

Si el HTML de la página no es muy largo, el primer layout/pintado aparecerá normalmente después del DOMContentLoaded. Pero si la página tiene mucho HTML entonces el navegador puede adelantar un primer layout y pintado con una parte recibida que considere suficiente para ser representada en pantalla. En esos casos el primer layout/pintado puede aparecer antes del DOMContentLoaded, aunque cuando éste se produzca volverá a generar otro layout/pintado. Por eso es importante evitar páginas con mucho HTML, es decir, con un número excesivo de elementos.

Seguidamente se produce la medición del primer Paint, es decir, el primer pintado de la página, que se inicia a los 861ms, algo después del layout. Esta medición es importante porque entra en juego el caracter subjetivo de la velocidad de carga. Tanto el DOMContentLoaded como el Load no son mediciones indicativas de la velocidad de carga apreciada por el usuario. Es indudable que cuanto antes se cargue y renderize el DOM también antes empezará a pintar en pantalla. Pero puede suceder que tengamos una baja medición del DOMContentLoaded y sin embargo algo está bloqueando el primer pintado. Por lo tanto lo que interesa es el momento cuando empezamos a pintar, de tal forma que el usuario podrá sentir o no un mayor o menor grado de sensación de velocidad si este hecho se produce antes o más tarde. Este objetivo forma parte también del concepto de índice de velocidad (speed index) del medidor Web Page Test que comentamos en el primer apartado.

Podemos plantearnos como objetivo un límite superior para el primer pintado de la página que esté por debajo de 1 segundo. Se basa en el efecto psicológico que estableció Nielsen en Powers of 10: Time Scales in User Experience:

  1. No más de 0.1 segundo si se quiere que los usuarios sientan que sus acciones están causando que algo suceda en la pantalla.
  2. No más de 1 segundo en la carga de una página para que el usuario sienta que está navegando sin retrasos. El usuario nota el corto retraso pero aún puede permanecer atento hasta la carga de la página.
  3. Después de 1 segundo el usuario empieza a impancientarse. En torno a los 10 segundos el usuario tiende a abandonar la página.

Hay que tener en cuenta que las pruebas debemos hacerlas siempre con el mismo ordenador y navegador para tratar de reproducir las mismas condiciones. Los navegadores se apoyan en los sistemas de conexión de los ordenadores, por lo que las medidas podrán diferir según como esté configurada la conexión. Las medidas se ven afectadas por cosas como el cacheado de DNS por el sistema operativo, las pre-conexiones TCP que puede hacer el navegador, la forma en que el servidor negocia la conexión o incluso la configuración del router ADSL y el propio ISP que pueden introducir cambios significativos en esas mediciones. En la velocidad de carga de una página el rendimiento está más relacionado con ese conjunto de configuraciones que con el ancho de banda de la línea. Además las mediciones expuestas en este tema son para conexiones ADSL, pues otra cosa son conexiones móviles. Esa optimización debería también estar por debajo de un segundo, pero eso es otra historia.

También podemos hacer las pruebas en localhost. Si el layout y primer pintado no están bloqueados o influenciados por la carga de otros recursos (CSS o JS por ejemplo), podemos realizar mediciones de estos eventos en localhost pues la duración de estas tareas está determinada única y exclusivamente por el navegador. Por otro lado si cargamos una página con localhost y obtenemos un DOMContentLoaded de unos 150 ms por ejemplo y luego cargamos esa página desde el servidor en producción y ese valor es de unos 650 ms, podemos estimar esa diferencia de 500 ms como una constante. Así cualquier medición del layout o paint en localhost sabemos que tendrá un coste añadido de 500 ms en el sitio en producción.

Se trata en todo caso de hacer una serie de tests y obtener ese objetivo en la mayor parte de ellos tratando de mantener el mismo conjunto de configuraciones de la conexión. Hay que tener en cuenta que entre dos test consecutivos pueden manifestarse variaciones de centenares de milisegundos debido a causas relacionadas con la red. Cosas como el tráfico del servidor en ese momento u operaciones que esté ejecutando el ordenador o navegador no relacionadas con la carga de la página pueden incrementar el tiempo de la prueba. Pero si hacemos por ejemplo 10 pruebas y en 8 obtenemos un resultado por debajo de un segundo, podemos estimar que esto es cierto con un 80% de probabilidad. Es algo simplista afirmar eso con tan pocos tests, pero en todo caso siempre podemos hacer una serie de pruebas más extensa.

Formato de archivos HAR: HTTP Archive

Waterfall o gráfico de carga

Un aspecto tangencial a este tema es el formato de datos HAR que se refiere a un HTTP Archive. Es un archivo de texto con datos en una estructura JSON que guarda el gráfico de carga y otros datos representables del waterfall. En el sitio igvita.com puedes ver más detalles sobre esto.

Tanto Web Page Test como Pingdom ofrecen la posibilidad de descargar el gráfico de carga o waterfall en esa estructura HAR. Con un visor de HAR podemos abrir estos JSON de datos de los tests que pasé a la página inicial de este sitio. Por ejemplo estos son los HAR de Web Page Test, Web Page Test móvil, Pingdom y Waterfall de Chorme. Puede copiar el texto y pegarlo en el visor HAR indicado. Para copiar un texto apunte con el ratón en el inicio del texto, pulse luego la tecla SHIFT manteniéndola pulsada y apunte con el ratón en el final del texto hasta donde quiera copiar.

También podemos guardar un Timeline en el navegador Chrome como un archivo de texto JSON y cargarlo en otro momento en esa pestaña. Este archivo chrome-timeline.json es la captura de la grabación señalada en este apartado. Puede guardarlo como archivo y cargarlo en una pestaña Timeline de un navegador Chrome.