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

¿Qué es First Contentful Paint (FCP)?

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

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

Desglosemos las palabras: 'First', 'Contentful' y 'Paint'.

1. First: Con First nos referimos, por supuesto, al primer momento exacto en que algo sustancial aparece en tu navegador.
2. Contentful: Con Contentful nos referimos a un elemento HTML con contenido. Es decir, no un elemento de diseño como un elemento vacío o color de fondo, sino texto, una imagen (incluida imagen de fondo), SVG o canvas.
3. Paint: Paint significa (más o menos) que el navegador está listo para mostrar algo en la pantalla. Esto parece sencillo 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 se muestra un ejemplo del proceso de renderizado que se requiere antes de que se pueda añadir algo en la pantalla.

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

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

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

¿Qué es una buena puntuación de First Contentful Paint?

Una puntuación FCP buena es cualquier valor inferior a 1,8 segundos. Si tu puntuación FCP está entre 1,8 y 3 segundos, necesita mejoras. Cualquier puntuación FCP superior a 3 segundos se considera pobre. Para cumplir con el umbral recomendado para First Contentful Paint, al menos el 75 % de tus visitantes necesitan tener una puntuación FCP "buena".

Como siempre con las métricas de rendimiento, una puntuación First Contentful Paint más rápida es mejor que una más lenta.

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

El FCP es medido por Google recopilando datos de usuarios reales. Esos datos se almacenan en el conjunto de datos CrUX. Estos 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 First Contentful Paint del conjunto de datos CrUX

First Contentful Paint se puede consultar en el conjunto de datos CrUX a través de pagespeed.web.dev, la API de CrUX o a través de Google BigQuery.

Medir First Contentful Paint mediante Real User Monitoring (RUM)

RUM Tracking significa Real User Monitoring. Con Real User Monitoring puedes rastrear First Contentful Paint a través de interacciones de usuarios reales. La ventaja del RUM Tracking 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 deseas medir. Asegúrate de hacerlo en modo 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 Elemento. De esta forma abres la consola de desarrollador de Chrome.
3. En la parte superior de la consola, verás la pestaña Lighthouse. Haz clic en ella. Luego, en Categorías, elige Rendimiento (deja las demás en blanco) y elige Móvil en Dispositivo.
4. Ahora haz clic en Generar Informe. 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 Lighthouse de esta página. ¡El FCP de esta página en un dispositivo móvil es de 0,8 segundos! No está mal, ¿verdad?

Medir FCP con una herramienta en línea

También puedes medir el FCP con varias herramientas en línea. Las más conocidas son GTMetrix, pingdom y pagespeed.web.dev. Estas herramientas son fáciles de usar y proporcionan datos sobre el FCP bajo condiciones de laboratorio específicas.

Qué muestran los datos reales de FCP

Los datos de CoreDash muestran que FCP sigue de cerca al TTFB: el p75 de FCP es de 392 ms en general, con 372 ms en escritorio y 692 ms en móvil (1,9 veces más lento). La diferencia entre FCP y TTFB es de solo 248 ms en escritorio y 376 ms en móvil, lo que indica que el tiempo de bloqueo de renderizado representa una porción relativamente pequeña del FCP en un sitio bien optimizado.

A nivel mundial, según el HTTP Archive Web Almanac 2024, el 68 % de las páginas de escritorio logran un buen FCP, mientras que solo el 51 % de las páginas móviles lo consiguen. FCP se recuperó en 2024 después de una ligera caída en 2023, lo que sugiere que los desarrolladores web están abordando cada vez más los recursos que bloquean el renderizado.

La estrecha correlación entre FCP y TTFB significa que mejorar tu Time to First Byte es a menudo 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, lo que significa que la mayor parte del tiempo de FCP se emplea esperando la respuesta del servidor en lugar de trabajo de bloqueo de renderizado.

Mejorar First Contentful Paint

Ahora que sabes qué es First Contentful Paint, podemos ponernos a trabajar para hacerlo más rápido. La idea detrás de un FCP rápido es en realidad bastante simple: asegurarte de que un navegador pueda comenzar a renderizar inmediatamente. Cualquier cosa que pueda causar un retraso en el renderizado resultará en una puntuación FCP pobre.

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

1. Time to First Byte (TTFB): El tiempo desde que el navegador comienza a cargar la página hasta que recibe el primer byte del HTML.
2. Retraso en la carga del recurso: El tiempo entre el TTFB y el momento en que el navegador comienza a cargar el recurso FCP.
3. Tiempo de carga del recurso: El tiempo que tarda en cargarse el recurso FCP en sí.
4. Retraso en el renderizado del elemento: El tiempo entre el momento en que el recurso FCP terminó de cargarse y el momento en que el elemento FCP se renderiza completamente.

Consejo de velocidad: Puedes eliminar fácilmente los pasos 2 y 3 asegurándote de que el elemento 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 en línea.

Esto nos deja solo con el Time to First Byte y el retraso en el renderizado del elemento para optimizar.

A continuación se presentan 14 soluciones que suelo usar para mejorar el FCP. Pero ten cuidado, usar una solución en el lugar equivocado puede en realidad crear retrasos. Por eso es mejor consultar a un experto en velocidad de página antes de comenzar por tu cuenta.

1. Respuesta rápida del servidor (TTFB)

El TTFB (el tiempo entre la solicitud y el primer byte que envía el servidor) es siempre el primer paso en el proceso de renderizado. A partir de ese punto, tu navegador comienza a realizar múltiples tareas, y el impacto de las optimizaciones posteriores comienza a disminuir. El código HTML es la única solicitud 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 se mide a menudo como Time to First Byte (TTFB). Es importante hacerlo lo más rápido posible. A menudo se logra habilitando el almacenamiento en caché del lado del servidor.

Cuando se trata de Time to First Byte, cuanto más bajo, mejor.

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

1. Usa el atajo Ctrl-Shift-I para abrir la consola de desarrollador de Google Chrome.
2. En la parte superior de la consola, verás una pestaña Red (Network). Haz clic en ella.
3. Recarga la página mediante Ctrl-R.
4. Ahora verás todas las solicitudes de red que Chrome ha enviado a tu servidor.
5. Haz clic en la primera solicitud de red, que es la solicitud de tu propia página.
6. Ahora obtendrás más información sobre esta solicitud de red. Haz clic en la pestaña Temporización (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 encontrados 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 por interrupciones menores de la red.

Sin entrar en demasiados detalles, HTTP/3 permite una mejora 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 es compatible con el protocolo HTTP/3 más rápido.

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

3. 103 Early Hints

103 Early Hints es un código de estado HTTP relativamente nuevo que permite a un servidor enviar encabezados 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, consultar una base de datos o ejecutar lógica del lado del servidor). En lugar de hacer que el navegador espere sin hacer nada, el servidor envía una respuesta 103 con indicaciones de preload y preconnect para que el navegador pueda comenzar a obtener recursos críticos inmediatamente.

Esto mejora directamente el FCP porque el navegador puede comenzar a descargar fuentes, hojas de estilo y otros recursos críticos para el renderizado 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 alojamiento admiten 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. Almacenamiento en caché del navegador

La conexión de red es a menudo un eslabón débil cuando se trata de velocidad de página. ¿No sería mucho más fácil omitir la red por completo?

Cuando un visitante ha estado en tu sitio antes, puedes indicar si y durante cuánto tiempo los recursos de red (por ejemplo, una hoja de estilos) pueden ser almacenados por el navegador del visitante. Cada vez que el visitante necesita uno de estos archivos de nuevo, aparecen desde la caché del navegador en un instante. Como resultado, el navegador puede comenzar a renderizar mucho más rápido y acelerar el FCP.

5. Compresión

La velocidad de red es en casi todos los casos un eslabón débil. Para un buen First Contentful Paint, es muy importante que los archivos se envíen a través de la red lo más rápido posible. La compresión reduce el número de bytes que deben enviarse desde el servidor; menos bytes significa menos tiempo esperando un recurso de red. La compresión, en mi opinión, es una técnica que no recibe la atención que merece. Desafortunadamente, demasiados administradores web "activan la compresión" y luego no vuelven a revisarla. Y eso es una lástima porque es simplemente una forma fácil 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 utilizada, pero Brotli está alcanzándola rápidamente. Brotli ha sido 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 compresión dinámica y 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 es a menudo una forma mucho más inteligente de comprimir, pero rara vez se usa.

6. Fuentes web 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 las fuentes web o las 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 una buena idea incluir un "resource hint". Esto asegurará que el navegador comience a descargar o conectarse al recurso inmediatamente. Como resultado, el recurso estará disponible antes y el navegador podrá comenzar a renderizar antes.

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

Descarga anticipada con "preloading"

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

El enlace preload es una de las herramientas más poderosas en el arsenal de velocidad de página. A través del enlace preload, descargas un recurso de red que necesitarás más tarde. Esto es a menudo una muy buena idea con fuentes, scripts críticos e imágenes en la parte visible del sitio.

Conectar por adelantado con preconnect

El enlace preconnect ya se conecta a 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>

Aún mejor que hacer preconnect a Google Fonts es alojar tus Google Fonts en tu propio servidor. Esto elimina completamente la conexión a terceros y te da control total sobre el almacenamiento en caché y la entrega.

7. Precargar la siguiente página con prefetch

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

Con prefetch, puedes obtener recursos de baja prioridad. Esta 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 de la siguiente página.

8. Evitar redirecciones

Un error común es tener una cadena de redirecciones demasiado larga. Permíteme explicar: 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á configurado correctamente, el visitante será redirigido al sitio web seguro. Puedes ver esto en el ejemplo verde a continuación.

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

9. Minimizar CSS

Un archivo CSS externo siempre bloquea el renderizado. Esto significa que un navegador normalmente no puede comenzar a mostrar 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 tiempo a que se descargue la hoja de estilos. Para una guía más completa, lee nuestro artículo sobre cómo corregir y eliminar CSS no utilizado.

Reducir el tamaño de CSS con shortcode

Una de las formas de reducir el tamaño de CSS es usando shortcodes. Estos son una sola línea que te permiten escribir las propiedades más importantes de un selector CSS en una línea.

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 de CSS

Es posible reducir aún más el tamaño de CSS fusionando 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 así

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

10. CSS Crítico

Podemos llevar el CSS un paso más allá usando CSS crítico. El CSS crítico es imprescindible para un sitio web rápido y un First Contentful Paint rápido.

El CSS crítico 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 CSS crítico en una hoja de estilos separada; en su lugar, añádelo directamente en el <head> de la página. De esta forma no tienes que descargar un nuevo archivo y el navegador puede comenzar a renderizar a toda velocidad. Esto produce un FCP más rápido. El CSS que no necesitas directamente para la parte visible de la página se carga después de que el primer ciclo de renderizado se haya completado. Para tu visitante, la página ya está terminada; nadie notará los nuevos estilos que aún se añaden en segundo plano.

El CSS crítico se puede generar fácilmente con nuestra propia herramienta de CSS crítico. ¡Solo pega la URL de tu página web en la herramienta y nosotros haremos el resto por ti!

Ejemplo de CSS crítico en línea

<head>
  <style>
    /* CSS crítico: solo lo necesario para el contenido visible */
    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>
  <!-- CSS no crítico cargado asincrónicamente -->
  <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. Diferir la carga de JavaScript

Una de las razones más comunes de un First Contentful Paint lento es JavaScript. Dependiendo de cómo uses JavaScript, puede bloquear el renderizado de la página. Normalmente JavaScript se descarga y se 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 una visión completa de las técnicas de aplazamiento, lee 14 métodos para diferir JavaScript.

Podemos solucionar esto posponiendo JavaScript. Puedes hacerlo de tres formas.

JavaScript Async

<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 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 suficiente tiempo para construir una parte importante de la página, con el First Contentful Paint ya en la página.

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 mientras se construye la página. Después de que todos los scripts se hayan descargado, se ejecutan en el orden en que fueron encontrados en el código HTML. Esto también puede bloquear la visualización de la página, pero en muchos casos First Contentful Paint ya está en la pantalla.

12. No depender de recursos externos

Los recursos externos, como fuentes externas, imágenes externas, hojas de estilo externas o scripts externos, son un cuello de botella potencial cuando se trata de First Contentful Paint. Como no tienes control del servidor donde se alojan los archivos, no sabes con qué rapidez se enviarán. Además, no puedes usar la conexión existente al servidor web. Se debe establecer una nueva conexión a un nuevo servidor, y eso lleva tiempo.

Uno de los recursos externos más comunes en la web es Google Fonts. Alojar tus Google Fonts en tu propio servidor elimina una conexión a terceros por completo y te da control total sobre el almacenamiento en caché, la compresión y el comportamiento de font-display.

Recursos externos bloqueantes

Sin recursos externos

13. Usar el formato de fuente correcto

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

Recientemente, las fuentes web han recibido más atención, y hay más formatos de fuentes nuevos y más rápidos. El formato de fuente más rápido en este momento es woff2, seguido de woff. Woff2 es compatible con todos los navegadores modernos.

Puedes especificar el orden preferido de tu fuente web en la declaración CSS font-face. 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

Cuando usas fuentes web, el comportamiento predeterminado de estas fuentes es no mostrar el texto en la página hasta que la fuente se haya cargado. Esto generalmente va directamente en detrimento de First Contentful Paint. Lee nuestra guía completa sobre cómo asegurar que el texto permanezca visible durante la carga de fuentes web.

Puedes resolver esto usando la declaración font-display:swap. Con esto puedes elegir mostrar el texto en la página de todos modos, en una fuente que el navegador conoce, mientras la fuente web 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: Muestra la fuente de respaldo inmediatamente, cambia cuando se carga la fuente web */
@font-face {
  font-family: 'MyFont';
  font-display: swap;
  src: url('/fonts/myfont.woff2') format('woff2');
}

/* optional: Muestra la fuente de respaldo, solo usa la fuente web si ya está en caché */
@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 de respaldo. Usar font-display: optional evita por completo el destello de texto sin estilo (FOUT) en la primera visita, pero la fuente web solo se mostrará si ya está en la caché del navegador. Para la mayoría de los sitios, swap es la mejor opción para el FCP.

15. Minimizar el tamaño del DOM

Una página web consiste en HTML. Lo primero que hace un navegador es convertir el HTML en nodos DOM. Esa es una estructura de árbol de elementos HTML que luego se usa para construir el árbol de renderizado. A partir del árbol de renderizado, un navegador comienza a renderizar; finalmente la página web aparece en la pantalla.

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

Resuélvelo mediante:

• Carga diferida de partes de tu página web
  Para acelerar la visualización inicial, considera cargar partes de tu sitio web, como el pie de página, vía AJAX en un momento posterior.
• Usar content-visibility
  La propiedad CSS content-visibility le dice al navegador que omita el estilo, diseño y pintado durante el renderizado. Lo hace justo antes de que el elemento sea visible.
• Dividir páginas grandes en múltiples páginas
  El número de nodos DOM se puede reducir dividiendo páginas grandes en múltiples páginas.
• Implementar scroll infinito
  El scroll infinito es básicamente carga diferida: al desplazarte por elementos repetidos como imágenes (Pinterest) o grandes tablas de datos, el scroll infinito puede acelerar significativamente tu página.
• Evitar la interacción JavaScript con el DOM
  Ten especial cuidado con JavaScript cuando tengas un gran número de nodos DOM en tu página. Un comando como querySelectorAll puede entonces cargar un gran número de nodos DOM, aumentando el uso de memoria.
• Evitar declaraciones CSS complicadas
  Ten especial cuidado con comandos CSS complicados cuando tengas un gran número de nodos DOM. Por ejemplo, verificar el estado last-child para cada elemento div en tu página puede ser costoso.
• Usar web workers para aliviar el hilo principal del navegador
  Los web workers son JavaScript que puede ejecutarse en paralelo con tu página web. Puedes dar a estos web workers comandos que se ejecutan en segundo plano. Cuando el web worker ha ejecutado el comando, lo pasa a la página original. La ventaja de esto es que puedes ejecutar JavaScript complejo sin que la página se congele.

Guías de optimización relacionadas

Mejorar FCP requiere trabajo en múltiples áreas. Aquí están nuestros artículos de análisis profundo más relevantes:

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