First Contentful Paint (FCP): Qué es, cómo medirlo y corregirlo

Corrige el First Contentful Paint

El First Contentful Paint (FCP) es el momento en el que un navegador dibuja el primer elemento significativo en una página para que el visitante lo vea. En otras palabras, es el momento en que un navegador renderiza algo en la pantalla por primera vez. Por ello, el FCP es una buena forma de medir la velocidad de carga percibida de la página.

Puedes mejorar el FCP asegurándote de que un navegador pueda empezar a renderizar sin ningún retraso. A continuación aprenderás qué es el FCP, cómo medirlo y 15 técnicas probadas para hacerlo más rápido.

¿Qué es el First Contentful Paint (FCP)?

El First Contentful Paint (FCP) es una forma de medir la velocidad de carga de la página. No puedes resumir la velocidad de la página como un momento en el tiempo; en realidad hay varios momentos durante el proceso de carga donde un visitante podría percibir que el sitio carga rápido o lento. El FCP mide la diferencia de tiempo entre solicitar la página y cuando el primer contenido significativo se renderiza en la pantalla por primera vez.

¿Qué te dice exactamente eso? Te dice que el FCP es principalmente una "métrica centrada en el usuario" porque dice algo sobre la velocidad de carga que experimenta un visitante. Dice algo sobre la UX. En el momento del FCP, puedes estar seguro de que un visitante realmente ve "algo" en la pantalla.

Vamos a desglosar las palabras: 'First', 'Contentful' y 'Paint'.

1. First: Con "First" (primero), por supuesto, nos referimos al primer momento exacto en el que aparece algo sustancial en tu navegador.
2. Contentful: Con "contentful" (con contenido) nos referimos a un elemento HTML con contenido. No es un elemento de diseño como un elemento en blanco o un color de fondo, sino más bien algo de texto, una imagen (incluyendo imagen de fondo), SVG o canvas.
3. Paint: "Paint" (pintar) significa (más o menos) que el navegador está listo para poner algo en la pantalla. Esto parece simple pero en realidad es la tarea más complicada del navegador. Para poner algo en la pantalla, un navegador debe estar listo para calcular todas las características de un elemento. A continuación hay un ejemplo del proceso de renderizado que se requiere antes de que se pueda añadir cualquier cosa a la pantalla.

FCP vs. LCP: ¿Cuál es la diferencia?

El FCP y el LCP (Largest Contentful Paint) miden el rendimiento de carga, pero capturan momentos diferentes en la línea de tiempo de carga de la página. Entender la diferencia te ayuda a priorizar tu trabajo de optimización correctamente.

En la práctica, el FCP suele dispararse mucho antes que el LCP. Por ejemplo, una página puede renderizar un encabezado (FCP) en 400 ms pero esperar otros 2 segundos para cargar la imagen hero (LCP). Si tu FCP es lento, tu LCP casi seguro también será lento, porque el FCP captura el primer cuello de botella en el pipeline de renderizado. Lee más en nuestra guía completa de LCP.

¿Qué es un buen First Contentful Paint?

Un buen FCP es cualquier valor por debajo de 1,8 segundos. Si tu FCP está entre 1,8 y 3 segundos, necesita mejorar. Cualquier FCP superior a 3 segundos se considera pobre. Para cumplir con el umbral recomendado para el First Contentful Paint, al menos el 75% de tus visitantes deben tener un "buen" FCP.

Como siempre con las métricas de rendimiento, un First Contentful Paint más rápido es mejor que uno lento.

¿Cómo mides tu First Contentful Paint (FCP)?

Google mide el FCP recopilando datos de usuarios reales. Esos datos se almacenan en el dataset de CrUX. Esos datos están disponibles públicamente a través de la API de CrUX o Google BigQuery. El FCP también se puede medir mediante las llamadas pruebas de laboratorio. La prueba de laboratorio más común se llama Lighthouse.

Obtener el First Contentful Paint del dataset de CrUX

El First Contentful Paint se puede leer del dataset de CrUX a través de pagespeed.web.dev, la API de CrUX o a través de Google BigQuery.

Medir el First Contentful Paint a través del Real User Monitoring (RUM)

RUM Tracking significa Real User Monitoring. Con el Real User Monitoring puedes rastrear el First Contentful Paint a través de interacciones de usuarios reales. La ventaja del RUM es que no tienes que esperar 28 días para obtener datos nuevos y los datos se pueden consultar y analizar con mucho más detalle.

Medir el FCP en Lighthouse

1. Abre la página (en Chrome) cuyo FCP quieres medir. Asegúrate de hacerlo de incógnito para que las extensiones no interfieran y posiblemente ralenticen el FCP de tu página.
2. Haz clic derecho en la página y selecciona Inspeccionar. De esta forma abres la consola de desarrolladores de Chrome.
3. En la parte superior de la consola, verás la pestaña Lighthouse. Haz clic en ella. Luego, en Categories, elige Performance (deja las otras en blanco) y elige Mobile en Device.
4. Ahora haz clic en Generate report. Lighthouse creará un informe de velocidad de tu página. En la esquina superior izquierda del informe, verás cuál es el FCP de tu página.

Esta es una captura de pantalla del informe de Lighthouse para esta página. ¡El FCP de esta página en un dispositivo móvil es de 0,8 segundos! No está mal, ¿verdad?

Medir el FCP con una herramienta online

También puedes medir el FCP con varias herramientas online. Las más conocidas son GTMetrix, pingdom y pagespeed.web.dev. Es fácil trabajar con estas herramientas y te darán datos sobre el FCP bajo circunstancias de laboratorio específicas.

Lo que muestran los datos reales del FCP

Los datos de CoreDash muestran que el FCP sigue de cerca al TTFB: el p75 del FCP es 392 ms en general, con desktop en 372 ms y móvil en 692 ms (1,9 veces más lento). El delta del FCP respecto al TTFB es de solo 248 ms en desktop y 376 ms en móvil. Esto indica que el tiempo de render blocking representa una parte relativamente pequeña del FCP en un sitio bien optimizado.

Globalmente, según el Web Almanac 2025, el 70% de las páginas en desktop consiguen un buen FCP, mientras que solo el 55% de las páginas móviles lo hacen. Ambas mejoraron desde 2024, con el móvil ganando 4 puntos porcentuales. Esto sugiere que los desarrolladores web están solucionando cada vez más los recursos render blocking.

La fuerte correlación entre el FCP y el TTFB significa que mejorar tu Time to First Byte suele ser la forma más efectiva de mejorar tu First Contentful Paint. En este sitio, el FCP está solo unos 250 ms por encima del TTFB. Esto significa que la mayor parte del tiempo del FCP se gasta esperando a que el servidor responda en lugar de en trabajo de render blocking.

Mejorar el First Contentful Paint

Es hora de hacer el FCP más rápido. La idea detrás de un FCP rápido es en realidad bastante simple: asegurarte de que un navegador pueda empezar a renderizar inmediatamente. Cualquier cosa que pueda causar que el renderizado se retrase resultará en un FCP pobre.

Al igual que con el Largest Contentful Paint, el First Contentful Paint se puede desglosar en 2 o 4 categorías:

1. Time to First Byte (TTFB): El tiempo desde que el navegador empieza a cargar la página hasta que recibe el primer byte del HTML.
2. Resource load delay: El tiempo entre el TTFB y cuando el navegador empieza a cargar el recurso del FCP.
3. Resource load time: El tiempo que tarda en cargar el propio recurso del FCP.
4. Element render delay: El tiempo entre que el recurso del FCP terminó de cargar hasta que el elemento del FCP se renderiza completamente.

Consejo de velocidad: Puedes eliminar fácilmente los pasos 2 y 3 asegurándote de que el elemento del FCP no requiera un recurso de red. En el caso de un elemento de texto, considera usar font-display:swap. En el caso de un elemento de imagen pequeño, considera colocar la imagen inline.

Esto solo nos deja el Time to First Byte y el Element Render delay para optimizar.

A continuación tienes 14 soluciones que suelo usar para mejorar el FCP. Pero ten cuidado, usar una solución en el lugar equivocado puede crear retrasos. Por eso es mejor consultar a un experto en pagespeed antes de empezar tú mismo.

1. Respuesta del servidor rápida (TTFB)

El TTFB (el tiempo entre la petición y el primer byte que envía el servidor) es siempre el primer paso en el proceso de renderizado. A partir de ese momento, tu navegador empieza a realizar múltiples tareas a la vez, y el impacto de más optimizaciones empieza a disminuir. El código HTML es la única petición que afecta directamente a todas las métricas de velocidad.

La velocidad a la que el código HTML se envía desde el servidor suele medirse como el Time to First Byte (TTFB). Es importante hacer esto lo más rápido posible. A menudo lo haces activando la caché del lado del servidor.

Cuando se trata del Time to First Byte, un número más bajo siempre es mejor.

Puedes medir el Time to First Byte tú mismo fácilmente. Se hace de la siguiente manera:

1. Usa el atajo Ctrl-Shift-I para abrir la consola de desarrolladores de Google Chrome.
2. En la parte superior de la consola, verás una pestaña Network. Haz clic en ella.
3. Recarga la página con Ctrl-R.
4. Ahora verás todas las peticiones de red que Chrome ha enviado a tu servidor.
5. Haz clic en la primera petición de red, que es la petición de tu propia página.
6. Ahora obtendrás más información sobre esta petición de red. Haz clic en la pestaña Timing en la parte superior de esta información para ver cuál es el TTFB de tu página.

2. HTTP/3

HTTP/3 es la tercera versión del protocolo HTTP. HTTP/3 resuelve muchos de los problemas que se encuentran en los protocolos más antiguos HTTP/1.1 y HTTP/2. Por ejemplo, desde HTTP/2, puedes enviar múltiples archivos al mismo tiempo a través de la misma conexión. HTTP/3 proporciona una conexión inicial más rápida y menos problemas ante pequeñas interrupciones de red.

Sin entrar en muchos detalles, HTTP/3 permite una ganancia de velocidad significativa, especialmente en una red más lenta como una red móvil. Tu administrador de red puede decirte si tu servidor web ya está adaptado para el protocolo HTTP/3, que es más rápido.

Puedes comprobar tú mismo si tu sitio web ya está usando el protocolo HTTP/3. Usa el atajo Ctrl-Shift-I para abrir el inspector de red de Google Chrome. Haz clic derecho en la cabecera de la tabla y selecciona Protocol. Ahora recarga la página para ver qué protocolo está usando tu sitio.

3. 103 Early Hints

Los 103 Early Hints son un código de estado HTTP relativamente nuevo que permite a un servidor enviar cabeceras de respuesta preliminares antes de que la respuesta final esté lista. Esto es especialmente útil cuando tu servidor necesita tiempo para generar el HTML (por ejemplo, al consultar una base de datos o ejecutar lógica en el servidor). En lugar de hacer que el navegador espere inactivo, el servidor envía una respuesta 103 con hints de preload y preconnect para que el navegador pueda empezar a obtener recursos críticos inmediatamente.

Esto mejora directamente el FCP porque el navegador puede empezar a descargar fuentes, hojas de estilo y otros recursos críticos para el renderizado incluso antes de que llegue el HTML. El impacto es más significativo en páginas con un TTFB alto.

HTTP/1.1 103 Early Hints
Link: </static/font/outfit.woff2>; rel=preload; as=font; type=font/woff2; crossorigin
Link: </static/css/critical.css>; rel=preload; as=style

HTTP/1.1 200 OK
Content-Type: text/html
...

No todos los proveedores de hosting soportan 103 Early Hints todavía. Cloudflare tiene soporte integrado para Early Hints, y Apache y Nginx se pueden configurar para enviarlos. Lee más en nuestra guía completa de 103 Early Hints.

4. Caché del navegador

La conexión de red suele ser un eslabón débil en lo que respecta a la velocidad de la página. ¿No sería mucho más fácil saltarse la red por completo?

Cuando un visitante ha estado en tu sitio antes, puedes indicar si los recursos de red (por ejemplo, una hoja de estilo) se pueden almacenar en el navegador del visitante y por cuánto tiempo. Cada vez que el visitante necesite uno de estos archivos de nuevo, aparecerán de la caché del navegador en un instante. Como resultado, el navegador puede empezar a renderizar mucho más rápido y acelerar el FCP.

5. Compresión

La velocidad de la red es, en casi todos los casos, un eslabón débil. Para un buen First Contentful Paint, es importantísimo que los archivos se envíen a través de la red lo más rápido posible. La compresión reduce la cantidad de bytes que se deben enviar desde el servidor; menos bytes significan menos tiempo esperando por un recurso de red. La compresión, en mi opinión, es una técnica que no está recibiendo la atención que merece. Desafortunadamente, demasiados webmasters "encienden la compresión" y luego no vuelven a prestarle atención. Y es una pena, porque es una forma sencilla de hacer que las cosas vayan un poco más rápido.

Hay dos técnicas de compresión populares: Gzip y Brotli. Gzip es la técnica de compresión más usada, pero Brotli la está alcanzando rápidamente. Brotli fue creado por el propio Google y tiene resultados entre un 15 y un 20% mejores cuando se trata de archivos HTML, JavaScript o CSS. Brotli es, por lo tanto, ideal para la web.

También hay una diferencia entre la compresión dinámica y la compresión estática. Con la compresión dinámica, comprimes el archivo justo antes de enviarlo a través de tu servidor web; con la compresión estática, el archivo comprimido se almacena en el servidor. Esta suele ser una forma mucho más inteligente de comprimir, pero rara vez se usa.

6. Web fonts tempranas con resource hints

Los resource hints inician una descarga o conexión de red antes de que el navegador lo haga por sí mismo. Algunos recursos de red, como web fonts o imágenes, solo se descargan después de que el navegador esté seguro de que necesita mostrarlos.

Si estás seguro de que necesitas un recurso para renderizar la parte visible del sitio, casi siempre es buena idea incluir un "resource hint". Esto asegurará que el navegador empiece a descargar o a conectarse al recurso inmediatamente. Como resultado, el recurso está disponible antes y el navegador puede empezar a renderizar antes.

Pero ten cuidado con los resource hints. Si los usas incorrectamente, en realidad pueden ralentizar tu página.

Descarga temprana con "preload"

<link rel="preload" href="/static/font/opensans600.woff2" as="font" type="font/woff2" crossorigin>

El link preload es una de las herramientas más potentes en el arsenal del pagespeed. A través del link preload, descargas un recurso de red que necesitarás más adelante. Esto suele ser muy buena idea con las fuentes, los scripts críticos y las imágenes en la parte visible del sitio.

Conectarse con anticipación con preconnect

El link preconnect conecta por adelantado con un servidor. Esto es útil cuando alojas archivos en un servidor de terceros como un CDN o Google Analytics.

<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>

Incluso mejor que hacer preconnect a Google Fonts es hacer self-hosting de tus Google Fonts. Esto elimina por completo la conexión a terceros y te da control total sobre la caché y la entrega.

7. Haz prefetch de la siguiente página con prefetch

<link rel="prefetch" href="/page2.html">

Con prefetch, puedes obtener recursos de baja prioridad. Es una forma útil de obtener recursos que crees que necesitarás más tarde, por ejemplo, cuando esperas que alguien haga clic en el enlace a la siguiente página.

8. Evita las redirecciones

Un error común es tener una cadena de redirecciones demasiado larga. Déjame explicarte: tu sitio probablemente funciona a través de una conexión segura. Cuando un visitante escribe tu sitio sin añadir https, el visitante será redirigido a la versión no segura de tu sitio web. Sin embargo, si todo está bien configurado, el visitante será redirigido al sitio web seguro. Puedes ver esto en el ejemplo verde de abajo.

Pero a veces la redirección se realiza a través de uno o más pasos intermedios, como se muestra en el ejemplo rojo. Son estos pasos intermedios los que provocan que el sitio web funcione lento, resultando en un FCP pobre. Cada paso intermedio cuesta tiempo extra, que se puede acumular rápidamente. Por lo tanto, asegúrate siempre de llegar a la página correcta con una sola redirección.

9. Minimizar el CSS

Un archivo CSS externo es siempre render blocking. Lo que eso significa es que un navegador normalmente no puede empezar a mostrar el contenido hasta que todas las hojas de estilo se hayan descargado y analizado. Por lo tanto, es mejor mantener las hojas de estilo lo más pequeñas posible. De esta manera no tienes que esperar tanto para que se descargue la hoja de estilo. Para una guía más completa, lee nuestro artículo sobre cómo corregir y eliminar CSS no utilizado.

Reducir el tamaño del CSS usando propiedades abreviadas

Una de las formas de reducir el tamaño del CSS es usar shorthand properties. Estas son propiedades en una sola línea que te permiten escribir las características más importantes de un selector de CSS en un solo lugar.

body{
    font-style: normal;
    font-weight: 400;
    font-stretch: normal;
    font-size: 0.94rem;
    line-height: 1.6;
    font-family: "Segoe UI", "Segoe UI", system-ui, -apple-system, sans-serif;
}

También puedes escribirlo como:

body{font: 400 .94rem/1.6 Segoe UI,Segoe UI,system-ui,-apple-system, sans-serif;}

Reducir aún más el tamaño del CSS

Es posible reducir el tamaño del CSS aún más agrupando selectores con una coma, eliminando saltos de línea y espacios, y escribiendo códigos de color más cortos.

h1{
  color : #000000;
}
h2{
  color : #000000;
}
h3{
  color : #000000;
}
h4{
  color : #000000;
}
h5{
  color : #000000;
}

Podría acortarse a:

h1,h2,h3,h4,h5{color:#000}

10. Critical CSS

Podemos llevar el CSS un paso más allá usando el critical CSS. El critical CSS es indispensable para un sitio web rápido y un First Contentful Paint rápido.

El critical CSS es una colección de todos los selectores (como body, p, h1, etc.) que necesitas para mostrar la parte visible de la página. No pongas este critical CSS en una hoja de estilo separada; en su lugar, añádelo directamente en el <head> de la página. De esta manera, no tienes que descargar un archivo nuevo y el navegador puede empezar a renderizar a la velocidad del rayo. Esto hace que el FCP sea más rápido. El CSS que no necesitas directamente para la parte visible de la página se carga después de que se complete el primer ciclo de renderizado. Para tu visitante, la página ya está terminada; nadie notará que los nuevos estilos se siguen añadiendo en segundo plano.

El critical CSS se puede generar fácilmente con nuestra propia herramienta de critical CSS. Simplemente pega la URL de tu página web en la herramienta y nosotros haremos el resto por ti.

Ejemplo de critical CSS inline

<head>
  <style>
    /* Critical CSS: only what is needed for above-the-fold content */
    body{font:400 1rem/1.6 system-ui,sans-serif;margin:0}
    h1{font-size:2rem;margin:.5em 0}
    .hero{padding:2rem;background:#f5f5f5}
  </style>
  <!-- Non-critical CSS loaded asynchronously -->
  <link rel="preload" href="/css/full.css" as="style" onload="this.onload=null;this.rel='stylesheet'">
  <noscript><link rel="stylesheet" href="/css/full.css"></noscript>
</head>

11. Aplazar la carga de JavaScript

Una de las razones más comunes para un First Contentful Paint lento es el JavaScript. Dependiendo de cómo uses el JavaScript, puede bloquear el renderizado de la página. Normalmente, el JavaScript se descarga y ejecuta antes de que se construya el árbol de renderizado. Sin el árbol de renderizado, un navegador no puede poner nada en la pantalla, y eso incluye el FCP. Para un resumen completo de las técnicas de aplazamiento, lee 14 métodos para aplazar el JavaScript.

Podemos evitar esto aplazando el JavaScript. Puedes hacer esto de tres maneras.

JavaScript asíncrono

<script async src="async.js"></script>

Al añadir el atributo async a una etiqueta script, la construcción de la página ya no se bloquea mientras se descarga el JavaScript. El atributo async indica que la descarga y la construcción del árbol de renderizado pueden ocurrir al mismo tiempo.

Una vez que el script se ejecuta, la página se bloquea. En la mayoría de los casos, gracias al atributo async, el navegador ha tenido tiempo suficiente para construir una parte importante de la página, con el First Contentful Paint ya en la pantalla.

Aplazar el JavaScript (Defer)

<script defer src="deferred.js"></script>

El atributo defer funciona más o menos igual que el atributo async. Al añadir el atributo defer a una etiqueta script, el script también puede descargarse simultáneamente a la construcción de la página. Después de que todos los scripts se descargan, se ejecutan en el orden en el que se encontraron en el código HTML. Esto también puede bloquear la visualización de la página, pero en muchos casos el First Contentful Paint ya está en la pantalla.

12. No dependas de recursos externos

Los recursos externos, como fuentes externas, imágenes externas, hojas de estilo externas o scripts externos, son un posible cuello de botella en lo que respecta al First Contentful Paint. Como no tienes control sobre el servidor donde se alojan los archivos, no sabes a qué velocidad se enviarán. Además, no puedes usar la conexión existente con el servidor web. Se debe establecer una nueva conexión con un nuevo servidor, y eso requiere tiempo.

Uno de los recursos externos más comunes en la web son las Google Fonts. Hacer self-hosting de tus Google Fonts elimina por completo una conexión a terceros y te da un control total sobre la caché, la compresión y el comportamiento del font-display.

Recursos externos bloqueantes

Sin recursos externos

13. Usa el formato de fuente correcto

Las fuentes merecen una atención especial cuando se trata del First Contentful Paint. En aproximadamente el 99% de las páginas que revisamos, el elemento del FCP es una línea de texto. Cuando usas web fonts externas, primero debes descargar estas fuentes desde un servidor, lo que por supuesto lleva tiempo.

Recientemente, las web fonts han estado recibiendo más atención, y existen formatos de fuente nuevos y más rápidos. El formato de fuente más rápido en este momento es woff2, seguido de woff. Woff2 es soportado por todos los navegadores modernos.

Puedes especificar el orden preferido de tu web font en la declaración font-face de CSS. Lo haces de la siguiente manera:

 @font-face {
   font-family: 'myFont';
   font-weight: 400;
   font-style: normal;
   font-display: swap;
   unicode-range: U+000-5FF
   src: local('myFont'),
        url('/fonts/myFont.woff2') format('woff2'),
        url('/fonts/myFont.woff') format('woff');
}

14. Font-display: swap

Al usar web fonts, el comportamiento por defecto de estas fuentes es no mostrar el texto en la página hasta que la fuente se haya cargado. Esto suele ir directamente en detrimento del First Contentful Paint. Lee nuestra guía completa sobre cómo asegurar que el texto permanezca visible mientras se carga la webfont.

Puedes solucionar esto usando la declaración font-display:swap. Con ella puedes elegir mostrar el texto en la página de todas formas, en una fuente que el navegador conozca, mientras la webfont se carga en segundo plano.

Sin font-display:swap

Con font-display:swap

font-display: swap vs optional

Hay dos estrategias comunes de font-display para la optimización del FCP:

/* swap: Shows fallback font immediately, swaps when webfont loads */
@font-face {
  font-family: 'MyFont';
  font-display: swap;
  src: url('/fonts/myfont.woff2') format('woff2');
}

/* optional: Shows fallback font, only uses webfont if already cached */
@font-face {
  font-family: 'MyFont';
  font-display: optional;
  src: url('/fonts/myfont.woff2') format('woff2');
}

Usar font-display: swap garantiza el FCP más rápido posible porque el texto se renderiza inmediatamente en la fuente fallback. Usar font-display: optional evita por completo el parpadeo de texto sin estilo (FOUT) en la primera visita, pero la webfont solo se mostrará si ya está en la caché del navegador. Para la mayoría de sitios, swap es la mejor opción para el FCP.

15. Minimiza el tamaño del DOM

Una página web está formada por HTML. Lo primero que hace un navegador es convertir el HTML en nodos del DOM. Esa es una estructura de árbol de elementos HTML que se usa más adelante para construir el árbol de renderizado. A partir del árbol de renderizado un navegador comienza el renderizado; al final la página web aparece en la pantalla.

La cantidad de nodos del DOM (elementos HTML) que tienes y lo profundos que son estos nodos en la estructura del árbol determina lo complicado que es para un navegador construir tu página. El CSS y el JavaScript también tardan más tiempo en analizarse cuando tienes demasiados nodos del DOM. Esto, de nuevo, va directamente en detrimento del FCP.

Soluciona esto de la siguiente manera:

• Aplica lazy loading en partes de tu página web
  Para acelerar la visualización inicial, considera cargar partes de tu sitio web, como el footer, mediante AJAX en un momento posterior.
• Haz uso de content-visibility
  La propiedad CSS content-visibility le dice a un navegador que se salte el style, el layout y el paint durante el renderizado. Lo hace justo antes de que el elemento se vuelva visible.
• Divide las páginas grandes en múltiples páginas
  El número de nodos del DOM se puede reducir dividiendo las páginas grandes en múltiples páginas.
• Implementa el scroll infinito
  El scroll infinito es básicamente lazy loading: cuando haces scroll por elementos repetidos como imágenes (Pinterest) o grandes tablas de datos, el scroll infinito puede acelerar significativamente tu página.
• Evita la interacción del JavaScript con el DOM
  Ten mucho cuidado con el JavaScript cuando tienes un gran número de nodos del DOM en tu página. Un comando como querySelectorAll puede cargar una gran cantidad de nodos del DOM y aumentar el uso de memoria.
• Evita declaraciones CSS complicadas
  Ten mucho cuidado con comandos CSS complicados si tienes un gran número de nodos del DOM. Por ejemplo, comprobar el estado de last-child para cada elemento div en tu página puede ser costoso.
• Usa web workers para liberar el main thread de tu navegador
  Los web workers son JavaScript que puede ejecutarse en paralelo con tu página web. Puedes darle comandos a estos web workers para que los ejecuten en segundo plano. Cuando el web worker ha ejecutado el comando, se lo pasa a la página original. La ventaja de esto es que puedes seguir ejecutando JavaScript complejo sin que la página se quede congelada.

Guías de optimización relacionadas

Mejorar el FCP requiere trabajo en múltiples áreas. Aquí tienes nuestras guías más relevantes:

• Hacer self-hosting de tus Google Fonts: Elimina una conexión a terceros y obtén un control total sobre la entrega de fuentes.
• Asegurar que el texto permanezca visible mientras se carga la webfont: Usa font-display para garantizar un renderizado de texto rápido.
• 14 métodos para aplazar el JavaScript: Todas las técnicas para evitar que el JavaScript bloquee tu FCP.
• Corregir y eliminar el CSS no utilizado: Reduce el CSS render blocking al mínimo.
• 103 Early Hints: Permite que el navegador empiece a obtener recursos antes de que llegue el HTML.
• Guía del Largest Contentful Paint (LCP): El FCP y el LCP comparten muchas estrategias de optimización. Si tu FCP es lento, tu LCP también lo será.
• Guía del Time to First Byte (TTFB): El TTFB es el mayor contribuyente individual al FCP. Empieza por aquí si la respuesta de tu servidor es lenta.