Guías

Cada métrica de rendimiento responde a una pregunta, y vale lo que vale esa pregunta. El First Contentful Paint plantea una que todo visitante se hace sin pensarlo: ¿cuánto tiempo llevo mirando a la nada? No cuánto falta para que la página sea usable, ni cuánto falta para que llegue la imagen grande, solo cuánto falta para que aparezca algo.

Eso convierte al FCP en la primera señal honesta que una página puede dar. Tampoco es un Core Web Vital, por razones que merece la pena entender, y eso cambia el peso que merece en tus prioridades.

Qué mide realmente el FCP

El FCP mide el tiempo desde que el usuario empieza a navegar a la página hasta el momento en que alguna parte del contenido se representa en pantalla. Aquí contenido tiene una definición precisa y no intuitiva: texto, imágenes incluidas las de fondo, elementos SVG y elementos canvas que no estén en blanco vacío.

La distinción que importa es entre First Paint y First Contentful Paint. El First Paint se dispara en cuanto el navegador cambia un píxel, lo que incluye pintar un color de fondo sobre la página anterior. En ese instante no se ha comunicado nada. El FCP espera a algo que una persona pueda leer o mirar de verdad.

Como el FCP es el primer contenido, es por definición anterior o igual al Largest Contentful Paint. En una página cuyo elemento más grande es también el primero, ambos valen lo mismo. En una página que muestra un titular al instante y una imagen de cabecera tres segundos después, están muy separados, y ese hueco es la parte interesante de la lectura.

Los umbrales, y el Core Web Vital que no es

Google publica tres franjas para el FCP, medidas en el percentil 75 de las cargas de página y separadas por tipo de dispositivo: bueno con 1,8 segundos o menos, mejorable entre 1,8 y 3 segundos, y malo por encima de 3 segundos. Móvil y escritorio se puntúan por separado, lo cual importa porque un mismo sitio cae con frecuencia en franjas distintas en cada uno.

• Total Blocking Time - 30 %
• Largest Contentful Paint - 25 %
• Cumulative Layout Shift - 25 %
• First Contentful Paint - 10 %
• Speed Index - 10 %

El FCP no es un Core Web Vital. Los Core Web Vitals son el LCP, el INP y el CLS, y son esos tres los que alimentan las señales de experiencia de página de Google. El FCP está al lado como métrica de diagnóstico: aparece en PageSpeed Insights y en el Chrome User Experience Report y pesa en la puntuación de rendimiento de Lighthouse, pero no forma parte del conjunto que toca el posicionamiento.

No es motivo para ignorarlo. Es motivo para usarlo en lo que hace bien, que es decirte si tu problema empieza antes del renderizado o durante él. En la puntuación de rendimiento de Lighthouse 10 los pesos se reparten así:

Qué lo retrasa de verdad

El primer componente del FCP es el tiempo hasta el primer byte. Nada puede pintarse antes de que llegue el primer byte de HTML, así que un servidor lento, una consulta lenta o un origen lejano ponen bajo el FCP un suelo que ningún trabajo de front-end levantará. Si el TTFB es de 1,5 segundos, un FCP por debajo de 1,8 es casi imposible.

El segundo son los recursos que bloquean el renderizado. Una hoja de estilos en el head debe descargarse y analizarse antes de que el navegador pinte, porque pintar con los estilos equivocados y repintar es peor que esperar. Los scripts síncronos en el head bloquean el análisis por completo. Cada uno es un viaje de ida y vuelta serializado insertado entre la llegada del HTML y la aparición de cualquier cosa.

El tercero son las fuentes web, y es el que se olvida. Una fuente declarada con font-display: block concede al navegador un periodo durante el cual el texto en esa fuente se representa invisible mientras el archivo se descarga. Un texto invisible no es contenido, así que el FCP lo espera. Pasar a font-display: swap pinta de inmediato una fuente de reserva y cambia a la real cuando llega, canjeando un reajuste visible por una primera aparición de palabras más temprana.

Medirlo tú mismo

En campo, el FCP viene del Chrome User Experience Report, que es lo que PageSpeed Insights muestra en su sección superior para usuarios reales en conexiones reales. Ese es el número fiable, porque refleja los dispositivos y las redes que tienen de verdad tus visitantes y no la máquina en la que estás probando.

En el navegador, un PerformanceObserver que escucha el tipo de entrada paint informa tanto de first-paint como de first-contentful-paint. Leer los dos es más útil que leer uno solo. Un hueco grande entre ellos significa que el navegador tenía píxeles que empujar y eligió primero un color de fondo, que es la firma de una hoja de estilos o una fuente interponiéndose entre tu HTML y tu lector.

FCP o LCP: cuál arreglar primero

Si el FCP y el LCP son ambos malos, arregla la causa común y se mueven los dos. El TTFB, el CSS bloqueante y las fuentes bloqueantes están aguas arriba de ambas métricas, así que el trabajo invertido ahí nunca se pierde. Si el FCP es bueno y el LCP malo, el problema es propio de tu elemento más grande, normalmente una imagen de cabecera sin optimizar o que el escáner de precarga descubre demasiado tarde.

El patrón que conviene reconocer es el inverso: un FCP malo con un LCP aceptable. Significa que el navegador estuvo inactivo antes de pintar nada y luego recuperó rápido, lo que casi siempre es un recurso bloqueante en el head y no un problema de peso. Es además la más barata de arreglar de las tres situaciones.