Entras en la web de un competidor y, durante un segundo, solo ves el fondo del navegador: ni logo, ni menú, ni titular. Ese primer instante en blanco condiciona si el visitante espera o abandona. El FCP (First Contentful Paint) mide cuándo aparece el primer píxel útil —texto, imagen o icono— en pantalla. En 2026 sigue siendo una señal clave en webs de empresa, sobre todo en móvil y en campañas de pago donde cada fracción de segundo cuenta.
Este artículo explica qué captura FCP, qué umbrales usar como referencia, cómo se relaciona con TTFB, LCP, CLS e INP, y qué cambios suelen adelantar la primera impresión visual sin renunciar al diseño de marca.
Qué es FCP y qué mide exactamente
FCP marca el momento en que el navegador pinta por primera vez contenido del DOM que el usuario puede ver: un titular, el logotipo, un párrafo del hero o una imagen de cabecera. No incluye el fondo del documento ni contenido fuera del viewport si aún no se ha renderizado.
- Empieza cuando el usuario solicita la URL (tras redirecciones).
- Termina cuando cualquier texto, imagen, SVG o canvas visible se muestra en pantalla.
- No mide interactividad (eso es INP) ni el elemento más grande (eso es LCP).
- Depende del HTML, CSS crítico, fuentes y del TTFB: sin HTML, no hay primer pintado.
La documentación de web.dev sobre FCP detalla qué elementos cuentan como «contenido» y cómo encaja en el desglose de rendimiento de Lighthouse.
Umbrales orientativos en 2026
Lighthouse y PageSpeed Insights siguen usando estas referencias para FCP en el percentil de la medición de laboratorio o campo:
- Bueno: 1,8 s o menos.
- A mejorar: entre 1,8 s y 3,0 s.
- Pobre: por encima de 3,0 s.
En CrUX (datos reales de Chrome) compara home, fichas de producto y formularios de contacto por separado. Un FCP aceptable en desktop puede ser pobre en 4G si el hero pesa demasiado o las fuentes bloquean el texto.
FCP frente a TTFB, LCP, CLS e INP
Los Core Web Vitals no compiten entre sí: se encadenan. Un TTFB alto retrasa la descarga del HTML y empuja FCP hacia adelante. Un FCP lento suele anticipar un LCP malo si el bloque principal del hero es pesado. El CLS puede empeorar si adelantas FCP sin reservar espacio para imágenes o fuentes.
Prioriza FCP cuando el usuario percibe «pantalla en blanco», cuando el menú o el titular tardan en aparecer tras el spinner del navegador, o cuando campañas de ads muestran alta tasa de rebote en móvil pese a un LCP posteriormente aceptable.
Causas habituales en webs de empresa
- CSS y JavaScript bloqueantes en el <head> que retrasan el primer render.
- Fuentes web sin estrategia (FOIT/FOUT) que ocultan el texto del hero.
- Imágenes del cabecero sin optimizar o sin dimensiones, aunque el LCP sea otro elemento.
- HTML generado tarde por backend lento o APIs síncronas en plantilla.
- Demasiados recursos en la ruta crítica antes del primer pintado.
- Redirecciones en cadena que suman latencia antes de cualquier contenido.
Formatos modernos como WebP y AVIF ayudan al LCP, pero FCP mejora sobre todo reduciendo lo que el navegador necesita antes de pintar la primera capa visible.
Cómo medir FCP con herramientas accesibles
- PageSpeed Insights / Lighthouse: métrica «First Contentful Paint» en rendimiento.
- Chrome DevTools → Performance: marca FCP en la línea de tiempos al grabar una carga.
- Search Console → Experiencia de página: tendencias de URLs con problemas de velocidad.
- WebPageTest: filmstrip que muestra el fotograma exacto del primer contenido.
Mide con extensiones de throttling en móvil y con caché fría en la URL del HTML. Repite en la plantilla de blog y en la home: suelen compartir cabecera pero no el mismo peso de hero.
Acciones que suelen mejorar FCP
CSS crítico y orden de recursos
Inline o prioriza el CSS necesario para el header, el titular y el fondo del hero. Retrasa estilos de módulos inferiores. Aplica la misma disciplina que en minificación de CSS y JS: menos bytes en la ruta crítica, no solo en el total de la página.
Fuentes y texto visible
Usa font-display: swap o subconjuntos que cubran el hero. Evita ocultar todo el texto hasta cargar la familia completa. Si el logotipo es texto web, asegura que el fallback del sistema se pinte de inmediato.
Servidor y caché del documento
Recorta TTFB con caché de página en rutas públicas y consultas optimizadas. Un HTML que llega 400 ms antes suele adelantar FCP casi lo mismo. Complementa con CDN cerca de tus usuarios.
Imágenes above the fold
Comprime el logo y el hero, define width/height y evita lazy loading en lo que el usuario ve primero. Usa preload solo para uno o dos recursos realmente críticos.
Scripts de terceros
No cargues chat, mapas o tags de analítica antes del primer pintado. Sigue las pautas de scripts de terceros: diferir lo que no es imprescindible para mostrar la cabecera y el mensaje principal.
Errores que mantienen el FCP alto
- Optimizar solo el vídeo del hero cuando el retraso está en CSS o fuentes del titular.
- Añadir un spinner a pantalla completa que retrasa la percepción de contenido real.
- Preload de media docena de archivos «por si acaso», saturando la red inicial.
- Ignorar redirecciones HTTP→HTTPS→www que consumen tiempo antes del HTML.
Checklist antes de cerrar una mejora
- ¿FCP mejoró en Lighthouse con throttling móvil en la URL del HTML?
- ¿El filmstrip de WebPageTest muestra texto o logo antes que antes?
- ¿LCP y CLS en las mismas páginas no empeoraron?
- ¿El branding (colores, tipografía) sigue siendo coherente tras inline de CSS crítico?
Conclusión
FCP responde a una pregunta directa: «¿Cuándo ve el visitante que la web ha empezado a cargar de verdad?». En una web de empresa, adelantar ese momento reduce rebote, refuerza confianza y prepara el terreno para un buen LCP e INP. Mide en tus URLs que más convierten, ataca la ruta crítica del primer pantallazo y valida el impacto junto al resto de métricas de rendimiento.
Si quieres un plan priorizado de velocidad y Core Web Vitals con cambios acotados a tu stack, en AATSOFT auditamos plantillas, origen y recursos críticos y proponemos mejoras con impacto medible en conversión.
