Pintado del primer contenido (FCP)
Qué mide First Contentful Paint, qué puntuación de FCP es buena, por qué no es una Core Web Vital, en qué se diferencia de First Paint y LCP y cómo corregir un FCP lento.
Idiomas
First Contentful Paint (FCP) es el tiempo desde que una página empieza a cargarse hasta que se renderiza por primera vez cualquier parte de su contenido —texto, imagen, SVG o canvas no blanco—. Un buen resultado es ≤1,8 s en el percentil 75 de usuarios reales. NO es una Core Web Vital: las señales de posicionamiento son LCP, INP y CLS. FCP es una métrica diagnóstica (de laboratorio y de campo) y un componente de LCP —ocurre antes o al mismo tiempo que LCP—, por lo que sirve principalmente para detectar recursos que bloquean el renderizado y un TTFB lento. En Lighthouse 10 representa el 10 % de la puntuación de rendimiento. Corrígelo eliminando CSS/JS que bloqueen el renderizado, reduciendo el TTFB, insertando CSS crítico, usando font-display: swap y preconectando con los orígenes necesarios.
TL;DR — First Contentful Paint (FCP) es el momento en que un visitante ve el primer elemento de tu página —cualquier texto, imagen o gráfico— en lugar de una pantalla blanca vacía. Cuanto más rápido, mejor; menos de 1,8 segundos es la marca de «bueno». Es una comprobación útil de velocidad, pero no es una de las métricas que Google utiliza para el posicionamiento.
Qué es realmente FCP
Cuando alguien hace clic en un enlace a tu página, hay un breve intervalo en el que mira la nada —una pantalla vacía— mientras el navegador obtiene y procesa tu página. First Contentful Paint es el instante en que esa pantalla vacía se convierte en algo real: un titular, un logotipo, una foto, cualquier cosa que el visitante pueda ver.
Esa es toda la idea. FCP responde a una pregunta sencilla: «¿Cuánto tarda el usuario en ver que la página está viva y haciendo algo?» Una página que pinta contenido en medio segundo parece rápida. Una página que permanece vacía durante tres segundos parece rota, y la gente se va.
Evidence for this claim FCP measures from navigation until the first text, image, SVG, or non-white canvas content is rendered. Scope: Current web.dev FCP definition and qualifying content types. Confidence: high · Verified: web.dev: First Contentful PaintQué cuenta como «contenido»
FCP se produce cuando el navegador dibuja cualquiera de estos elementos en la pantalla:
- Texto (un encabezado, un párrafo, un enlace de navegación)
- Imágenes, incluidas las imágenes de fondo
- Gráficos
<svg> - Un elemento
<canvas>que no sea blanco
Un color de fondo por sí solo no cuenta: eso es otra cosa anterior llamada First Paint. FCP solo cuenta cuando aparece contenido real.
¿Qué puntuación es buena?
Los intervalos de Google, medidos entre visitantes reales:
| Tiempo de FCP | Valoración |
|---|---|
| 1,8 segundos o menos | Bueno |
| 1,8–3,0 segundos | Necesita mejoras |
| Más de 3,0 segundos | Deficiente |
Verás tu FCP en herramientas como PageSpeed Insights y Lighthouse, los mismos informes que muestran tus Core Web Vitals.
¿Afecta FCP a mi posicionamiento en Google?
No, no directamente. Esta es la parte que la mayoría entiende mal. Las métricas que Google utiliza realmente para el posicionamiento son las tres Core Web Vitals: LCP, INP y CLS. FCP no es una de ellas.
Pero esta es la razón por la que aún merece la pena vigilarlo: las cosas que hacen lento el FCP —un servidor lento, hojas de estilo grandes y scripts que bloquean el dibujo de la página— suelen ser las mismas que perjudican a Largest Contentful Paint (LCP), que sí es una señal de posicionamiento. Por eso, corregir las causas raíz de FCP suele ayudar también a LCP, pero no es una garantía, porque LCP tiene sus propias causas (el tamaño y la prioridad de carga de su elemento más grande). Piensa en FCP como una alarma de humo: merece la pena comprobarla, pero no demuestra que el incendio esté apagado.
Correcciones rápidas
Si tu FCP es lento, estos son los sospechosos habituales (y qué hacer):
- Archivos que bloquean el renderizado. El CSS y JavaScript del
<head>pueden impedir que el navegador dibuje nada hasta que terminen de cargarse. Es la causa número uno. - Un servidor lento. Si tu servidor tarda mucho en responder (un Time to First Byte alto), el navegador no puede pintar hasta que llegan los bytes.
- Fuentes que ocultan el texto. Algunas configuraciones de fuentes dejan el texto invisible hasta tres segundos mientras carga una fuente web. Cambiar la regla a
font-display: swapmuestra inmediatamente el texto de fallback.
¿Quieres la versión técnica —la diferencia entre laboratorio y campo, la cadena diagnóstica FCP/LCP y la lista completa de correcciones—? Cambia a la pestaña Avanzado.
TL;DR — FCP es el tiempo desde el inicio de la navegación hasta que se renderiza por primera vez cualquier contenido de la página (texto, imagen,
<svg>o<canvas>no blanco). No es una Core Web Vital: es una métrica diagnóstica complementaria, de laboratorio y de campo, y un componente de LCP (FCP ocurre antes o al mismo tiempo que LCP). Umbrales de campo (p75): Bueno ≤ 1,8 s, necesita mejoras ≤ 3,0 s, deficiente > 3,0 s. En Lighthouse 10 representa el 10 % de la puntuación de rendimiento. Como el reloj de FCP empieza con la navegación, incluye el tiempo de redirección, la configuración de la conexión y el TTFB, por lo que las cifras de laboratorio (Lighthouse) y de campo (CrUX) suelen diferir. Corrígelo donde se origina: primero el CSS/JS que bloquea el renderizado, después el TTFB y luego las fuentes.
Qué mide FCP (con precisión)
La definición de Google, tomada del artículo de Philip Walton en web.dev, es la columna vertebral de la precisión aquí:
“First Contentful Paint (FCP) measures the time from when the user first navigated to the page to when any part of the page’s content is rendered on the screen.” (traducción) «First Contentful Paint (FCP) mide el tiempo desde que el usuario navegó por primera vez a la página hasta que cualquier parte del contenido de la página se renderiza en pantalla». «Content», según el mismo documento, significa “text, images (including background images), <svg> elements, or non-white <canvas> elements.” (traducción) «texto, imágenes (incluidas las imágenes de fondo), elementos <svg> o elementos <canvas> no blancos».
La palabra que hace todo el trabajo es any. A FCP no le importa qué se renderiza: un logotipo de 40 píxeles cuenta igual que una imagen principal completa. Es la señal de «¿ya hay algo en pantalla?», precisamente por lo que es un indicador temprano y no una métrica de finalización.
Evidence for this claim FCP measures from navigation until the first text, image, SVG, or non-white canvas content is rendered. Scope: Current web.dev FCP definition and qualifying content types. Confidence: high · Verified: web.dev: First Contentful PaintHay un detalle fácil de pasar por alto que cambia la forma de leer la cifra: el reloj de FCP empieza con la navegación, así que incluye todo lo que ocurre antes de que se analice siquiera tu HTML. El propio punto clave de Google dice: “FCP includes any unload time from the previous page, connection set up time, redirect time, and Time To First Byte (TTFB) which can be significant when measured in the field.” (traducción) «FCP incluye cualquier tiempo de descarga de la página anterior, el tiempo de configuración de la conexión, el tiempo de redirección y el Time To First Byte (TTFB), que puede ser considerable cuando se mide en campo». Un servidor que tarda 1,5 s en responder ya ha consumido la mayor parte de tu presupuesto de 1,8 s antes de que el navegador procese un solo byte.
FCP NO es una Core Web Vital
Voy a ser tajante porque la mayoría de las páginas se andan con rodeos: FCP no es una Core Web Vital ni forma parte de las señales de posicionamiento de Google. Las Core Web Vitals son LCP, INP y CLS, y FCP no aparece en ninguna parte de la página de Google sobre las Core Web Vitals del posicionamiento en búsquedas.
Lo que sí es FCP, en la taxonomía de Google, es una «Other Web Vital»: una métrica complementaria útil para el diagnóstico. web.dev lo expresa así: “the metrics Time to First Byte (TTFB) and First Contentful Paint (FCP) are both vital aspects of the loading experience, and are both useful in diagnosing issues with LCP (slow server response times or render-blocking resources, respectively).” (traducción) «las métricas Time to First Byte (TTFB) y First Contentful Paint (FCP) son aspectos fundamentales de la experiencia de carga y ambas sirven para diagnosticar problemas de LCP (tiempos de respuesta lentos del servidor o recursos que bloquean el renderizado, respectivamente)».
Por tanto, la forma honesta de explicárselo a las partes interesadas tiene dos caras, y debes decir ambas sin titubear:
- FCP no afecta directamente al posicionamiento. No optimices FCP «para SEO».
- FCP es un buen diagnóstico de LCP, que sí afecta al posicionamiento. Los recursos que bloquean el renderizado aparecen primero en FCP.
FCP frente a First Paint (FP)
Se confunden constantemente:
- First Paint (FP) se produce cuando el navegador pinta cualquier cosa, incluso un color de fondo sin contenido real.
- FCP se produce solo cuando se renderiza contenido apto: texto, imágenes (incluidas las imágenes de fondo), elementos
<svg>o elementos<canvas>no blancos. Es una lista específica definida por la especificación, no una regla imprecisa de «cualquier contenido del DOM», y conviene mantenerla precisa porque una imagen de fondo cuenta aunque no sea texto del DOM.
Por tanto, FP ≤ FCP, siempre. En la mayoría de las páginas son casi idénticos, porque es raro pintar un color de fondo sin contenido encima. Cuando existe una diferencia significativa, normalmente significa que se pintó un fondo meramente decorativo antes que cualquier contenido real. La API Paint Timing devuelve entradas tanto para first-paint como para first-contentful-paint, pero FCP es el que merece análisis; FP rara vez aporta algo accionable.
FCP frente a LCP
La otra pareja que la gente mezcla:
- FCP = cuando se pinta cualquier contenido. Se produce pronto. Puede ser un logotipo diminuto o un enlace de navegación.
- LCP = cuando se renderiza el elemento más grande de la ventana gráfica. Se produce en FCP o después.
La formulación de Google es que FCP mide cuándo se pinta cualquier contenido y LCP cuándo se pinta el contenido principal, por lo que LCP pretende ser más selectivo. Interpreta «más selectivo» como eso, no como «certificado como correcto»: ninguna de las dos métricas demuestra que el contenido principal real de la página esté completo o sea útil para el visitante. FCP solo confirma que se pintó algo apto; LCP confirma que lo hizo el candidato apto más grande. Una página puede tener un FCP rápido (logotipo a 0,5 s) y un LCP lento (imagen principal a 4 s); esa diferencia es en sí misma un diagnóstico útil. Y si tu FCP está cerca de tu LCP, suele ser una buena señal: significa que lo primero que se pintó también es lo más grande, sin un renderizado inicial desperdiciado en elementos de interfaz que no importan al usuario.
Evidence for this claim FCP answers when any eligible content first appears, while LCP tracks the largest eligible viewport candidate; neither metric proves the page's main content is complete or useful. Scope: field and lab Confidence: high · Verified: First Contentful Paint (FCP)Conviene conocer una rareza de medición: debido a las restricciones de seguridad sobre la temporización de imágenes de origen cruzado, la API del navegador puede informar en casos excepcionales de un LCP anterior al FCP. Es un artefacto de medición, no algo que haya ocurrido físicamente.
Umbrales y por qué laboratorio y campo no coinciden
Umbrales de campo (CrUX, p75): Bueno ≤ 1,8 s · necesita mejoras ≤ 3,0 s · deficiente > 3,0 s. La orientación de Google es medir en el percentil 75 de las cargas de página, separado entre móviles y ordenadores.
Evidence for this claim A good FCP is 1.8 seconds or less at the 75th percentile; above 3 seconds is poor. Scope: Current web.dev FCP field thresholds. Confidence: high · Verified: web.dev: First Contentful PaintPero Lighthouse para ordenadores utiliza límites distintos y más estrictos: verde es aproximadamente 0–0,9 s, naranja 0,9–1,6 s y rojo más de 1,6 s, porque el laboratorio ejecuta un Chrome limpio y limitado en un dispositivo simulado, no en condiciones reales. (Esas bandas, al igual que las ponderaciones de la puntuación que aparecen más adelante, dependen de la versión de Lighthouse; esto refleja el documento de auditoría vigente al redactar estas líneas). La puntuación de FCP de Lighthouse es “a comparison of your page’s FCP time and FCP times for real websites, based on data from the HTTP Archive.” (traducción) «una comparación del tiempo de FCP de tu página con los tiempos de FCP de sitios web reales, basada en datos de HTTP Archive».
Esta es la fuente más común de confusión sobre FCP, así que interiorízala:
La línea de «bueno» de 1,8 s es el umbral de campo (CrUX p75). La línea «verde» de Lighthouse para ordenadores es de ~0,9 s. Son escalas distintas para trabajos distintos.
Las cifras de campo y de laboratorio difieren principalmente porque muestrean poblaciones distintas, no porque una sea universalmente «más verdadera». Lighthouse ejecuta una única sesión limpia con condiciones fijas de dispositivo y red. Campo/CrUX agrega dispositivos reales, redes reales, estados de caché y tipos de navegación, incluidas restauraciones del back/forward cache y páginas prerenderizadas, que no reciben automáticamente un FCP nuevo como una navegación normal; necesitan su propio tratamiento del ciclo de vida (la biblioteca web-vitals lo hace por ti). En la mayoría de los sitios, la cifra de campo sí resulta más alta: los usuarios reales arrastran cadenas de redirecciones, el tiempo de descarga de la página anterior y conexiones frías que una ejecución de laboratorio omite, pero eso es una tendencia, no una regla. Antes de interpretar una diferencia entre laboratorio y campo como un problema, comprueba que comparas situaciones equivalentes (misma clase de dispositivo y mismas condiciones de red). Usa los datos de campo para tu cifra del mundo real y Lighthouse para el diagnóstico.
Dónde encaja FCP en la puntuación de Lighthouse
En Lighthouse 10 —la versión actual al redactar estas líneas, no una cifra permanente— FCP representa el 10 % de la puntuación de rendimiento. La ponderación completa es:
| Métrica | Peso |
|---|---|
| Total Blocking Time (TBT) | 30 % |
| Largest Contentful Paint (LCP) | 25 % |
| Cumulative Layout Shift (CLS) | 25 % |
| First Contentful Paint (FCP) | 10 % |
| Speed Index | 10 % |
La puntuación de rendimiento es una media ponderada de las puntuaciones de cada métrica, y Google señala que las ponderaciones cambian con el tiempo a medida que evoluciona su investigación. FCP se ha mantenido en el 10 % desde Lighthouse 8 hasta 10, pero confírmalo con la versión que estés ejecutando antes de tratar ese «10 %» como algo inmutable. La lectura práctica es que un FCP perfecto solo puede mover tu cifra de Lighthouse hasta cierto punto, y un FCP malo suele apuntar también a un LCP malo (comparten causas raíz), aunque es una coincidencia que conviene comprobar, no algo que la puntuación garantice.
Qué causa un FCP lento
En orden aproximado de prioridad:
- Recursos que bloquean el renderizado: el asesino número uno. El CSS y el JS síncrono del
<head>obligan al navegador a esperar: no puede construir el CSSOM ni el árbol de renderizado, así que no puede pintar nada hasta descargar y analizar esos archivos. - TTFB alto: FCP no puede producirse antes de que lleguen los bytes. Un servidor lento es la primera pieza del dominó y está dentro de la medición de FCP.
- Cadenas de redirecciones: cada redirección añade un viaje de ida y vuelta completo antes del primer byte.
- Estrategia de carga de fuentes web:
font-display: block(o ninguna regla) puede dejar el texto invisible hasta unos 3 segundos. Aunque el pintado se produzca técnicamente sobre un fondo, el usuario no ve nada útil.
Cómo corregirlo
La lista completa, pero con un orden de prioridad que la documentación no te da. Son palancas habituales, no universales: comprueba primero tu traza o tira de película para ver qué recurso o fase está retrasando realmente tu candidato de FCP antes de aplicar correcciones (preconnect, preload o un cambio de font-display) que quizá no correspondan a tu página:
Haz esto primero (mayores beneficios):
- Elimina el CSS y JavaScript que bloquean el renderizado. Inserta el CSS crítico de la zona visible directamente en
<head>, carga el resto de forma asíncrona y añadeasync/defera los scripts no críticos. Cambiar de sitio una etiqueta<link>no ayuda: el navegador no pintará hasta que todo el CSS se cargue y analice, independientemente de dónde esté la etiqueta. - Reduce el TTFB (tiempo de respuesta del servidor). Caché, CDN, un origen más rápido: cualquier cosa que entregue antes el primer byte reduce directamente el FCP.
- Corrige la carga de fuentes. Usa
font-display: swap(muestra inmediatamente el texto de fallback y cambia a la fuente web cuando está lista) ofont-display: optional(omite la fuente web si aún no está en caché). Evitafont-display: blockpara el texto crítico: es lo peor para FCP.
Después, ordena el resto:
- Preconecta con los orígenes necesarios mediante
<link rel="preconnect">: establecer pronto conexiones con orígenes de terceros importantes puede ahorrar 100–500 ms. - Precarga solicitudes clave (
<link rel="preload">) para una fuente crítica o la imagen LCP. - Minifica el CSS, elimina CSS sin usar y elimina JavaScript sin usar: los archivos más pequeños se analizan antes y desbloquean antes el pintado.
- Evita múltiples redirecciones, evita cargas de red enormes, sirve recursos estáticos con una política de caché eficiente, evita un DOM excesivo y minimiza la profundidad de solicitudes críticas. Es higiene general de la carga que alimenta el primer pintado.
La cadena diagnóstica FCP → TTFB → LCP
Así es como yo usaría realmente FCP, y es el enfoque que la documentación sugiere sin desarrollarlo: trata las tres métricas de carga como un único flujo de trabajo:
- FCP alto → comprueba los recursos que bloquean el renderizado (CSS/JS en
<head>). Es la causa más habitual y la mejora más rápida. - Comprueba también el TTFB: como FCP lo incluye, un servidor lento infla FCP antes de que entre en escena cualquier bloqueo del renderizado. La orientación de web.dev es que, como TTFB precede a FCP y LCP, tu servidor debe responder lo bastante rápido para que el percentil 75 de los usuarios alcance un FCP «bueno».
- Estos mismos problemas suelen propagarse a LCP —la métrica que sí es una señal de posicionamiento— porque FCP y LCP comparten con frecuencia causas raíz. Es una coincidencia que conviene comprobar, no una garantía: LCP tiene sus propios factores (el tamaño, la prioridad y la ruta de carga de su elemento más grande), así que corregir las causas de FCP no promete arreglar LCP. Es el lugar correcto para empezar a mirar, no el último paso.
Ese es el valor de FCP para un profesional de SEO: una lectura temprana y barata de si la ruta de carga está sana, antes de que termine la medición más selectiva de LCP.
Resumen de IA
Una síntesis de la versión avanzada:
- FCP = tiempo desde el inicio de la navegación hasta que se renderiza por primera vez cualquier contenido: texto, imágenes (incluido el fondo),
<svg>o<canvas>no blanco. Es la señal de «¿ya hay algo en pantalla?». - FCP NO es una Core Web Vital. Las señales de posicionamiento son LCP, INP y CLS. FCP es una métrica diagnóstica complementaria, de laboratorio y de campo, no un factor directo de posicionamiento.
- Es un componente de LCP (FCP ocurre antes o al mismo tiempo que LCP), por lo que suele detectar los mismos recursos que bloquean el renderizado y el TTFB lento que perjudican a LCP —que sí afecta al posicionamiento—, pero corregir las causas de FCP no garantiza arreglar LCP; LCP tiene sus propios factores.
- Umbrales de campo (CrUX p75): Bueno ≤ 1,8 s · necesita mejoras ≤ 3,0 s · deficiente > 3,0 s.
- Laboratorio ≠ campo, y «el campo siempre es más alto» es una tendencia, no una regla. La línea «verde» de ~0,9 s de Lighthouse para ordenadores es más estricta que el umbral de campo de 1,8 s porque es una ejecución limpia en condiciones fijas; campo/CrUX agrega dispositivos, redes, estados de caché y tipos de navegación reales (incluidas restauraciones de bfcache y páginas prerenderizadas). Compara poblaciones antes de interpretar una diferencia como un problema: usa campo para tu cifra real y laboratorio para el diagnóstico.
- FCP frente a FP: First Paint se produce con cualquier pintado (incluso un color de fondo); FCP necesita contenido apto (texto, imágenes incluidas las de fondo, SVG o canvas no blanco). FP ≤ FCP siempre.
- FCP frente a LCP: FCP = cualquier contenido apto; LCP = el candidato apto más grande. Ninguna demuestra que el contenido principal real esté completo o sea útil: son proxies. FCP rápido + LCP lento es una diferencia real y frecuente.
- Peso de Lighthouse 10 (actual al redactar estas líneas): 10 % — TBT 30 %, LCP 25 %, CLS 25 %, FCP 10 %, Speed Index 10 %; las ponderaciones cambian entre versiones de Lighthouse.
- Principales correcciones, por orden: elimina CSS/JS que bloqueen el renderizado → reduce TTFB → corrige las fuentes (
font-display: swap/optional) → preconecta/precarga → minifica, optimiza la caché y el DOM.
Documentación oficial
Documentación de fuentes primarias de Google sobre FCP.
web.dev (Google)
- First Contentful Paint (FCP): definición canónica de Philip Walton, lista de lo que cuenta como contenido, umbral de 1,8 s, punto clave sobre TTFB/redirecciones y medición de FCP con la API Paint Timing y la biblioteca web-vitals.
- Web Vitals: dónde encaja FCP, una «Other Web Vital» complementaria a las Core Web Vitals (LCP, INP, CLS), útil para diagnosticar LCP.
- Largest Contentful Paint (LCP): la distinción entre FCP y LCP y su relación.
- Time to First Byte (TTFB): por qué TTFB precede a FCP y está incluido en él.
- User-centric performance metrics: clasificación de FCP como métrica de laboratorio y de campo.
Lighthouse / Chrome Developers
- First Contentful Paint audit: bandas de valoración de escritorio de Lighthouse (verde ≤ 0,9 s) y cómo se calcula la puntuación de FCP frente a los datos de HTTP Archive.
- Lighthouse performance scoring: ponderaciones de las métricas, incluido FCP con el 10 % de la puntuación de rendimiento en Lighthouse 10.
Google Search Central
- Core Web Vitals & Google Search: la página sobre señales de posicionamiento; enumera LCP, INP y CLS. FCP no aparece, y ese es el punto.
Citas de la fuente
Declaraciones registradas de la documentación de Google. Cada enlace es un enlace profundo que salta al pasaje citado en la página de origen.
web.dev: la definición
- “First Contentful Paint (FCP) measures the time from when the user first navigated to the page to when any part of the page’s content is rendered on the screen.” (traducción) «First Contentful Paint (FCP) mide el tiempo desde que el usuario navegó por primera vez a la página hasta que cualquier parte del contenido de la página se renderiza en pantalla». — Philip Walton, First Contentful Paint (FCP), web.dev (actualizado el 6 de diciembre de 2023). Ir a la cita
web.dev: el umbral
- “sites should strive to have a First Contentful Paint of 1.8 seconds or less.” (traducción) «los sitios deberían aspirar a tener un First Contentful Paint de 1,8 segundos o menos». — misma fuente. Ir a la cita
web.dev: qué incluye FCP (el punto clave)
- “FCP includes any unload time from the previous page, connection set up time, redirect time, and Time To First Byte (TTFB) which can be significant when measured in the field.” (traducción) «FCP incluye cualquier tiempo de descarga de la página anterior, el tiempo de configuración de la conexión, el tiempo de redirección y el Time To First Byte (TTFB), que puede ser considerable cuando se mide en campo». — misma fuente.
web.dev: papel de FCP respecto a las Core Web Vitals
- “the metrics Time to First Byte (TTFB) and First Contentful Paint (FCP) are both vital aspects of the loading experience, and are both useful in diagnosing issues with LCP (slow server response times or render-blocking resources, respectively).” (traducción) «las métricas Time to First Byte (TTFB) y First Contentful Paint (FCP) son aspectos fundamentales de la experiencia de carga y ambas sirven para diagnosticar problemas de LCP (tiempos de respuesta lentos del servidor o recursos que bloquean el renderizado, respectivamente)». — Web Vitals, web.dev. Ir a la cita
Lighthouse: cómo se calcula la puntuación de FCP
- “Your FCP score is a comparison of your page’s FCP time and FCP times for real websites, based on data from the HTTP Archive.” (traducción) «La puntuación de FCP es una comparación del tiempo de FCP de tu página con los tiempos de FCP de sitios web reales, basada en datos de HTTP Archive». — First Contentful Paint audit, developer.chrome.com.
Lighthouse: cómo funciona la puntuación de rendimiento
- “The Performance score is a weighted average of the metric scores.” (traducción) «La puntuación de rendimiento es una media ponderada de las puntuaciones de las métricas».
- “The weightings have changed over time because the Lighthouse team is regularly doing research and gathering feedback to understand what has the biggest impact on user-perceived performance.” (traducción) «Las ponderaciones han cambiado con el tiempo porque el equipo de Lighthouse investiga y recopila comentarios con regularidad para comprender qué influye más en el rendimiento percibido por el usuario». — Lighthouse performance scoring, developer.chrome.com.
#:~:text=; confírmalos en las páginas activas antes de tratar cualquier cita como definitiva. Las ponderaciones de Lighthouse se citan para Lighthouse 10: vuelve a verificarlas si se ha publicado una versión más reciente. Lista de comprobación para investigar un FCP lento
Cuando FCP sea alto, baja por esta lista en orden: es, aproximadamente, de mayor a menor beneficio:
- Comprueba la cifra de campo, no solo Lighthouse. Lee el p75 de CrUX/PageSpeed Insights para conocer el FCP real; usa Lighthouse solo para diagnosticar.
- Busca recursos que bloqueen el renderizado. El CSS y el JS síncrono del
<head>son la causa número uno; la auditoría «Eliminate render-blocking resources» de Lighthouse los enumera. - Inserta el CSS crítico de la zona visible; carga el resto de forma asíncrona.
- Añade
async/defera los scripts no críticos y mueve las etiquetas de terceros después del primer pintado. - Mide el TTFB. Está dentro de FCP: un servidor lento infla FCP antes que cualquier otra cosa. Añade caché, un CDN o un origen más rápido.
- Elimina las cadenas de redirecciones: cada salto es un viaje de ida y vuelta completo antes del primer byte.
- Corrige las fuentes: usa
font-display: swapuoptional; nuncablockpara texto crítico. Precarga el archivo de fuente crítico. - Preconecta con los orígenes de terceros necesarios y precarga la imagen LCP o las solicitudes clave.
- Reduce la carga: minifica CSS, elimina CSS/JS sin usar, aplica una política de caché eficiente, reduce el DOM y acorta la profundidad de solicitudes críticas.
- Vuelve a comprobar LCP después: las mismas correcciones deberían haberlo movido, y LCP es la métrica que afecta al posicionamiento.
Chuleta de FCP
Umbrales de campo (CrUX, percentil 75)
| Tiempo de FCP | Valoración |
|---|---|
| ≤ 1,8 s | Bueno |
| 1,8–3,0 s | Necesita mejoras |
| > 3,0 s | Deficiente |
**Valoración de escritorio de Lighthouse (laboratorio; más estricta que la de campo)
| Tiempo de FCP | Color |
|---|---|
| 0–0,9 s | Verde (rápido) |
| 0,9–1,6 s | Naranja (moderado) |
| Más de 1,6 s | Rojo (lento) |
Ponderaciones de la puntuación de rendimiento de Lighthouse 10 (actuales al redactar estas líneas; las ponderaciones cambian entre versiones de Lighthouse)
| Métrica | Peso |
|---|---|
| Total Blocking Time | 30 % |
| Largest Contentful Paint | 25 % |
| Cumulative Layout Shift | 25 % |
| First Contentful Paint | 10 % |
| Speed Index | 10 % |
Las tres métricas de carga, sin confusión
| Métrica | Se produce cuando… | ¿Core Web Vital? |
|---|---|---|
| First Paint (FP) | el navegador pinta cualquier cosa, incluso un color de fondo | No |
| First Contentful Paint (FCP) | se pinta cualquier contenido real (texto/imagen/SVG/canvas) | No (diagnóstica) |
| Largest Contentful Paint (LCP) | se renderiza el elemento más grande de la ventana gráfica | Sí |
Orden de los eventos: FP ≤ FCP ≤ LCP.
Qué cuenta como «contenido» para FCP
texto · imágenes (incluidas las imágenes de fondo) · elementos <svg> · elementos <canvas> no blancos
Datos rápidos
- El reloj de FCP empieza con la navegación: incluye el tiempo de redirección, la configuración de la conexión y el TTFB.
- FCP se puede medir tanto en laboratorio como en campo.
font-display: usaswap/optional; evitablock(texto invisible hasta unos 3 s).- Preconectar con orígenes de terceros puede ahorrar 100–500 ms.
Herramientas para medir FCP
Datos de campo (usuarios reales)
- PageSpeed Insights: muestra el FCP p75 de CrUX de tu URL (campo) junto a una ejecución de Lighthouse (laboratorio).
- Chrome User Experience Report (CrUX): el conjunto de datos de usuarios reales que sustenta las cifras de campo, disponible mediante la API o BigQuery.
- Biblioteca JavaScript web-vitals: añade
onFCP(console.log)(o envíalo a tus analíticas) para capturar FCP de tus propios visitantes; gestiona los casos extremos de bfcache y de pestañas en segundo plano.
Datos de laboratorio (simulados)
- Lighthouse: en Chrome DevTools, PageSpeed Insights o la CLI. Úsalo para diagnosticar FCP (la auditoría «Eliminate render-blocking resources» es la clave).
- Panel Performance de Chrome DevTools: observa exactamente cuándo se producen First Paint y First Contentful Paint en una carga registrada.
Mídelo tú mismo con la API Paint Timing
new PerformanceObserver((entryList) => {
for (const entry of entryList.getEntriesByName('first-contentful-paint')) {
console.log('FCP candidate:', entry.startTime, entry);
}
}).observe({type: 'paint', buffered: true});O usa la biblioteca web-vitals (recomendado)
import {onFCP} from 'web-vitals';
onFCP(console.log);Hay algunos casos que la API sin procesar no gestiona y la biblioteca web-vitals sí: ignora el FCP producido en pestañas en segundo plano, sigue informando de FCP cuando una página se restaura desde la caché de atrás/adelante (un evento de navegación nuevo no se dispara automáticamente al restaurar desde bfcache, por lo que necesita un tratamiento explícito) y usa activationStart en lugar del inicio de navegación como origen del reloj para páginas prerenderizadas. La temporización del pintado en un iframe de origen cruzado sigue siendo una carencia conocida: una página cuyo contenido principal se renderiza dentro de uno puede mostrar un FCP engañosamente rápido.
Errores de FCP que ocultan el verdadero cuello de botella
- Tratar FCP como una Core Web Vital. FCP es un diagnóstico útil, pero LCP, INP y CLS son las Core Web Vitals que se utilizan en los sistemas de posicionamiento de Google. Usa FCP para investigar la fase de pantalla vacía, no como sustituto de los datos de campo de CWV.
- Optimizar un logotipo diminuto porque se convierte en el primer pintado. Un pintado temprano pero carente de significado puede mejorar FCP mientras el contenido útil de la página sigue llegando tarde. Comprueba LCP y la tira de película junto con FCP para que el cambio mejore lo que realmente ve el visitante.
- Empezar por comprimir imágenes cuando la página está vacía. Si nada puede pintarse, los bloqueadores habituales son el tiempo de respuesta del servidor, el CSS que bloquea el renderizado, el JavaScript síncrono o las fuentes. Sigue la cascada de solicitudes antes de cambiar recursos no relacionados.
- Comparar ejecuciones de Lighthouse no relacionadas. La emulación del dispositivo, las condiciones de red, el estado de la caché y la variación entre ejecuciones cambian el FCP de laboratorio. Compara ejecuciones repetidas con la misma configuración y confirma el resultado con datos de campo cuando estén disponibles.
El presupuesto de la pantalla vacía
Divide FCP en tres preguntas consecutivas en lugar de tratar la cifra final como un único problema:
- ¿Cuánto tarda en llegar el HTML? Inspecciona el TTFB. Una respuesta lenta impide que el navegador empiece a trabajar de forma útil, así que empieza por el servidor, la caché, las redirecciones o la configuración de la conexión.
- ¿Cuánto tarda el navegador en poder renderizar? Inspecciona las hojas de estilo que bloquean el renderizado, los scripts síncronos y el comportamiento de las fuentes. El HTML puede estar presente mientras el hilo principal o la ruta de renderizado siguen bloqueados.
- ¿Qué se convierte realmente en el primer contenido? Usa una tira de película o una traza para confirmar que el primer pintado es texto o imágenes significativos, no un elemento mínimo que mejora el aspecto de la métrica sin mejorar la experiencia.
El marco mantiene las correcciones en orden: primero la entrega, después el renderizado y por último la utilidad. Vuelve a ejecutar el mismo perfil de laboratorio después de cada cambio para saber qué fase se ha movido.
Ponte a prueba: First Contentful Paint
Cinco preguntas rápidas sobre lo que mide FCP y cómo diagnosticarlo. Elige una respuesta para cada una y luego comprueba el resultado.
Recursos que merecen tu tiempo
Google / web.dev
- First Contentful Paint (FCP): referencia canónica sobre la definición, los umbrales, el código de medición y la lista completa de optimización.
- Web Vitals: cómo se relaciona FCP con las Core Web Vitals y por qué es una métrica diagnóstica.
- Largest Contentful Paint (LCP): la métrica que FCP ayuda a diagnosticar y una Core Web Vital.
- Time to First Byte (TTFB): la métrica de respuesta del servidor que vive dentro de FCP.
Lighthouse
- First Contentful Paint audit: bandas de valoración de escritorio y cómo se calcula la puntuación.
- Lighthouse performance scoring: ponderaciones de las métricas, con FCP al 10 %.
Mis textos relacionados
- Guía de SEO técnico para principiantes: dónde encaja la velocidad de página en el panorama más amplio.
- Core Web Vitals: qué son y cómo mejorarlas: las métricas de señal de posicionamiento a las que contribuye FCP.
De todo el sector
- First Contentful Paint (FCP): artículo canónico de Google de Philip Walton, con definición, umbrales, código de la API Paint Timing y la lista completa de optimización.
- Web Vitals: marco de Google que explica dónde encaja FCP (una «Other Web Vital», complementaria a las Core Web Vitals) y su papel en el diagnóstico de LCP.
- First Contentful Paint audit: documento de Chrome Developers sobre las bandas de valoración de escritorio de Lighthouse y cómo se calcula la puntuación de FCP frente a los datos de HTTP Archive.
- Time to First Byte (TTFB): guía de Google sobre por qué TTFB precede a FCP y está incluido en él, y cómo un servidor lento consume el presupuesto de FCP antes de que el navegador pinte un solo píxel.
- Eliminate render-blocking resources: guía de Chrome Developers sobre el principal causante de FCP: el CSS y JS síncrono en <head> que impiden que el navegador pinte.
- Ensure text remains visible during webfont load: auditoría de Chrome Developers que explica los valores de font-display y por qué
blockretrasa FCP mientrasswapuoptionalmantienen visible el texto. - First Contentful Paint: guía práctica de NitroPack sobre FCP, con consejos de optimización específicos para CMS y una explicación clara de campo frente a laboratorio.
Datos que merece la pena citar
- Buen FCP = ≤ 1,8 s en el percentil 75 de usuarios reales; necesita mejoras hasta 3,0 s y es deficiente por encima de esa cifra (umbrales de campo/CrUX). Fuente
- Lighthouse para ordenadores es más estricto: ~0–0,9 s es «verde» porque el laboratorio ejecuta un entorno simulado y limitado, no condiciones reales. Fuente
- FCP representa el 10 % de la puntuación de rendimiento de Lighthouse 10 (actual al redactar estas líneas; las ponderaciones cambian entre versiones), junto a TBT 30 %, LCP 25 %, CLS 25 % y Speed Index 10 %. Fuente
- Preconectar con orígenes de terceros puede ahorrar 100–500 ms de carga al establecer conexiones con antelación. Fuente
Registro de cambios
Actualizado el 9 ago 2026.
Resumen editorial y detalles registrados del cambio.Detalles del cambio
-
Los detalles del cambio están disponibles actualmente en inglés.
-
Los detalles del cambio están disponibles actualmente en inglés.
La comparación completa no está disponible: no se archivó una instantánea anterior para esta revisión.
Actualizado el 17 jul 2026.
Resumen editorial y detalles registrados del cambio.Detalles del cambio
-
Los detalles del cambio están disponibles actualmente en inglés.
La comparación completa no está disponible: no se archivó una instantánea anterior para esta revisión.