¿Qué es la carga de recursos?

¿Qué es la carga de recursos?

La carga de recursos es la forma en que el navegador encuentra, solicita, prioriza y procesa los archivos que necesita una página: HTML, CSS, JavaScript, fuentes, imágenes, vídeo y llamadas a API. El orden y el momento de esas peticiones deciden cuándo aparece el contenido y cuándo responde la página. Muchas veces una página es lenta no porque sus archivos sean enormes, sino porque un archivo importante empieza a descargarse demasiado tarde.

Cómo carga recursos el navegador

El navegador descarga primero el HTML y va encontrando más archivos al leerlo: un enlace a una hoja de estilos, una etiqueta script, una imagen. Algunos los descubre aún más tarde, como una fuente indicada dentro de una hoja de estilos o una imagen definida como fondo en CSS. Además, cada archivo de un origen nuevo paga la resolución DNS, la conexión y el TLS antes de que se mueva el primer byte. Por el camino, el navegador asigna una prioridad a cada petición. Por defecto, las imágenes empiezan con prioridad baja y solo suben cuando el diseño las encuentra en el viewport (web.dev, «Optimize resource loading with the Fetch Priority API»). Las hojas de estilos y los scripts clásicos del head pueden retrasar el primer pintado: es la ruta de renderizado crítica.

Cuatro formas de mejorarla

• Descubrir antes los archivos importantes. Usa resource hints: preload para una imagen principal o una fuente clave y preconnect para un origen de terceros que seguro vas a usar.
• Cargar después lo que no es crítico. Añade defer o async a los scripts (ver carga asíncrona) y usa carga diferida (lazy loading) para imágenes e iframes fuera de la parte visible.
• Subir o bajar la prioridad. El atributo fetchpriority (high, low, auto) funciona en img, script y link. Es una indicación, no una orden, y no hace que el navegador encuentre antes el archivo. Según web.dev, lo admiten Chrome y Edge 102, Firefox 132 y Safari 17.2.
• Cargar menos y desde más cerca. Elimina el código sin usar, comprime los archivos y sírvelos desde una CDN para acortar cada ida y vuelta. Unas buenas cabeceras de caché permiten que las visitas repetidas se salten la descarga.

Ejemplo

Una página de producto tiene una imagen principal grande, seis imágenes de galería debajo, un script de analítica y un widget de chat. Cargado sin criterio, el navegador lanza todo a la vez y la imagen principal compite por el ancho de banda con el chat. Mejor plan: marcar la imagen principal con fetchpriority="high", poner loading="lazy" a la galería, añadir defer al script de analítica y cargar el chat cuando la página ya sea interactiva.

<img src="/hero.webp" fetchpriority="high" alt="Producto">
<img src="/gallery-1.webp" loading="lazy" alt="Detalle">
<script src="/analytics.js" defer></script>

web.dev cuenta una prueba de Google Flights en la que marcar la imagen LCP con fetchpriority="high" mejoró el LCP de 2,6 s a 1,9 s. Es un solo sitio con una configuración concreta, así que mide tu propia página.

Errores frecuentes

• Cargar la imagen principal en diferido. Le dice al navegador que espere por algo que el visitante ve al instante, y retrasa el Largest Contentful Paint.
• Precargarlo todo. Los hints compiten entre sí y, pasados unos pocos, dejan de ayudar. Resérvalos para los archivos que condicionan el primer renderizado.
• Muchos orígenes de terceros. Cada uno necesita su propia conexión y puede frenar la página si es lento.
• Scripts async que dependen entre sí. Con async el orden no está garantizado; usa defer.
• Ignorar las visitas repetidas. Sin cabeceras de caché, quien vuelve descarga todo otra vez.

Relación con las pruebas y el monitoreo

La herramienta principal es la cascada de red: muestra qué empezó cuándo, qué esperó a qué y qué peticiones quedaron bloqueadas. Revísala con una conexión limitada y desde más de una ubicación, porque la distancia cambia el coste de la conexión. LoadFocus Page Speed Monitoring ejecuta auditorías de Google Lighthouse programadas desde 25 regiones en la nube, para ver si un cambio en la carga ayudó en todas partes o solo cerca de tu servidor. El verificador gratuito de Core Web Vitals muestra LCP, INP y CLS de usuarios reales a partir de los datos CrUX de Google. Para una lista más amplia de mejoras, lee la guía de 10 pasos para acelerar tu web.

Preguntas frecuentes: carga de recursos

¿Qué diferencia hay entre carga de recursos y lazy loading?

La carga de recursos es todo el proceso de descargar los archivos de una página. El lazy loading es una técnica dentro de él: retrasa archivos, normalmente imágenes e iframes, hasta que están a punto de verse.

¿En qué orden carga recursos un navegador?

Empieza por el HTML y luego pide los archivos que encuentra al analizarlo, cada uno con una prioridad. Los archivos citados dentro del CSS, como fuentes e imágenes de fondo, se descubren más tarde, y por eso existen hints como preload.

¿Qué hace fetchpriority?

Pide al navegador que descargue un recurso con más o menos prioridad que la habitual. Es una indicación que el navegador puede ignorar y no ayuda a descubrir un archivo antes.

¿Cargar JavaScript bloquea el renderizado?

Un script clásico sin async, defer ni type module bloquea el análisis del HTML mientras se descarga y se ejecuta. Con defer o async se evita.

¿Cómo veo cómo se cargan mis recursos?

Abre el panel Network de las DevTools del navegador, o ejecuta una auditoría de Lighthouse y lee su cascada y la lista de recursos que bloquean el renderizado.