FCP y DCL en Pagespeed Insights. Qué son y cómo usar estas métricas de tiempo de carga

Desde enero de 2018, Google ofrece dos nuevas métricas o indicadores de tiempo de carga en su herramienta Pagespeed Insights.

Estas métricas son First Contentful Paint (FCP) y DOM Content Loaded (DCL). En este vídeo-post te voy a explicar de dónde proceden y qué mide cada una, cuándo las muestra Pagespeed Insights (y cuándo no) y cómo usarlas para saber si debes optimizar tu tiempo de carga.

¿De dónde vienen estos datos?

Del Chrome User Experience Report o Informe de Experiencia de Usuario de Chrome.

Es una base de datos pública donde se van agregando datos de uso real de páginas cargadas con Chrome en diversos dispositivos.

Si usas Chrome, los datos de tiempo de carga de las páginas por las que navegas pueden agregarse a este informe si no indicas expresamente que no quieres que se usen. Tus datos se añadirán a la base de datos de forma totalmente anónima, eso sí.

Esta base de datos no es completa. Es decir, no están incluidas todas las páginas del mundo. De hecho a finales de 2017 sólo contenía datos de más o menos un millón de páginas web, lo cual es muy poco comparado con la totalidad de la web. Por eso al analizar algunas páginas en Pagespeed Insights no recibes ningún dato de este informe, porque no se encuentra dentro de la base de datos de Chrome UX Report.

¿Cuáles son los criterios para que una página web esté incluida entre ese millón (aproximadamente) de páginas para los que el Chrome User Experience Report da datos públicos?

No lo sabemos con seguridad, porque Google no lo ha hecho público, pero parece estar bastante relacionado con el volumen de tráfico. Por lo que he podido experimentar, las páginas con más tráfico orgánico tienen bastante más posibilidades de mostrar datos que las que tienen poco tráfico.

Ojo, si consultas dos páginas cuyo tráfico conoces perfectamente, te puedes encontrar con que la de menor tráfico sí arroja datos de FCP / DCL en Pagespeed Insights, mientras que la de mayor tráfico no. Pero en general

Incluso es posible que Pagespeed Insights muestre estos datos para algunas páginas sólo en desktop y no en móvil (como verás en el ejemplo que pongo en el vídeo), y viceversa.

¿Cómo saber mis valores de FCP y DCL si Pagespeed no me las muestra?

Hay una forma: con una herramienta gratuita desarrollada por Google llamada Lighthouse, que podemos ejecutar como una extensión de Chrome.

En un próximo vídeo-post voy a explicar cómo funciona esta herramienta y cómo hacer una auditoría muy potente de WPO con ella, pero por ahora basta saber que para cualquier página web del mundo, Lighthouse te mostrará datos de First Contentful Paint (simulando un móvil de gama media con conexión 3G) e incluso te dará el tamaño total de tu DOM y recomendaciones para hacer ambos tiempos de carga más bajos.

First Contentful Paint: ¿qué es?

Vamos con la primera métrica. First Contentful Paint, que traducido sería algo como “primera impresión, o primera mano de pintura, con contenido de la página”.

Qué es: FCL es el tiempo que transcurre desde el momento en el que solicitas la carga de una página hasta el momento en que aparece en la pantalla de tu navegador el primer fragmento de contenido que viene del código de la nueva página.

Este fragmento de contenido puede ser texto, una imagen, un icono, lo que importa es que sea “contenido”, no simplemente un color de fondo.

Mira en el vídeo el ejemplo de una página de mi blog. En mi caso aparecen casi al mismo tiempo el logo, la barra superior del menú, algún texto y alguna imagen…

Importante: el FCP que te muestra Pagespeed Insights es la mediana de todos los FCPs para tu página que hay registrados en el Chrome User Experience Report.

Es decir, imagina que hay 9 tiempos diferentes guardados para el FCP de tu página, pues la que te mostrará será la quinta más rápida, o quinta más lenta, es lo mismo, la del medio. Eso es la mediana (no confundir con una media aritmética).

Por eso, si estás con el cronómetro a ver cuando tu página empieza a “pintar” contenido, puede que te salga un tiempo más bajo. Esto puede ser porque tu conexión es mejor, o tu navegador va más rápido, pero la mediana que hay en el Chrome UX Report es un tiempo más alto.

Si tu mediana, comparada con la del resto de páginas que hay en Chrome UX Report está en la media (tercio medio de toda la muestra), tu puntuación (Average) saldrá en naranja. Si está en el tercio más rápido, saldrá en verde; y si está en el 33% más lento, saldrá en rojo.

¿Y qué quiere decir esa escala de colores que hay más abajo? Esto es una representación de como le carga tu página a todos los usuarios cuyos datos están registrados. En verde, tienes el porcentaje de usuarios para los que tu FCP es rápido. En naranja, el porcentaje para los que tu FCP es normal, y en rojo el porcentaje para los que tu FCP es lento.

¿Es lo mismo FCP que tiempo de respuesta del servidor?

No son lo mismo, y de hecho FCP siempre es mayor, ya que para que se pinte algo en el navegador primero debe responder tu servidor, y luego ya entra el tiempo que tarda el navegador en analizar el HTMl de la página e imprimir un primer contenido.

FCP: ¿cómo mejorarlo?

Hay que dividirlo en sus partes. Lo primero es la respuesta del servidor. Si tu servidor responde lento, siempre tienes un handicap para llegar a un buen FCP, por lo que lo primero sería mejorar la respuesta del servidor (en el link puedes leer mi post sobre el tema).

La otra parte es cómo está estructurado tu código, si hay muchos scripts o llamadas en el head de la página que se ejecutan antes que el contenido que de verdad va a ver el usuario, y si merece la pena retrasarlas (defer o async) o incluso eliminarlas del código de tu página. Esto es algo que tocaré en el detalle en el post sobre Lighthouse, así que atentos.

La conclusión es que hay que bajar la respuesta del servidor y adelantar en tu código el momento en el que empieza a mostrarse el contenido de la página.

DOM content loaded: ¿qué es?

Es el tiempo que transcurre desde que el usuario solicita la carga de una página, hasta el momento en el que se ha cargado completamente el html de una página, sin esperar a la carga de archivos CSS, imágenes o iframes (pero sí a todos aquellos scripts que se carguen de forma asíncrona).

¿Por qué se llama DOM Content Loaded? El DOM es una estructura jerárquica, en forma de árbol, en donde se representan todo el contenido y todas las llamadas que deben cargarse dentro de una página, y en qué orden. Cuanto más arriba esté una llamada dentro del DOM, antes la ejecutará el navegador.

DCL: ¿cómo mejorarlo?

Pues la respuesta rápida es haciendo el DOM más sencillo o más compacto, con menos niveles o “nodes”, que es como se llama cada una de las unidades del DOM.

Lo que debes hacer es identificar si hay fragmentos de código que no necesitas cargar, porque no se van a mostrar o porque no aportan nada importante para tu página, y eliminarlos.

Por supuesto, habrá ciertas funcionalidades de la página de las que no podremos prescindir, por lo tanto no podremos eliminar de nuestro código los scripts que se encargan de llamar dichas funciones. En ese caso, tenemos la posibilidad de cargar de forma asíncrona estos scripts, tal y como explicaba para reducir el tiempo de FCP.

Al cargar scripts de forma asíncrona, la carga del HTML no se interrumpe mientras se ejecutan estos scripts, sino que sigue su curso hasta el final del DOM, y los scripts se cargan al final. Pero ojo, porque según cómo esté programada tu página, ciertos scripts no podrán ser pasados a carga asíncrona, ya que afectarían al buen funcionamiento de la página.

Por ejemplo, si hay javascripts que para ejecutarse dependen de jQuery, eso quiere decirse que el jQuery debe cargarse antes de que se puedan cargar estos scripts. Por tanto, si aplicas async a TODOS los scripts, tu página no funcionará bien, o no se verá bien mientras se está cargando.

De nuevo, explicaré todo esto más en detalle en mi próximo vídeo-post sobre Lighthouse.

¿En qué se diferencian FCP y DCL? ¿Cuál es más importante optimizar?

FCP se parece más a un sprint o una carrera de 100 metros, mientras que DCL es más una carrera de medio fondo. Es perfectamente posible que entre dos páginas, una gane al sprint (FCP), mientras que la otra gane al medio fondo (DCL).

¿Cuál debo optimizar primero? Hombre, lo ideal es optimizar ambas, pero si tuviera recursos limitados y tuviera que elegir una, siempre actuaría sobre FCP, por lo que he dicho de ese efecto psicológico que tiene en el usuario que la página empiece a cargarse y ya pueda empezar a leer.

Además, como el tiempo de FCP va incluido en DCL, al bajar FCP, lógicamente baja también DCL, mientras que es posible hacer cambios que sólo tengan incidencia en DCL, pero no en FCP.

Por todo ello, para mí la prioridad sería FCP. Pero eso no quiere olvidarse de DCL y del tiempo total de carga de una página. Aunque contase con recursos limitados, primero trabajaría FCP, y una vez logrado un buen tiempo de FCP, pasaría a trabajar en DCL.

¿En qué se diferencian FCP y DCL de las tradicionales puntuaciones que da Pagespeed Insights? ¿Cuál es más importante?

Muy sencillo. Las puntuaciones (el típico 100/100 al que todo el mundo aspira) no medían la velocidad de carga como tal, sino que representan hasta qué punto se cumplen una serie de criterios subjetivos definidos por Google.

Estos criterios están relacionados en general con la velocidad de carga, en el sentido de que si una página por ejemplo aplica el minificado suele ser más rápida que otra que no lo haga, pero no se puede decir que una página que lo cumpla casi todo y llegue a un 90/90 sea siempre más rápida en cargar que otra que incumple dos o tres criterios y se queda en un 80/80.

Y eso, por no decir que Google cambia con el tiempo el peso que da en la puntuación a ciertos criterios, de manera que es perfectamente posible que una página que no ha cambiado en nada recibiese una puntuación de 90 hace 6 meses, y ahora sólo 75.

Frente a esto, FCP y DCL son métricas que sí miden la velocidad de carga de forma objetiva, y están basadas en un criterio que no cambia nunca. Por lo tanto, sí sirven para comparar la velocidad de una página frente a otra.

Extra: Consulta todos los resultados de un mismo sitio con el comando origin:

Google permite que, en lugar de consultar el FCP y DCL de un sitio página a página, lo hagamos para todo el dominio, o al menos para todas las páginas de ese dominio que aparecen en el Chrome UX Report.

Para hacer esto, sólo debes introducir, en lugar de la url, lo siguiente:

Origin:midominio.com

Sustituyendo midominio.com por el dominio que quieras consultar.

Así podrás ver, en conjunto, qué tiempos de carga está arrojando tu sitio para usuarios reales de Google Chrome.

Al usar el comando origin:, las puntuaciones de Pagespeed Insights desaparecer, y lo único que recibirás es datos de FCP y DCL, si es que aparecen en el Chrome UX Report.

Conclusión

Con estas nuevas métricas, Google va dándonos datos que, aunque a priori son más difíciles de interpretar, están más relacionados con el tiempo de carga real de nuestras páginas para usuarios reales. Como todo lo que nos da gratis Google, debemos aprovecharlo para mejorar el rendimiento de nuestro sitio.

Aunque la velocidad de carga no fuera un factor de posicionamiento en Google, que lo es, debemos tratar de hacer nuestras páginas más rápidas, tanto en tiempo de respuesta del servidor, como en FCP y DCL, porque mejoran la experiencia del usuario, hacen más probable que el usuario navegue más tiempo e incluso vuelva en un futuro a nuestro sitio y hace que aumenten las conversiones, fin último de publicar contenido y hacer SEO.

Hasta para Adwords, la velocidad de carga cuenta mucho y puede mejora la puntuación de calidad de tus anuncios. Tanto es así que hace poco Google ha incluido una columna con tiempo de carga de nuestras landing pages en anuncios de Adwords.

Así que no necesitas más razones. Empieza a familiarizarte con estas métricas, y no te quedes con el 100/100, que no es ahí donde está la miga. Los datos de carga de usuarios reales son los que mandan.