First Contentful Paint

¿Qué es el First Contentful Paint (FCP)?

El First Contentful Paint (FCP) es una forma de medir la velocidad de carga de la página. No puedes resumir la velocidad de la página como un punto en el tiempo, en realidad hay varios momentos durante el proceso de carga donde un visitante podría experimentar el sitio como cargando rápido o lento. El FCP mide la diferencia de tiempo entre solicitar la página y cuando el primer contenido significativo se renderiza en la pantalla por primera vez.

¿Qué te dice eso exactamente? Te dice que el FCP es principalmente una "métrica centrada en el usuario" porque dice algo sobre la velocidad de carga que experimenta un visitante. Dice algo sobre la user experience. En el momento del FCP, puedes estar seguro de que un visitante realmente ve "algo" en la pantalla.

Desglosemos las palabras: "First", "Contentful" y "Paint".

1. First:  Por First, por supuesto, nos referimos al primer momento exacto en que algo sustancial aparece en tu navegador.
2. Contentful: Con contentful nos referimos a un elemento HTML con contenido. Así que no un elemento de diseño como un elemento en blanco o color de fondo, sino más bien algo de texto, una imagen (incluyendo imagen de fondo), SVG o canvas.
   
3. Paint: Paint significa (más o menos) que el navegador está listo para poner algo en la pantalla. Esto parece simple pero en realidad es la tarea más complicada del navegador. Para poner algo en la pantalla, un navegador debe estar listo para calcular todas las características de un elemento. A continuación se muestra un ejemplo del proceso de renderizado que se requiere antes de que se pueda agregar algo en la pantalla.

¿Qué es una buena puntuación de First Contentful Paint?

Una buena puntuación de FCP es cualquier cosa por debajo de 0 y 1.8 segundos. Si tu puntuación de FCP está entre 1.8 y 3 segundos necesita mejora. Cualquier puntuación de FCP por encima de 3 segundos se considera pobre. Para aprobar los Core Web Vitals para el Largest Contentful Paint al menos el 75% de tus visitantes necesitan tener una puntuación FCP "buena".

Como siempre con los Core Web Vitals, una puntuación de First Contentful Paint más rápida es mejor que una más grande. 

¿Cómo mides tu First Contentful Paint (FCP)?

El FCP es medido por Google recopilando datos de usuarios reales. Esos datos se almacenan en el conjunto de datos CrUX. Esos datos están disponibles públicamente a través de la API CrUX o Google BigQuery. El FCP también se puede medir a través de las llamadas pruebas de laboratorio. La prueba de laboratorio más común se llama Lighthouse.

Obteniendo el First Contentful Paint del conjunto de datos CrUX

El First Contentful Paint  se puede leer del conjunto de datos CrUX a través de pagespeed.web.dev, la API CrUX, o a través de google BigQuery.

Midiendo el First Contentful Paint a través de Real User Monitoring (RUM) 

RUM Tracking significa Real User Monitoring. Con Real User Monitoring puedes rastrear el First Contentful Paint a través de interacciones de usuarios reales. La ventaja de RUM Tracking es que no tienes que esperar 28 días para obtener datos frescos y los datos pueden ser consultados y analizados con mucho mayor detalle.

Midiendo el FCP en Lighthouse

1. Abre la página – en Chrome – cuyo FCP quieres medir. Asegúrate de hacer esto en incógnito para que los plugins no te molesten y posiblemente ralenticen el FCP de tu página.
2. Haz clic derecho en la página y selecciona Inspeccionar elemento. De esta manera abres la consola de desarrollador de Chrome.
3. En la parte superior de la consola, verás la pestaña Lighthouse. Haz clic en ella. Luego bajo Categorías, elige Performance (deja las otras en blanco) y elige Móvil bajo Dispositivo.
4. Ahora haz clic en Generar informe. Lighthouse creará un informe de velocidad de tu página. En la esquina superior izquierda del informe, verás cuál es el FCP de tu página.

Esta es una captura de pantalla del informe de Lighthouse para esta página. ¡El FCP de esta página en un dispositivo móvil es de 0.8 segundos! No está mal, ¿verdad?

Midiendo FCP con una herramienta en línea

También puedes medir el FCP con una serie de herramientas en línea. Las más conocidas son GTMetrix, pingdom y pagespeed.web.dev. Estas herramientas son fáciles de trabajar y darán algunos datos sobre el LCP bajo circunstancias de laboratorio específicas.

Mejorando el First Contentful Paint

Ahora que sabes qué es el First Contentful Paint, podemos ponernos a trabajar para hacerlo más rápido. La idea detrás de un FCP rápido es en realidad bastante simple: asegurarse de que un navegador pueda comenzar a renderizar inmediatamente. Cualquier cosa que pueda causar que el renderizado se retrase resultará en una puntuación FCP pobre.

Justo como con el Largest Contentful Paint, el First Contentful Paint se puede desglosar en 2 o 4 categorías:

1. Time to first byte (TTFB) - El tiempo desde que comienza a cargar la página hasta que el navegador recibe el primer byte del HTML. 
2. Retraso de carga de recursos - El tiempo entre TTFB y cuando el navegador comienza a cargar el recurso FCP
   
3. Tiempo de carga de recursos - El tiempo que tarda en cargar el recurso FCP en sí.
   
4. Retraso de renderizado de elementos - El tiempo entre cuando el recurso FCP terminó de cargar hasta que el elemento LCP está completamente renderizado
   

Consejo de velocidad: Puedes eliminar fácilmente los pasos 2 & 3 asegurándote de que el elemento LCP no requiera un recurso de red. En el caso de un elemento de texto considera usar font-display:swap. En el caso de un elemento de imagen pequeño considera colocar la imagen en línea.

Esto solo nos deja con el Time to First Byte y el Retraso de renderizado de elementos para optimizar.

A continuación hay 14 soluciones que uso a menudo para mejorar el FCP. Pero ten cuidado, usar una solución en el lugar equivocado puede en realidad crear retrasos. Por eso es mejor consultar a un experto en pagespeed antes de comenzar tú mismo.

1. Respuesta rápida del servidor (TTFB)

El TTFB (el tiempo entre la solicitud y el primer byte que envía el servidor) es siempre el primer paso en el proceso de renderizado. A partir de ese punto, tu navegador comienza a realizar múltiples tareas, y el impacto de optimizaciones adicionales comienza a disminuir. El código HTML es la única solicitud que afecta directamente a todas las métricas de velocidad.

La velocidad a la que se envía el código HTML desde el servidor a menudo se mide como el time to first byte (TTFB). Es importante hacer esto lo más rápido posible. A menudo haces esto habilitando el almacenamiento en caché del lado del servidor.

Cuando se trata de time to first byte, más bajo es siempre mejor. 

Puedes medir fácilmente el time to first byte tú mismo. Se hace de la siguiente manera:

1. Usa el atajo Ctrl-Shift-I para abrir la consola de desarrolladores de Google Chrome.
   
2. En la parte superior de la consola, verás una pestaña Network. Haz clic en ella.
3. Recarga la página con Ctrl-R.
   
4. Ahora verás todas las solicitudes de red que Chrome ha enviado a tu servidor.
5. Haz clic en la solicitud de red superior, que es la solicitud de tu página misma.
6. Ahora obtendrás más información sobre esta solicitud de red.  Haz clic en la pestaña timing en la parte superior de esta información para ver cuál es el TTFB para tu página.

2. HTTP/3

HTTP/3 es la tercera versión del protocolo HTTP. HTTP/3 resuelve muchos de los problemas encontrados en los protocolos más antiguos HTTP/1.1 y HTTP/2. Por ejemplo, desde HTTP/2, puedes enviar múltiples archivos al mismo tiempo a través de la misma conexión. HTTP/3 proporciona una conexión inicial más rápida y menos problemas por interrupciones menores de la red.

Sin entrar en demasiados detalles, HTTP/3 permite una ganancia de velocidad significativa, especialmente en una red más lenta como una red móvil. Tu administrador de red puede decirte si tu servidor web ya es adecuado para el protocolo HTTP/3 más rápido.

Puedes comprobar por ti mismo si tu sitio web ya está utilizando el protocolo HTTP/3 más rápido. Usa el atajo Ctrl-Shift-I para abrir el inspector de red de Google Chrome. Haz clic derecho en el encabezado de la tabla y selecciona Protocol. Ahora recarga la página para ver qué protocolo está utilizando tu sitio.

3. Caché del Navegador

La conexión de red es a menudo un eslabón débil cuando se trata de la velocidad de la página. ¿No sería mucho más fácil saltarse la red por completo?

Cuando un visitante ha estado en tu sitio antes, puedes indicar si y por cuánto tiempo los recursos de red  (por ejemplo una hoja de estilo)  pueden ser almacenados por el navegador del visitante. Cada vez que el visitante necesita uno de estos archivos de nuevo, aparecen desde la caché del navegador en poco tiempo. Como resultado, el navegador puede comenzar a renderizar mucho más rápido y acelerar el FCP.

4. Compresión

La velocidad de la red es en casi todos los casos un eslabón débil. Para un buen First Contentful Paint, es muy importante que los archivos se envíen a través de la red lo más rápido posible. La compresión reduce el número de bytes que deben enviarse desde el servidor – menos bytes significa menos tiempo esperando un recurso de red. La compresión, en mi opinión, es una técnica que no está recibiendo la atención que merece. Desafortunadamente, demasiados webmasters “encienden la compresión” y luego no la vuelven a mirar. Y eso es una pena porque es solo una manera fácil de hacer que las cosas vayan un poco más rápido.

hay dos técnicas de compresión populares: Gzip y Brotli. Gzip es la técnica de compresión más utilizada pero Brotli está alcanzando rápidamente. Brotli ha sido creado por Google mismo y tiene resultados 15 a 20% mejores cuando se trata de archivos HTML, JavaScript o CSS. Brotli es, por lo tanto, ideal para la web.

También hay una diferencia entre compresión dinámica y compresión estática. Con la compresión dinámica comprimes el archivo justo antes de enviarlo a través de tu servidor web; con la compresión estática, el archivo comprimido se almacena en el servidor. Esta es a menudo una forma mucho más inteligente de comprimir, pero rara vez se usa.

5. Web-fonts tempranas con resource hints

Las resource hints inician una descarga o conexión de red antes de que el navegador lo haga por su cuenta. Algunos recursos de red, como web fonts o imágenes, solo se descargan después de que el navegador está seguro de que necesita mostrarlos.

Si estás seguro de que necesitas un recurso para renderizar la parte visible del sitio, casi siempre es una buena idea incluir una “resource hint”. Esto asegurará que el navegador comience a descargar o conectarse al recurso inmediatamente. Como resultado, el recurso está disponible antes y el navegador puede comenzar a renderizar antes.

Pero ten cuidado con las resource hints, si las usas incorrectamente, en realidad pueden ralentizar tu página.

Descarga temprana con "preloading"

<link rel="preload" href="/static/font/opensans600.woff2" as="font" type="font/woff2" crossorigin>

El enlace preload es una de las herramientas más poderosas en el arsenal de velocidad de página. A través del enlace preload, descargas un recurso de red que necesitarás más tarde. Esto es a menudo una muy buena idea con fuentes, scripts críticos e imágenes en la parte visible del sitio.

Conectando por adelantado con preconnect

El enlace preconnect ya se conecta a un servidor. Esto es útil cuando alojas archivos en un servidor de terceros como un CDN o Google analytics.

<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>

6. Prefetch la siguiente página con prefetch

<link rel="prefetch" href="/page2.html">

Con prefetch, puedes buscar recursos de baja prioridad. Esta es una forma útil de buscar recursos que crees que necesitarás más tarde – cuando esperas que alguien haga clic en el enlace de la siguiente página, por ejemplo.

7. Evita redirecciones

Un error común es tener una cadena de redirección que es demasiado larga. Déjame explicar: Tu sitio probablemente se ejecuta a través de una conexión segura. Cuando un visitante escribe tu sitio, sin agregar https, será redirigido a la versión no segura de tu sitio web. Sin embargo, si todo está configurado correctamente, el visitante será redirigido al sitio web seguro. Puedes ver esto en el ejemplo verde a continuación.

Pero a veces la redirección tiene lugar a través de uno o más pasos intermedios, como se muestra en el ejemplo rojo. Son estos pasos intermedios los que hacen que el sitio web funcione lento, resultando en una puntuación de First Contentful Paint pobre. Cada paso intermedio cuesta tiempo extra, lo que puede acumularse rápidamente. Así que, siempre asegúrate de llegar a la página correcta dentro de una redirección.

8. Minimiza CSS

Un archivo CSS externo siempre es render-blocking. Lo que eso significa es que un navegador normalmente no puede comenzar a mostrar contenido hasta que todas las hojas de estilo hayan sido descargadas y analizadas. Por lo tanto, es mejor mantener las hojas de estilo lo más pequeñas posible. De esta manera no tienes que esperar tanto para que se descargue la hoja de estilo.

Reduciendo el tamaño de CSS con shortcode

Una de las formas de reducir el tamaño de CSS es usando shortcodes. Estos son de una sola línea que te permiten escribir las propiedades más importantes de un selector CSS en una línea.

body{\r
    font-style: normal;\r
    font-weight: 400;\r
    font-stretch: normal;\r
    font-size: 0.94rem;\r
    line-height: 1.6;\r
    font-family: "Segoe UI", "Segoe UI", system-ui, -apple-system, sans-serif;\r
}

También puedes escribirlo como:

body{font: 400 .94rem/1.6 Segoe UI,Segoe UI,system-ui,-apple-system, sans-serif;}

Reduciendo el tamaño de CSS aún más

Es posible reducir el tamaño de CSS aún más fusionando selectores con una coma,  eliminando enters y espacios y escribiendo códigos de color más cortos.

h1{\r
  color : #000000;\r
}\r
h2{\r
  color : #000000;\r
}\r
h3{\r
  color : #000000;\r
}\r
h4{\r
  color : #000000;\r
}\r
h5{\r
  color : #000000;\r
}

Podría acortarse como

h1,h2,h3,h4,h5{color:#000}\r

9. Critical CSS

Podemos llevar CSS un paso más allá usando critical CSS. Critical CSS es imprescindible para un sitio web rápido y un First Contentful Paint rápido.

Critical CSS es una colección de todos los selectores (como body, p, h1 etc.) que necesitas para mostrar la parte visible de la página. No pongas este critical CSS en una hoja de estilo separada; en su lugar, agrégalo directamente en el <head> de la página. De esta manera no tienes que descargar un archivo nuevo y el navegador puede comenzar a renderizar a la velocidad del rayo. Esto hace un FCP más rápido. El CSS que no necesitas directamente para la parte visible de la página se carga después de que se completa el primer ciclo de renderizado. Para tu visitante, la página ya está lista – nadie notará los nuevos estilos que aún se agregan en segundo plano..

Critical CSS se puede generar fácilmente con nuestra propia herramienta de critical CSS. ¡Solo pega la URL de tu página web en la herramienta y nosotros haremos el resto por ti!

10. Defer loading JavaScript

Una de las razones más comunes para un First Contentful Paint lento es JavaScript. Dependiendo de cómo uses JavaScript, puede bloquear el renderizado de la página. Normalmente JavaScript es descargado y ejecutado antes de que se construya el render tree. Sin el render tree, un navegador no puede poner nada en la pantalla – esto incluye el FCP.

Podemos solucionar esto posponiendo JavaScript. Puedes hacer esto de tres maneras

Async JavaScript

<script async src="async.js"></script>

Al agregar el atributo async a una etiqueta de script, la construcción de la página ya no se bloquea mientras se descarga el JavaScript. El atributo async indica que la descarga y la construcción del render tree pueden ocurrir al mismo tiempo.

Una vez que se ejecuta el script, la página se bloquea. En la mayoría de los casos, gracias al atributo async, el navegador ha tenido suficiente tiempo para construir una parte importante de la página, con el First Contentful Paint ya en la página.

Defer JavaScript

<script defer src="async.js"></script>

El atributo defer funciona más o menos igual que el atributo async. Al agregar el atributo defer a una etiqueta de script, el script también puede descargarse simultáneamente a la construcción de la página. Después de que todos los scripts se descargan, se ejecutan en el orden en que se encontraron en el código HTML. Esto también puede bloquear la visualización de la página pero en muchos casos el First Contentful Paint ya está en la pantalla.

11. No dependas de recursos externos

Los recursos externos, como fuentes externas, imágenes externas, hojas de estilo externas o scripts externos, son un cuello de botella potencial cuando se trata del First Contentful Paint. Dado que no tienes control del servidor donde se alojan los archivos, no sabes qué tan rápido se enviarán. Además, no puedes usar la conexión existente al servidor web. Se debe configurar una nueva conexión a un nuevo servidor – y eso lleva tiempo.

Bloqueo de recursos externos

Sin recursos externos

12. Usa el formato de fuente correcto

Las fuentes merecen atención extra cuando se trata del First Contentful Paint. En aproximadamente el 99% de las páginas que miramos, el elemento FCP es una línea de texto. Cuando usas web fonts externas, debes descargar estas fuentes de un servidor primero, lo cual – por supuesto – lleva tiempo. 

Recientemente, las web fonts han estado recibiendo más atención, y hay más formatos de fuente nuevos y más rápidos. El formato de fuente más rápido en este momento es woff2, seguido de woff. Woff2 es compatible con todos los navegadores modernos. 

Puedes especificar el orden preferido de tu web font en la declaración CSS font-face. Lo haces de la siguiente manera:

 @font-face {  
   font-family: "myFont";  
   font-weight: 400;  
   font-style: normal;  
   font-display: swap;
   unicode-range: U+000-5FF 
   src: local("myFont"),
        url("/fonts/myFont.woff2") format("woff2"),
        url("/fonts/myFont.woff") format("woff");
}

13. Font display:swap

Cuando se usan web fonts, el comportamiento predeterminado de estas fuentes es no mostrar el texto en la página hasta que se carga la fuente. Esto es generalmente directamente a expensas del First Contentful Paint. 

Puedes resolver esto usando font-display:swap. Con esto puedes elegir mostrar el texto en la página de todos modos, en una fuente que el navegador conoce, mientras la webfont se carga en segundo plano..

Sin font-display:swap

Con font-display:swap

Lee nuestro artículo completo  Asegura que el texto permanezca visible durante la carga de webfont

14. Minimiza el tamaño del DOM

Una página web consiste en HTML. Lo primero que hace un navegador es convertir el HTML a nodos DOM. Esa es una estructura de árbol de elementos HTML que luego se usa para construir el render tree con. Desde el render tree un navegador comienza a renderizar; eventualmente la página web aparece en la pantalla. 

Cuántos nodos DOM (elementos HTML) tienes y qué tan profundos son estos nodos DOM en la estructura de árbol determina qué tan complicado es para un navegador construir tu página. CSS y JavaScript también toman más tiempo para analizar cuando tienes demasiados nodos DOM. Esto, de nuevo, es todo directamente a expensas del FCP.

Resuelve esto mediante:

• Lazy load partes de tu página web
  Para acelerar la visualización inicial, considera cargar partes de tu sitio web, como el pie de página, a través de AJAX en un momento posterior.
• Haz uso de content-visibility
  La propiedad CSS content-visibility le dice a un navegador que omita el estilo, el diseño y la pintura durante el renderizado. Lo hace justo antes de que el elemento se vuelva visible.
•  Divide páginas grandes en múltiples páginas
  El número de nodos DOM se puede reducir dividiendo páginas grandes en múltiples páginas.
•  Implementa infinite scroll
  Infinite scrolling es básicamente lazy loading: cuando te desplazas a través de elementos repetidos como imágenes (pinterest) o tablas grandes de datos, infinite scroll puede acelerar significativamente tu página.
• Evita la interacción DOM de JavaScript
  Ten cuidado extra con JavaScript cuando tienes un gran número de nodos DOM en tu página. Un comando como puede cargar un gran número de nodos DOM, aumentando el uso de memoria.
• Evita declaraciones CSS complicadas
  Ten cuidado extra con comandos CSS complicados con un gran número de nodos DOM. Por ejemplo, deberías verificar el estado last-child para cada elemento div en tu página.
• Usa web workers para ahorrar el hilo principal de tu navegador
  Web workers son JavaScript que pueden ejecutarse en paralelo con tu página web. Puedes dar a estos web workers comandos que se ejecutan en segundo plano. Cuando el web worker ha ejecutado el comando, lo pasa a la página original. La ventaja de esto es que aún puedes ejecutar JavaScript complejo sin que la página se congele.