Corrige "Avoid Chaining Critical Requests" en Lighthouse

Cómo se determina la prioridad de descarga

Las peticiones críticas son los recursos que se descargan con alta prioridad durante la carga inicial de la página. ¿Cómo se determina esta prioridad?

El propio navegador determina la prioridad de descarga. El navegador sigue unas reglas para determinar la prioridad de cada recurso. Qué elementos reciben finalmente la máxima prioridad depende de la estructura de la página. Los elementos que tu navegador considera necesarios para el primer renderizado de la página reciben la máxima prioridad.

Inicialmente, tu navegador hace una suposición calculada sobre qué elementos son más importantes. En general, la prioridad de descarga funciona así: el HTML siempre tiene la máxima prioridad, luego las hojas de estilo, el JavaScript síncrono, las fuentes, las peticiones AJAX, las imágenes en la parte superior de la página, las imágenes en la parte inferior de la página y, por último, el JavaScript asíncrono.

Puedes anular estas prioridades con el atributo fetchpriority. Configurar fetchpriority="high" le dice al navegador que un recurso es más importante de lo que normalmente supondría. Configurar fetchpriority="low" hace lo contrario. Este atributo ahora tiene un 93% de soporte en navegadores. Para una guía completa, consulta Priorización de recursos y los Core Web Vitals.

Puedes ver qué recursos reciben alta prioridad en tu página. Abre las DevTools con Ctrl+Shift+J. Ve a la pestaña Network, haz clic derecho en los nombres de las columnas y selecciona 'Priority'.

¿Cómo afecta la cadena de peticiones críticas al tiempo de carga de la página?

Al cargar una página, un navegador empieza en modo "bloqueo de visualización". En este modo, los recursos más importantes se descargan con alta prioridad. Esos son los recursos críticos.

Un navegador no empezará a renderizar la página (completamente) hasta descargar todos los recursos críticos. Así que cualquier recurso crítico puede bloquear el primer renderizado de una página.

Cuantos menos recursos críticos tenga una página, menos trabajo tendrá que hacer el navegador para mostrar el primer contenido en la pantalla, y habrá menos competencia por la CPU y otros recursos.

Según el Web Almanac 2025, solo el 15% de las páginas móviles pasa la auditoría de recursos de render blocking. Eso significa que el 85% de la web todavía tiene problemas de cadenas críticas que resolver. Esta es una de las principales razones por las que solo el 55% de los orígenes móviles puntúan como "bueno" en el First Contentful Paint. En los sitios monitorizados por CoreDash, los orígenes con menos de 3 peticiones en la cadena crítica tienen un FCP medio de 1,2 segundos, frente a los 2,4 segundos de los orígenes con 8 o más peticiones en la cadena.

Nota: A partir de Lighthouse 13 (octubre de 2025), esta auditoría ha sido renombrada como la información "Network Dependency Tree". El concepto es el mismo: Lighthouse analiza la cadena de peticiones de red de alta prioridad y avisa cuando es demasiado profunda.

Cómo corregir "Avoid Chaining Critical Requests" en Lighthouse

Puedes reducir el impacto de las peticiones críticas de tres maneras:

1. Reduce el número de recursos críticos. Convierte los recursos críticos en recursos no críticos eliminándolos o aplazándolos.
2. Reduce el número de bytes críticos. Reducir el tamaño de los recursos de la ruta crítica hace que se descarguen más rápido. La compresión Gzip o Brotli, el tree shaking de JavaScript, la optimización de imágenes y el font subsetting ayudan.
3. Mejora el orden de descarga de la ruta crítica. Usa resource hints como el preload para saltarte el descubrimiento de recursos y asegurar que los recursos críticos se descarguen lo más rápido posible. Usa HTTP 103 Early Hints para empezar a hacer preload de los recursos antes incluso de que llegue el HTML.

Qué opción es mejor depende del tipo de archivo del recurso:

1. HTML

El HTML siempre se descarga con la máxima prioridad. La página siempre forma parte de la cadena de peticiones críticas. Por eso la página en sí es lo primero que hay que considerar al optimizar.

Carga retrasada de contenido: Muchos sitios grandes, como el propio Google, usan esta técnica para reducir la cadena de peticiones críticas. En la página de resultados de búsqueda, por ejemplo, las partes del contenido que no se necesitan inmediatamente solo se cargan más tarde mediante una petición AJAX.

Minifica: Más pequeño siempre es más rápido. Usa la minificación de HTML para eliminar comentarios, espacios y líneas en blanco de la página.

Compresión: Comprime tu HTML con Brotli o Gzip. Brotli suele conseguir una compresión entre un 15 y un 20% mejor que Gzip.

2. Hojas de estilo

Las hojas de estilo en el head de la página siempre son críticas. Sin estilos, un navegador no sabe cómo se verá la página. Por lo tanto, las hojas de estilo son una parte estándar de la cadena de peticiones críticas.

CSS crítico: La forma más efectiva de romper la cadena de CSS es poner tu CSS crítico inline directamente en una etiqueta <style> en el <head>. Esto elimina por completo la petición de red del render blocking. Puedes generar el CSS crítico mediante herramientas de NodeJS o con el Generador de CSS Crítico. Pon el CSS crítico inline y carga el resto con menor prioridad:

<link rel="preload"
      href="css.css"
      type="text/css"
      as="style"
      onload="this.onload=null;this.rel='stylesheet';"/>

Observa cómo ahora pasa algo extraño en la página. Primero la página se muestra sin estilos, y solo después de cargar el CSS se aplican los estilos. Todo el contenido parpadeará de sin estilos a con estilos. Por eso necesitas el CSS crítico: las reglas CSS para la parte visible de la página están inline, por lo que la página se ve correctamente de inmediato, y el resto del CSS se carga sin hacer render blocking.

Evita las cadenas @import en CSS: Si tus archivos CSS usan @import para cargar otros archivos CSS, creas una cadena donde el navegador debe descargar el archivo A antes incluso de descubrir que necesita el archivo B. Reemplaza las sentencias @import por etiquetas <link> separadas o concatena los archivos en el proceso de build. Esta es una de las causas más comunes de cadenas críticas innecesariamente profundas.

Media queries: Carga solo los estilos que tu dispositivo necesita. Si un visitante está en móvil, no necesita descargar los estilos de escritorio o de impresión. Usa el atributo media para hacer que las hojas de estilo no bloqueen en los dispositivos que no coinciden:

<link href="all.css" rel="stylesheet" media="all">
<link href="print.css" rel="stylesheet" media="print">
<link href="desktop.css" rel="stylesheet" media="screen and (min-device-width: 1024px)">

El navegador solo descarga las hojas de estilo cuyo atributo media coincide con el dispositivo actual con alta prioridad. Las hojas de estilo que no coinciden se descargan con prioridad baja y no bloquean el renderizado.

Minifica: Elimina el CSS no utilizado. Muchos sitios usan librerías CSS como Bootstrap. Estas librerías a menudo son demasiado completas y no se usan todas las declaraciones de estilo. Edita estas librerías mediante un preprocesador CSS (como Sass) para eliminar los grupos de estilos no utilizados. Los preprocesadores también minifican tu CSS eliminando todos los espacios y saltos de línea. Consulta también cómo corregir 'eliminar CSS no utilizado'.

Compresión: Comprime las hojas de estilo con compresión Brotli o Gzip.

3. JavaScript

Los archivos JavaScript en el head de la página se descargan con alta prioridad por defecto y bloquean el renderizado de la página mientras se descargan y ejecutan. Por lo tanto, el JavaScript es una parte estándar de la cadena de peticiones críticas.

Defer y Async: Ajusta la prioridad de los archivos JavaScript cargándolos de forma asíncrona mediante el atributo async o defer. Los scripts async se descargan en paralelo con prioridad baja. Los scripts defer también se descargan en paralelo y su ejecución se retrasa hasta después de que el HTML haya sido procesado. Para una comparación completa, consulta async vs defer y cómo afectan a los Core Web Vitals.

// bloquea la carga y la ejecución
<script src="normalscript.js"></script>
// async no bloquea durante la carga, pero sí bloquea durante la ejecución
<script  src="asyncscript.js"></script>
// defer no bloquea durante la carga ni durante la ejecución
<script  src="deferscript.js"></script>

Para más técnicas para aplazar el JavaScript, consulta 16 métodos para aplazar o programar el JavaScript. Si tienes JavaScript no utilizado que no se puede aplazar, consulta cómo reducir el JavaScript no utilizado.

Code splitting y preloading: Si la página no permite que el JavaScript se cargue de forma asíncrona, divide el JavaScript en varios archivos. Pon la parte que es crítica durante la carga de la página en un archivo pequeño y hazle preload. Pon el JavaScript no crítico en otro archivo y deja que se cargue con defer o async.

Minifica: Reduce el número de bytes mediante un minificador de JavaScript. Los bundlers modernos como webpack, Rollup y Vite usan terser internamente para analizar el JavaScript y hacerlo lo más pequeño posible.

Compresión: Reduce el número de bytes comprimiendo el JavaScript mediante Gzip o Brotli.

4. Web fonts

Las web fonts suelen ser los últimos archivos en la cadena de peticiones críticas. Esto se debe a que las web fonts dependen del descubrimiento: solo se cargan cuando un navegador descubre que son necesarias. Para ello, un navegador primero debe analizar el HTML y buscar en la hoja de estilo qué fuente se usa.

Preloading: Cuando sabes que vas a usar una fuente, es más rápido hacerle preload. La fuente se descarga entonces lo antes posible, minimizando la influencia en la cadena de peticiones críticas. Hazle preload a una fuente añadiendo este código lo antes posible en el head de la página:

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

Estrategia de fuentes: Hay muchas otras formas de hacer que las fuentes carguen más rápido. Consulta cómo alojar Google Fonts tú mismo y cómo asegurar que el texto sigue visible durante la carga de la webfont.

• Usa siempre web fonts alojadas por ti mismo, nunca fuentes alojadas remotamente como Google Fonts.
• Reduce el tamaño de la fuente con el font subsetting.
• Carga las fuentes no críticas a través de la FontFace API.
• Usa font-display: swap para evitar que las fuentes bloqueen el renderizado inicial.
• Deja que los navegadores generen sus propias variantes de fuentes mediante font synthesis.

5. Imágenes

Las imágenes que aparecen en el viewport visible durante la carga de la página también pueden recibir alta prioridad y pueden interferir con la ruta crítica. Cuando estés seguro de que una imagen siempre aparecerá en la parte visible del sitio web, hazle preload a esta imagen. Añade fetchpriority="high" para decirle al navegador que es la imagen más importante de la página:

<link rel="preload" as="image" href="important-image.webp">

Para todas las imágenes que no son visibles de inmediato, usa el lazy loading. Usa loading="lazy" para retrasar la carga de la imagen hasta justo antes de que se vuelva visible:

<img loading="lazy" src="lazy-image.webp" width="20" height="20" alt="...">

6. Peticiones AJAX

Las peticiones AJAX siempre reciben alta prioridad. Por lo tanto, pospón las peticiones AJAX hasta que la página termine de renderizarse. Espera a que la página envíe el evento "load":

window.addEventListener('load', (event)=>{
  console.log('este es un buen momento para una petición AJAX');
});

Si no es posible posponer la petición AJAX, puedes hacer preload al recurso para que esté disponible para el navegador antes.

7. Iframes

Los iframes normalmente se descargan con alta prioridad. Porque un iframe en realidad es una página dentro de una página, un iframe puede causar un retraso significativo en los tiempos de carga. Los recursos que requiere el iframe también pueden descargarse con alta prioridad y formar su propia cadena de peticiones críticas. El uso de iframes por lo tanto puede afectar significativamente a tus Core Web Vitals.

Puedes retrasar la carga de un iframe mediante el atributo loading="lazy". Eso a menudo marca una gran diferencia cuando el iframe no es visible de inmediato durante la carga. Para tener más control sobre el tiempo, inyecta el iframe a través de JavaScript para asegurarte de que no termina en la cadena de peticiones críticas. Consulta cómo incrustar Google Maps sin perjudicar a tu PageSpeed y cómo incrustar YouTube con unos Core Web Vitals perfectos para ver ejemplos de esta técnica.

Verifica tus mejoras

Después de optimizar tu cadena crítica, verifica la mejora con Real User Monitoring. Tu FCP y tu LCP deberían mejorar. Las herramientas de lab data como Lighthouse te dan feedback instantáneo, pero los field data de usuarios reales son los que cuentan para los Core Web Vitals.