First Contentful Paint (FCP)
First Contentful Paint (FCP) mide cuánto tarda en renderizarse en pantalla el primer fragmento de contenido, texto, imagen, SVG o lienzo no blanco, después de que el usuario solicita una página. Es el momento en que los usuarios ven la primera señal de que "esta página está respondiendo".
First Contentful Paint (FCP) mide cuánto tarda en renderizarse en pantalla el primer fragmento de contenido, texto, imagen, SVG o lienzo no blanco, después de que el usuario solicita una página. Es el momento en que los usuarios ven la primera señal de que "esta página está respondiendo".
Por qué importa
Los usuarios que miran fijamente una pantalla en blanco abandonan rápido. La investigación del Nielsen Norman Group muestra que la atención cae bruscamente una vez que la primera respuesta visual supera 1 segundo. El FCP no es hoy un Core Web Vital oficial, pero es un componente clave de la puntuación de rendimiento de Lighthouse y un indicador adelantado del LCP. Si el FCP es lento, el LCP nunca podrá ser bueno.
Umbrales
| Calificación | FCP |
|---|---|
| Bueno | ≤ 1.8s |
| Necesita mejora | 1.8 a 3.0s |
| Deficiente | > 3.0s |
Medido en el percentil 75 (p75) de los datos de usuarios reales del Chrome User Experience Report.
TTFB → FCP → LCP → INP
La carga de una página es una línea de tiempo de métricas secuenciales.
- TTFB: tiempo hasta que el servidor envía el primer byte
- FCP: tiempo hasta que se pinta el primer contenido
- LCP: tiempo hasta que se pinta el elemento de contenido más grande
- INP: tiempo hasta que una interacción del usuario responde visualmente
El orden importa: si el TTFB es lento, el FCP no puede ser rápido, y el LCP tampoco. El trabajo de rendimiento debe empezar "desde arriba".
Qué ralentiza el FCP
TTFB lento: un servidor lento ralentiza el FCP en la misma medida.
Recursos que bloquean el renderizado: el CSS externo y el JS síncrono en <head> deben descargarse y ejecutarse antes de que el navegador pueda pintar. Si son demasiados o demasiado grandes, el FCP se estanca.
Tamaño grande del DOM: miles de elementos en el HTML inicial cuestan tiempo de análisis y maquetación.
Carga de fuentes web: las fuentes personalizadas que aún no se han cargado provocan FOIT (destello de texto invisible), haciendo que el FCP parezca retrasado.
Renderizado del lado del cliente (CSR): las aplicaciones de React y Vue que pintan el contenido solo después de descargar y ejecutar el bundle de JS retrasan el FCP considerablemente.
Cómo optimizar
Mejora el TTFB: CDN, caché del lado del servidor y optimización de la base de datos, los cimientos.
Elimina los recursos que bloquean el renderizado: usa async y defer para diferir el JS. Incorpora el CSS crítico en línea y carga el resto de forma asíncrona.
Renderizado del lado del servidor (SSR): usa frameworks como Next.js, Astro o Remix para pregenerar el HTML en el servidor.
Optimización de fuentes: font-display: swap muestra el texto de respaldo de inmediato mientras se cargan las fuentes personalizadas. Usa preload solo para las fuentes críticas.
Reduce los bundles de JS: el tree shaking, la división de código y la eliminación de bibliotecas sin usar reducen el bundle inicial.
Optimización de imágenes: usa <link rel="preload"> para la imagen principal y sirve WebP o AVIF.
Herramientas de medición
- PageSpeed Insights: datos de campo de CrUX + datos de laboratorio
- Lighthouse: diagnósticos a nivel de página
- Chrome DevTools → Performance: el FCP en la línea de tiempo
- Biblioteca JS web-vitals: recopila datos de usuarios reales en tu propio sitio
Sources: