01Qué es y cómo funciona
FCP es un Core Web Vital que captura el tiempo transcurrido desde el inicio de la navegación hasta el momento en que el navegador renderiza cualquier nodo DOM visible. La medición incluye nodos de texto, imágenes, SVGs y elementos canvas que pasan a formar parte del diseño. No incluye recursos que no afectan al renderizado visual, como elementos ocultos o indicadores de carga (spinners). Los navegadores modernos exponen el FCP a través de la interfaz PerformanceObserver, lo que permite que las librerías de JavaScript registren e informen de la métrica en tiempo real.
FCP te indica el momento en que la página muestra algo que puedes ver. Es la primera pista visual de que la página se está cargando.
02Qué hacer al respecto
Para mejorar el FCP puedes: inline critical CSS para que el contenido above-the-fold se renderice sin esperar a las hojas de estilo externas; use responsive images con tamaños apropiados y elementos picture; lazy‑load offscreen images para reducir la carga inicial de recursos; reduce server response time optimizando las consultas del backend y utilizando un CDN; minify and defer non‑critical JavaScript; y cache static assets de forma agresiva. Estas acciones suelen reducir cientos de milisegundos del primer renderizado.
03Cómo se mide o se detecta
Puedes ver el FCP en varias herramientas: el Performance panel en Chrome DevTools (busca en la Timeline), Lighthouse audits (disponibles en la pestaña Audits) y PageSpeed Insights, que reporta la métrica en su sección de Core Web Vitals. Se puede añadir la Web Vitals JavaScript library a una página para capturar el FCP de forma programática. Para datos de campo, Chrome User Experience Report (CrUX) agrega el FCP de usuarios reales y es accesible a través de Google Search Central.
04Errores comunes
- Ignorar el CSS/JS que bloquea el renderizado y retrasa el primer renderizado.
- Colocar imágenes de tipo hero de gran tamaño antes del fold sin optimización.
- No cachear los recursos estáticos, lo que provoca descargas repetidas.
- Medir el FCP en páginas que cargan contenido mediante AJAX después del renderizado inicial.
- Centrarse en el FCP promedio mientras se ignora la experiencia de usuario del percentil 75.
05Límites
FCP no se aplica a las single‑page applications que cargan contenido dinámicamente después de la carga inicial de la página; la métrica solo reflejará el primer renderizado estático. Tampoco captura cambios visuales posteriores, por lo que una página que actualiza un gráfico después de 2 segundos seguirá teniendo un FCP temprano. Confundir FCP con Largest Contentful Paint (LCP) es un error común; LCP mide el elemento visible más grande, mientras que FCP mide el primer elemento visible.
06Ejemplo práctico
"Si una página carga una imagen hero de 200 KB después de 800 ms, el FCP es de 800 ms. Cualquier texto que aparezca antes establecerá el FCP en esa marca de tiempo anterior".
07Preguntas frecuentes
¿En qué se diferencia First Contentful Paint de Largest Contentful Paint?
FCP marca el momento en que cualquier contenido visible aparece por primera vez en pantalla, mientras que LCP espera a que se renderice el elemento único más grande. FCP trata sobre qué tan rápido ven los usuarios algo; LCP trata sobre qué tan rápido termina de cargarse el contenido principal. Ambos son Core Web Vitals, pero responden a preguntas diferentes sobre la velocidad percibida.
¿Qué se considera el "primer contenido" para FCP?
Cualquier elemento del DOM visible renderizado por el navegador califica: texto, imágenes, elementos <canvas> que no estén en blanco o incluso SVGs. Los colores de fondo y los cambios en un elemento ya renderizado no cuentan. El navegador simplemente registra la marca de tiempo del primer renderizado que califique después de que comienza la navegación.
¿Debería optimizar el FCP incluso si mi LCP ya es bueno?
Por lo general sí, porque el FCP y el LCP reflejan diferentes etapas de la experiencia de carga. Un LCP rápido aún puede sentirse lento si los usuarios se quedan mirando una pantalla en blanco esperando el primer byte de contenido. Mejorar el FCP le asegura a los usuarios que la página realmente está funcionando, lo que reduce las tasas de rebote en conexiones lentas.
¿Cuál es un buen puntaje de FCP para alcanzar como objetivo?
Google clasifica un FCP de 1.8 segundos o menos como bueno, entre 1.8 y 3.0 segundos como que necesita mejorar, y más de 3.0 segundos como deficiente. Estos umbrales provienen de datos de rendimiento de usuarios reales recopilados a través del Chrome User Experience Report.
¿Puedo medir el FCP sin implementar RUM (Real User Monitoring)?
Sí. Las herramientas de laboratorio como Lighthouse y el panel Performance de Chrome DevTools reportan el FCP para una única carga simulada. Para usuarios reales, necesitas la biblioteca JavaScript Web Vitals o un proveedor de RUM que lea las entradas paint-timing y las envíe de vuelta a tu endpoint de analítica.
08Preguntado en voz alta
El mismo término en las palabras que alguien usa al hablar con un asistente en lugar de escribir en un buscador: escrito desde la situación, y por eso cada pregunta lleva la situación de la que salió.
Lighthouse realiza una única carga simulada en una máquina rápida, por lo que puede pasar por alto lo que experimentan los visitantes reales en redes lentas. Abre Chrome DevTools y limita la red a Slow 4G mientras grabas un rastro de Performance, y observa cuándo aparece realmente el primer texto o imagen. Esa marca de tiempo es tu FCP, y si es superior a unos 1,8 segundos, tus visitantes estarán mirando una pantalla en blanco aunque la puntuación de laboratorio parezca estar en verde.
First Contentful Paint suele estar bloqueado por el trabajo de la ruta de renderizado (render-path), no por el HTML en sí: el servidor tiene que enviar una respuesta que el navegador pueda empezar a pintar inmediatamente, el CSS crítico tiene que estar integrado (inlined) y las fuentes web deben estar configuradas para que no oculten el texto. Si incluyes el CSS de la parte superior (above-the-fold) de forma inline, precargas los archivos de fuentes y sirves imágenes en formatos modernos con ancho y alto explícitos, verás cómo el FCP disminuye en la próxima prueba.
Sí, FCP sigue siendo un Core Web Vital y sigue apareciendo en Search Console y CrUX, por lo que ignorarlo significaría perder una señal sobre la que se puede actuar. El INP reemplazó al FID, no al FCP, y las dos métricas miden cosas distintas: FCP es la velocidad de carga, el INP es la interactividad después de que la página se ha cargado. Necesitas ambas porque una página puede renderizarse rápidamente y, aun así, sentirse lenta al hacer clic, o sentirse ágil al hacer clic pero dejar a los usuarios mirando una pantalla en blanco durante dos segundos.