Corregir "Avoid Chaining Critical Requests" en Lighthouse

Cómo se determina la prioridad de descarga

Las solicitudes 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?

La prioridad de descarga la determina el propio navegador. El navegador sigue un conjunto de reglas para determinar la prioridad de cada recurso. Los elementos que finalmente reciben la prioridad más alta dependen de la estructura de la página. Los elementos que el navegador considera necesarios para el primer renderizado de la página reciben la prioridad más alta.

Inicialmente, el navegador hace una conjetura fundamentada sobre qué elementos son más importantes. En términos generales, la prioridad de descarga funciona así: el HTML siempre tiene la prioridad más alta, seguido de las hojas de estilo, el JavaScript síncrono, las fuentes, las solicitudes AJAX, las imágenes en la parte superior de la página, las imágenes más adelante en la página y, por último, el JavaScript asíncrono.

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

Puede ver qué recursos tienen prioridad alta en su página. Abra las DevTools con Ctrl+Shift+J. Vaya a la pestaña Network, haga clic derecho en los nombres de las columnas y seleccione 'Priority'.

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

Al cargar una página, el navegador comienza en modo "display blocking". En este modo, los recursos más importantes se descargan con alta prioridad. Esos son los recursos críticos.

Un navegador no comenzará (totalmente) a renderizar la página hasta que se hayan descargado todos los recursos críticos. Por lo tanto, 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 pantalla y menos competencia habrá por la CPU y otros recursos.

Según el Web Almanac 2025, solo el 15% de las páginas móviles superan la auditoría de recursos que bloquean el renderizado. Eso significa que el 85% de la web todavía tiene problemas de cadenas críticas por resolver. Esta es una de las razones principales por las que solo el 55% de los orígenes móviles obtienen una puntuación "buena" en el First Contentful Paint. En los sitios monitorizados por CoreDash, los orígenes con menos de 3 solicitudes en la cadena crítica tienen un FCP mediano de 1,2 segundos, en comparación con los 2,4 segundos de los orígenes con 8 o más solicitudes 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 solicitudes de red de alta prioridad y señala cuando es demasiado profunda.

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

Puede reducir el impacto de las solicitudes críticas de tres maneras:

1. Reducir el número de recursos críticos. Convierta los recursos críticos en no críticos eliminándolos o difiriéndolos.
2. Reducir 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 subsetting de fuentes ayudan.
3. Mejorar el orden de descarga de la ruta crítica. Use resource hints como el preloading para omitir el descubrimiento de recursos y asegurar que los recursos críticos se descarguen lo más rápido posible. Use HTTP 103 Early Hints para comenzar a precargar recursos incluso antes de que llegue el HTML.

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

1. HTML

El propio HTML siempre se descarga con la prioridad más alta. La página siempre forma parte de la cadena de solicitudes 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, utilizan esta técnica para reducir la cadena de solicitudes críticas. En la página de resultados de búsqueda, por ejemplo, las partes del contenido que no se necesitan de inmediato solo se cargan más tarde mediante una solicitud AJAX.

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

Compresión: Comprima su HTML con Brotli o Gzip. Brotli suele lograr 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, el navegador no sabe cómo se verá la página. Por lo tanto, las hojas de estilo forman parte estándar de la cadena de solicitudes críticas.

CSS crítico: La forma más efectiva de romper la cadena de CSS es insertar el CSS crítico directamente en una etiqueta <style> en el <head>. Esto elimina por completo la solicitud de red que bloquea el renderizado. Puede generar CSS crítico mediante herramientas NodeJS o mediante el Generador de CSS Crítico. Coloque el CSS crítico en línea y cargue el resto con una prioridad menor:

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

Observe que ahora ocurre algo extraño en la página. Primero se muestra la página sin estilos y, solo después de cargar el CSS, se aplica el estilo. Todo el contenido parpadeará de sin estilo a con estilo. Por eso necesita el CSS crítico: las reglas CSS para la parte visible de la página se insertan en línea, de modo que la página se vea correcta de inmediato, y el resto del CSS se carga sin bloquear el renderizado.

Evitar cadenas de @import en CSS: Si sus archivos CSS usan @import para cargar otros archivos CSS, crea una cadena en la que el navegador debe descargar el archivo A antes de descubrir que necesita el archivo B. Reemplace las sentencias @import por etiquetas <link> separadas o concatene los archivos en el momento de la compilación. Esta es una de las causas más comunes de cadenas críticas innecesariamente profundas.

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

<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 con alta prioridad las hojas de estilo cuyo atributo media coincida con el dispositivo actual. Las hojas de estilo que no coinciden se descargan con prioridad baja y no bloquean el renderizado.

Minificar: Elimine el CSS no utilizado. Muchos sitios utilizan bibliotecas CSS como Bootstrap. Estas bibliotecas suelen estar sobredimensionadas y no se utilizan todas las declaraciones de estilo. Edite estas bibliotecas a través de un preprocesador CSS (como Sass) para eliminar los grupos de estilos no utilizados. Los preprocesadores también minifican su CSS eliminando todos los espacios y saltos de línea. Consulte también cómo corregir 'remove unused CSS'.

Compresión: Comprima 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 forma parte estándar de la cadena de solicitudes críticas.

Defer y Async: Ajuste 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 una prioridad menor. Los scripts diferidos (defer) también se descargan en paralelo y su ejecución se retrasa hasta después de que se haya analizado el HTML. Para una comparación completa, consulte 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 async src="asyncscript.js"></script>
\/\/ defer no bloquea durante la carga ni durante la ejecución
<script defer src="deferscript.js"></script>

Para conocer más técnicas para diferir JavaScript, consulte 16 métodos para diferir o programar JavaScript. Si tiene JavaScript no utilizado que no se puede diferir, consulte cómo reducir el JavaScript no utilizado.

Code splitting y preloading: Si la página no permite cargar JavaScript de forma asíncrona, divida el JavaScript en varios archivos. Coloque la parte que es crítica durante la carga de la página en un archivo pequeño y realice un preload. Coloque el JavaScript no crítico en otro archivo y deje que se cargue de forma diferida o asíncrona.

Minificar: Reduzca el número de bytes a través de un minificador de JavaScript. Los empaquetadores modernos como webpack, Rollup y Vite utilizan terser internamente para analizar el JavaScript y hacerlo lo más pequeño posible.

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

4. Web fonts

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

Preloading: Cuando sepa que va a utilizar una fuente, es más rápido realizar un preload de esta fuente. La fuente se descarga entonces lo antes posible, minimizando la influencia en la cadena de solicitudes críticas. Realice el preload de 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 se carguen más rápido. Consulte cómo auto-alojar Google Fonts y cómo garantizar que el texto permanezca visible durante la carga de webfonts.

• Utilice siempre fuentes web auto-alojadas, nunca fuentes alojadas de forma remota como Google Fonts.
• Reduzca el tamaño de la fuente con el subsetting de fuentes.
• Cargue fuentes no críticas a través de la API FontFace.
• Use font-display: swap para evitar que las fuentes bloqueen el renderizado inicial.
• Permita que los navegadores generen sus propias variantes de fuentes mediante la síntesis de fuentes.

5. Imágenes

Las imágenes que aparecen en el viewport visible durante la carga de la página también pueden recibir una prioridad alta y pueden interferir con la ruta crítica. Cuando esté seguro de que una imagen aparecerá siempre en la parte visible del sitio web, realice un preload de esta imagen. Añada fetchpriority="high" para indicarle 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 sean visibles de inmediato, realice un lazy load de estas imágenes. Use 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. Solicitudes AJAX

A las solicitudes AJAX siempre se les asigna una prioridad alta. Por lo tanto, posponga las solicitudes AJAX hasta que la página haya terminado de renderizarse. Espere hasta que la página haya enviado el evento "load":

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

Si no es posible posponer la solicitud AJAX, puede realizar un preload del recurso para que esté disponible para el navegador antes.

7. Iframes

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

Puede retrasar la carga de un iframe mediante el atributo loading="lazy". Eso suele marcar una gran diferencia cuando el iframe no es visible de inmediato durante la carga. Para tener más control sobre el tiempo, inyecte el iframe a través de JavaScript para asegurarse de que no acabe en la cadena de solicitudes críticas. Consulte cómo insertar Google Maps sin perjudicar su PageSpeed y cómo insertar YouTube con unos Core Web Vitals perfectos para ver ejemplos de esta técnica.

Verifique sus mejoras

Después de optimizar su cadena crítica, verifique la mejora con Real User Monitoring. Tanto su FCP como su LCP deberían mejorar. Las herramientas de laboratorio como Lighthouse le ofrecen feedback instantáneo, pero los datos de campo de usuarios reales son lo que cuenta para los Core Web Vitals.