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

Corregir 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 por primera vez algo en la pantalla. Como tal, el FCP es una buena forma de medir la velocidad de carga percibida de la página.

Puede mejorar el FCP asegurándose de que el navegador pueda comenzar a renderizar sin ningún retraso. A continuación, aprenderá 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 se puede resumir la velocidad de la página como un punto en el tiempo; en realidad, hay varios momentos durante el proceso de carga en los que un visitante puede experimentar 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 se renderiza el primer contenido significativo en la pantalla por primera vez.

¿Qué le dice exactamente eso? Le indica 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 experiencia del usuario. En el momento del FCP, puede estar seguro de que un visitante realmente ve "algo" en la pantalla.

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

1. First: Por First, por supuesto, nos referimos al primer momento exacto en que algo sustancial aparece en su navegador.
2. Contentful: Con contentful nos referimos a un elemento HTML con contenido. No se trata de un elemento de diseño como un elemento en blanco o un color de fondo, sino de algún texto, una imagen (incluida la imagen de fondo), un SVG o un lienzo (canvas).
3. Paint: Paint significa (más o menos) que el navegador está listo para poner 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 a la pantalla.

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

El FCP y el LCP (Largest Contentful Paint) miden el rendimiento de la carga, pero capturan momentos diferentes en la línea de tiempo de carga de la página. Comprender la diferencia le ayuda a priorizar su 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 400ms pero esperar otros 2 segundos a que se cargue la imagen hero (LCP). Si su FCP es lento, es casi seguro que su LCP también lo será, porque el FCP captura el primer cuello de botella en la canalización de renderizado. Lea más en nuestra guía completa de LCP.

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

Para aprobar la evaluación de Core Web Vitals en cuanto al First Contentful Paint, al menos el 75% de sus visitantes necesitan tener una puntuación de FCP 'buena'. Una puntuación de FCP inferior a 1,8 segundos se considera una buena puntuación de FCP, una puntuación de FCP entre 1,8 y 3,0 segundos necesita mejorar y una puntuación de FCP superior a 3,0 segundos se considera pobre.

Cómo medir el First Contentful Paint

Puede medir el First Contentful Paint de varias maneras. Las herramientas más comunes son Lighthouse, PageSpeed Insights y Chrome DevTools. Todas estas herramientas utilizan datos de laboratorio, lo que significa que simulan una visita a la página bajo condiciones controladas. Para comprender el rendimiento real de sus usuarios, debe utilizar herramientas que recopilen datos de campo.

Medir el FCP con Chrome DevTools

Puede medir el FCP directamente en su navegador utilizando las Chrome DevTools. Abra las herramientas para desarrolladores (Ctrl+Shift+I), vaya a la pestaña Performance y recargue la página. Verá el marcador FCP en la sección Timings.

Medir el FCP con PageSpeed Insights

PageSpeed Insights proporciona tanto datos de laboratorio (Lighthouse) como datos de campo (CrUX) para una URL específica. Esto le permite ver cómo experimentan los usuarios reales su sitio y compararlo con una prueba controlada.

Medir el FCP con datos RUM

Las herramientas de Real User Monitoring (RUM), como CoreDash, recopilan datos de rendimiento de cada visitante real de su sitio. Esto le proporciona una imagen mucho más precisa de su rendimiento de FCP en diferentes dispositivos, redes y ubicaciones. CoreDash desglosa el FCP en sus subpartes, ayudándole a identificar si el retraso se debe al servidor, a la carga de recursos o al trabajo de renderizado.

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: asegurarse de que un navegador pueda comenzar a renderizar de inmediato. Cualquier cosa que pueda causar un retraso en el renderizado resultará en una puntuación de 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 comienza 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 comienza a cargar el recurso FCP.
3. Resource load time: El tiempo que tarda en cargarse el propio recurso FCP.
4. Element render delay: El tiempo entre que el recurso FCP terminó de cargarse hasta que el elemento FCP se renderiza por completo.

Consejo de velocidad: Puede eliminar fácilmente los pasos 2 y 3 asegurándose de que el elemento FCP no requiera un recurso de red. En el caso de un elemento de texto, considere usar font-display:swap. En el caso de un elemento de imagen pequeño, considere colocar la imagen en línea (inline).

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

A continuación se presentan 14 soluciones que suelo utilizar para mejorar el FCP. Pero tenga cuidado, usar una solución en el lugar equivocado puede crear retrasos. Por eso lo mejor es consultar a un experto en pagespeed antes de empezar por su 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 momento, su navegador comienza a realizar multitarea y el impacto de nuevas optimizaciones empieza 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 se envía el código HTML desde el servidor se mide a menudo como el Time to First Byte (TTFB). Es importante que sea lo más rápido posible. A menudo esto se consigue habilitando el almacenamiento en caché del lado del servidor.

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

Puede medir fácilmente el Time to First Byte usted mismo. Se hace de la siguiente manera:

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

2. HTTP/3

HTTP/3 es la tercera versión del protocolo HTTP. HTTP/3 resuelve muchos de los problemas detectados en los protocolos más antiguos HTTP/1.1 y HTTP/2. Por ejemplo, desde HTTP/2, se pueden enviar varios 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 pequeñas interrupciones de la red.

Sin entrar en demasiados detalles, HTTP/3 permite una ganancia de velocidad significativa, especialmente en una red más lenta como la red móvil. Su administrador de red puede decirle si su servidor web ya es apto para el protocolo más rápido HTTP/3.

Usted mismo puede comprobar si su sitio web ya utiliza el protocolo más rápido HTTP/3. Use el atajo Ctrl-Shift-I para abrir el inspector de red de Google Chrome. Haga clic derecho en la cabecera de la tabla y seleccione Protocol. Ahora recargue la página para ver qué protocolo está utilizando su sitio.

3. 103 Early Hints

103 Early Hints es 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 el servidor necesita tiempo para generar el HTML (por ejemplo, al consultar una base de datos o ejecutar lógica del lado del servidor). En lugar de hacer que el navegador espere inactivo, el servidor envía una respuesta 103 con sugerencias de preload y preconnect para que el navegador pueda empezar a obtener recursos críticos de inmediato.

Esto mejora directamente el FCP porque el navegador puede empezar 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 hosting admiten todavía los 103 Early Hints. Cloudflare tiene soporte integrado para Early Hints, y Apache y Nginx pueden configurarse para enviarlos. Lea más en nuestra guía completa de 103 Early Hints.

4. Browser Caching

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

Cuando un visitante ha estado antes en su sitio, usted puede indicar si los recursos de red (por ejemplo, una hoja de estilo) pueden ser almacenados por el navegador del visitante y durante cuánto tiempo. Cada vez que el visitante necesite de nuevo uno de estos archivos, aparecerán desde la caché del navegador en un abrir y cerrar de ojos. 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, el eslabón débil. Para un buen First Contentful Paint, es muy importante que los archivos se envíen por 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 significan menos tiempo de espera por un recurso de red. La compresión, en mi opinión, es una técnica que no recibe la atención que merece. Por desgracia, demasiados webmasters "activan la compresión" y luego no vuelven a mirarla más. Y es una pena, porque es 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á ganando terreno rápidamente. Brotli ha sido creado por la propia Google y tiene resultados entre un 15 y un 20% mejores cuando se trata de archivos HTML, JavaScript o CSS. Brotli es, por 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 se comprime el archivo justo antes de enviarlo a través del 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 utiliza.

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 su cuenta. 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á seguro de que necesita 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 a conectarse al recurso inmediatamente. Como resultado, el recurso está disponible antes y el navegador puede empezar a renderizar antes.

Pero tenga cuidado con los resource hints. Si los utiliza incorrectamente, pueden ralentizar su página.

Descarga temprana con "preloading"

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

El enlace de preload es una de las herramientas más potentes del arsenal de velocidad de página. A través del enlace de preload, se descarga un recurso de red que se necesitará más tarde. Suele ser una muy buena idea con las fuentes, los scripts críticos y las imágenes en la parte visible del sitio.

Conexión anticipada con preconnect

El enlace de preconnect ya conecta con un servidor. Esto es útil cuando aloja 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 auto-alojar sus Google Fonts. Esto elimina por completo la conexión de terceros y le da un control total sobre el almacenamiento en caché y la entrega.

7. Prefetch de la siguiente página con prefetch

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

Con prefetch, puede obtener recursos de baja prioridad. Esta es una forma útil de obtener recursos que cree que necesitará más tarde, por ejemplo cuando espera que alguien haga clic en el enlace de la página siguiente.

8. Evitar redirecciones

Un error común es tener una cadena de redirección demasiado larga. Me explico: Probablemente su sitio funcione a través de una conexión segura. Cuando un visitante teclea su sitio sin añadir https, el visitante será redirigido a la versión no segura de su sitio web. Sin embargo, si todo está bien configurado, el visitante será redirigido al sitio web seguro. Puede verlo en el ejemplo verde de abajo.

Pero a veces la redirección se produce 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, lo que se traduce en una puntuación de First Contentful Paint pobre. Cada paso intermedio cuesta un tiempo extra, que puede acumularse rápidamente. Por lo tanto, asegúrese siempre de llegar a la página correcta en una sola redirección.

9. Minimizar el CSS

Un archivo CSS externo siempre bloquea el renderizado (render-blocking). Esto significa que, normalmente, un navegador no puede empezar a mostrar el contenido hasta que se hayan descargado y analizado todas las hojas de estilo. Por lo tanto, lo mejor es que las hojas de estilo sean lo más pequeñas posible. De este modo, no habrá que esperar tanto para descargar la hoja de estilo. Para una guía más completa, lea nuestro artículo sobre cómo corregir y eliminar el CSS no utilizado.

Reducir el tamaño del CSS con shortcode

Una de las formas de reducir el tamaño del CSS es mediante el uso de shortcodes. Se trata de líneas únicas que permiten anotar las propiedades más importantes de un selector CSS en una sola 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 puede 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 aún más el tamaño del CSS fusionando selectores con una coma, eliminando entradas 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 como

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

10. CSS Crítico

Podemos llevar el CSS un paso más allá utilizando 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 necesita para mostrar la parte visible de la página. No ponga este CSS crítico en una hoja de estilo aparte; en su lugar, añádalo directamente en el <head> de la página. De este modo no tendrá que descargar un archivo nuevo y el navegador podrá empezar a renderizar a la velocidad del rayo. Esto permite un FCP más rápido. El CSS que no necesita directamente para la parte visible de la página se carga después de que se complete el primer ciclo de renderizado. Para su visitante, la página ya está terminada; nadie notará que se siguen añadiendo nuevos estilos en segundo plano.

El CSS crítico se puede generar fácilmente con nuestra propia herramienta de CSS crítico. Solo tiene que pegar la URL de su página web en la herramienta y nosotros haremos el resto por usted.

Ejemplo de CSS Crítico en línea

<head>
  <style>
    \/* CSS Crítico: solo lo necesario para el contenido above-the-fold *\/
    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 de forma asíncrona -->
  <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 para un First Contentful Paint lento es el JavaScript. Dependiendo de cómo utilice el JavaScript, este 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 una visión completa de las técnicas de aplazamiento, lea 14 métodos para diferir JavaScript.

Podemos evitarlo posponiendo el JavaScript. Puede hacerlo de tres maneras.

JavaScript asíncrono (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 el JavaScript. El atributo async indica que la descarga y la construcción del árbol de renderizado pueden ocurrir al mismo tiempo.

Una vez ejecutado el script, 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 página.

Diferir 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. Una vez descargados todos los scripts, estos se ejecutan en el orden en 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 pantalla.

12. No dependa de recursos externos

Los recursos externos, como las fuentes externas, las imágenes externas, las hojas de estilo externas o los scripts externos, son un cuello de botella potencial cuando se trata del First Contentful Paint. Al no tener control sobre el servidor donde se alojan los archivos, no sabe a qué velocidad se enviarán. Además, no puede utilizar la conexión existente con el servidor web. Hay que configurar una nueva conexión con un nuevo servidor, y eso lleva tiempo.

Uno de los recursos externos más comunes en la web es Google Fonts. Auto-alojar sus Google Fonts elimina toda una conexión de terceros y le da un control total sobre el almacenamiento en caché, la compresión y el comportamiento de font-display.

Bloqueo de recursos externos

Sin recursos externos

13. Utilice el formato de fuente adecuado

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

Recientemente, las fuentes web han recibido más atención y hay nuevos formatos de fuente 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.

Puede especificar el orden preferido de su fuente web en la declaración font-face de CSS. Se hace 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 se utilizan fuentes web, 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. Lea nuestra guía completa sobre cómo garantizar que el texto permanezca visible durante la carga de webfonts.

Puede solucionar este problema utilizando la declaración font-display:swap. Con ella puede elegir mostrar el texto en la página de todos modos, con 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

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

\/* swap: Muestra la fuente de respaldo inmediatamente, cambia cuando se carga la webfont *\/
@font-face {
  font-family: 'MyFont';
  font-display: swap;
  src: url('/fonts/myfont.woff2') format('woff2');
}

\/* optional: Muestra la fuente de respaldo, solo usa la webfont si ya está en caché *\/
@font-face {
  font-family: 'MyFont';
  font-display: optional;
  src: url('/fonts/myfont.woff2') format('woff2');
}

El uso de font-display: swap garantiza el FCP más rápido posible porque el texto se renderiza inmediatamente en la fuente de respaldo. El uso de font-display: optional evita por completo el flash 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 se compone de HTML. Lo primero que hace un navegador es convertir el HTML en nodos DOM. Se trata de una estructura de árbol de elementos HTML que se utiliza posteriormente para construir el árbol de renderizado. A partir del árbol de renderizado, el navegador comienza a renderizar; finalmente, la página web aparece en la pantalla.

El número de nodos DOM (elementos HTML) que tenga y la profundidad de estos nodos DOM en la estructura del árbol determinan lo complicado que es para un navegador construir su página. El CSS y el JavaScript también tardan más tiempo en analizarse cuando se tienen demasiados nodos DOM. Esto, una vez más, va directamente en detrimento del FCP.

Solucione esto de la siguiente manera:

• Carga diferida (lazy load) de partes de su página web
  Para acelerar la visualización inicial, considere la posibilidad de cargar partes de su sitio web, como el pie de página (footer), a través de AJAX en un momento posterior.
• Haga uso de content-visibility
  La propiedad CSS content-visibility indica al navegador que omita el estilo, el diseño y la pintura durante el renderizado. Lo hace justo antes de que el elemento se vuelva visible.
• Divida las páginas grandes en varias páginas
  El número de nodos DOM puede reducirse dividiendo las páginas grandes en varias páginas.
• Implemente el scroll infinito (infinite scroll)
  El scroll infinito es básicamente una carga diferida: cuando se desplaza a través de elementos repetidos como imágenes (Pinterest) o grandes tablas de datos, el scroll infinito puede acelerar significativamente su página.
• Evite la interacción de JavaScript con el DOM
  Tenga especial cuidado con el JavaScript cuando tenga un gran número de nodos DOM en su página. Un comando como querySelectorAll puede cargar un gran número de nodos DOM, aumentando el uso de memoria.
• Evite declaraciones CSS complicadas
  Tenga especial cuidado con comandos CSS complicados con un gran número de nodos DOM. Por ejemplo, comprobar el estado de last-child para cada elemento div de su página puede resultar costoso.
• Utilice web workers para liberar el main thread de su navegador
  Los web workers son JavaScript que pueden ejecutarse en paralelo a su página web. Puede dar comandos a estos web workers 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 puede seguir ejecutando JavaScript complejo sin que la página se congele.

Guías de optimización relacionadas

Mejorar el FCP requiere trabajar en múltiples áreas. Estas son nuestras guías más relevantes:

• Auto-alojar Google Fonts: Elimine una conexión de terceros y obtenga el control total sobre la entrega de fuentes.
• Garantizar que el texto permanezca visible durante la carga de webfonts: Use 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 su FCP.
• Corregir y eliminar el CSS no utilizado: Reduzca al mínimo el CSS que bloquea el renderizado.
• 103 Early Hints: Permita que el navegador comience a obtener recursos antes de que llegue el HTML.
• Guía de Largest Contentful Paint (LCP): El FCP y el LCP comparten muchas estrategias de optimización. Si su FCP es lento, su LCP también lo será.
• Guía de Time to First Byte (TTFB): El TTFB es el factor que más contribuye al FCP. Empiece aquí si la respuesta de su servidor es lenta.