Optimizar la LCP Resource Load Duration

Esta guía forma parte de la sección Largest Contentful Paint (LCP) de nuestro centro de recursos de Core Web Vitals. La Resource Load Duration es la tercera de las cuatro fases secuenciales del LCP, midiendo el tiempo que se tarda en descargar el recurso LCP a través de la red. Aunque el Resource Load Delay suele representar una mayor parte del tiempo del LCP, optimizar la duración de la descarga sigue siendo esencial para lograr una buena puntuación de LCP.

Optimizar la LCP Resource Load Duration

El Largest Contentful Paint (LCP) es una de las tres métricas de rendimiento de Core Web Vitals que miden su experiencia de usuario en línea. El LCP captura el tiempo que tarda el elemento de contenido más grande (una imagen, un video o un bloque de texto) en hacerse visible en el viewport. La Resource Load Duration es una subparte del LCP que indica cuánto tiempo se dedica a obtener el recurso de red para el elemento LCP.

¿Qué es la Resource Load Duration en el LCP?

La Resource Load Duration, a menudo llamada Load Duration, se refiere al tiempo necesario para que el navegador descargue el recurso de red (por ejemplo, una imagen) que eventualmente se convertirá en el elemento LCP. Para imágenes y videos, esta duración abarca desde que la imagen comienza a descargarse hasta que el navegador completa la descarga. Para los elementos LCP basados en texto, la duración de la carga suele ser cero. La guía de optimización de LCP de Google divide el LCP en cuatro subpartes secuenciales, siendo la Resource Load Duration el tiempo dedicado a descargar realmente los bytes del recurso.

La Resource Load Duration se mide desde el momento en que el navegador comienza a descargar el recurso LCP hasta que ha terminado de descargarse. Cuatro factores principales determinan la duración de la carga del recurso:

• Tamaño del archivo: Los archivos más grandes requieren tiempos de descarga más largos.
• Velocidad de la red: Las conexiones más lentas extienden naturalmente la duración de la carga.
• Capacidad de respuesta del servidor: Los retrasos en la respuesta del servidor ralentizan la obtención de recursos.
• Descargas concurrentes: Los recursos descargados simultáneamente compiten por el ancho de banda, lo que puede aumentar los tiempos de carga.

Cómo detectar la Resource Load Duration

Existen dos formas eficaces de identificar y medir la duración de la carga del recurso:

Inspección de red en Chrome DevTools: Use el atajo Ctrl + Shift + I para abrir las Herramientas para Desarrolladores de Chrome, luego seleccione la pestaña "Network" y recargue la página. Busque el elemento LCP en las solicitudes de red (si desea saber cuál es el elemento LCP, pruebe el Visualizador de Core Web Vitals). El inspector de red le mostrará cuánto tiempo se tardó en descargar el recurso.

Consejo Pro: Habilite las filas de solicitud grandes para ver detalles adicionales como la latencia de LCP, el tamaño transferido y el tamaño real.

Usar datos de Real User Monitoring (RUM):

Las herramientas de RUM a menudo registran datos de atribución de LCP. Los datos de atribución para el Largest Contentful Paint contienen información sobre la resource load duration. Con estos datos, puede graficar las tendencias de la duración de la carga a lo largo del tiempo o por página y detectar las páginas o elementos que ralentizan las cosas.

Cómo mejorar la LCP Load Duration

Los problemas de duración de la carga de recursos ocurren cuando los recursos son demasiado grandes o se entregan a través de rutas de red subóptimas. Dos enfoques principales abordan esto: reducir el tamaño de los datos o optimizar la entrega de los datos.

1. Optimizar el tamaño del archivo

Optimizar el tamaño del archivo reduce el número de bytes que deben enviarse por la red. Menos datos significan menos tiempo de descarga. Para una guía completa sobre la optimización de imágenes, consulte nuestro artículo sobre cómo optimizar las imágenes.

Usar formatos de imagen modernos

AVIF y WebP son las mejores opciones para la compresión de imágenes. AVIF comprime hasta un 50% más que WebP para fotos complejas, sin pérdida de calidad visible. WebP tiene un soporte de navegador más amplio y funciona bien para imágenes más simples. Según el Web Almanac 2025, el WebP se utiliza ahora en más del 40% de las solicitudes de imágenes, mientras que la adopción de AVIF se ha duplicado aproximadamente año tras año, pero sigue estando por debajo del 10%.

Elegir el ajuste de calidad adecuado

Los formatos de imagen modernos como WebP y AVIF permiten una reducción significativa de la calidad antes de que la degradación visual sea perceptible. Como regla general, un ajuste de calidad entre 75 y 85 para WebP, y entre 60 y 75 para AVIF, se verá idéntico al original a distancias de visualización normales, pero con una fracción del tamaño del archivo. Pruebe siempre con sus imágenes específicas, ya que la calidad óptima depende del tipo de contenido (fotografías vs. ilustraciones vs. imágenes con mucho texto).

Automatizar la compresión de imágenes con Sharp

Para la optimización de imágenes en el momento de la construcción (build), la biblioteca sharp es una de las herramientas más rápidas y utilizadas en el ecosistema de Node.js. El siguiente ejemplo muestra cómo convertir y comprimir una imagen a los formatos WebP y AVIF con ajustes de calidad optimizados:

const sharp = require('sharp');

// Convertir a WebP con calidad optimizada
await sharp('input.jpg')
  .resize(1200)  // Cambiar el tamaño al ancho máximo necesario
  .webp({ quality: 80, effort: 6 })
  .toFile('output.webp');

// Convertir a AVIF con calidad optimizada
await sharp('input.jpg')
  .resize(1200)
  .avif({ quality: 65, effort: 6 })
  .toFile('output.avif');

// Generar múltiples tamaños para imágenes responsivas
const widths = [400, 800, 1200];
for (const width of widths) {
  await sharp('input.jpg')
    .resize(width)
    .webp({ quality: 80 })
    .toFile(`output-${width}w.webp`);
}

Este enfoque genera todas las variantes que necesita para un elemento <picture> responsivo con soporte de formatos modernos. Para los sitios de WordPress, los plugins como ShortPixel o Imagify gestionan esta conversión automáticamente al subir la imagen.

Imágenes responsivas

El elemento <picture> y el atributo srcset sirven diferentes tamaños de imagen según la pantalla: versiones más pequeñas para móviles, mayor resolución para pantallas más grandes. He aquí un ejemplo de configuración:

<picture>
  <source media="(min-width: 800px)" srcset="large.jpg 1x, larger.jpg 2x">
  <img src="photo.jpg" alt="Descripción" width="800" height="450">
</picture>

Dimensiones de imagen correctas

Las imágenes responsivas son solo parte de la solución porque responsivo no significa que tengan el tamaño adecuado. Ajustar las dimensiones de la imagen a su tamaño de visualización es uno de los errores más comunes que veo. Servir una imagen de 2000px de ancho para un área de visualización de 500px desperdicia ancho de banda y puede ralentizar notablemente los tiempos de carga.

Optimización de archivos de fuentes

Cuando el elemento LCP es texto renderizado con una fuente web personalizada, el archivo de la fuente se convierte en el recurso LCP. Optimice la duración de la carga de la fuente mediante:

• Usar el formato WOFF2: WOFF2 proporciona la mejor compresión para fuentes web, normalmente un 30% más pequeña que WOFF y significativamente más pequeña que los archivos TTF o OTF.
• Subconjuntos de fuentes (subsetting): Si su sitio solo utiliza caracteres latinos, cree un subconjunto de la fuente para eliminar los juegos de caracteres no utilizados (cirílico, griego, CJK). Herramientas como glyphhanger o pyftsubset pueden automatizar esto, reduciendo a menudo el tamaño del archivo de la fuente en un 50% o más.
• Limitar las variantes de fuente: Cada peso y estilo (normal, negrita, cursiva) es una descarga de archivo independiente. Incluya solo los pesos que su diseño utiliza realmente.

2. Mejorar el rendimiento de la red

Una vez optimizados los tamaños de los recursos, el siguiente paso es maximizar la velocidad de la red, o incluso saltarse la red por completo.

Evitar la necesidad de red con el almacenamiento en caché del navegador

No hay conexión de red más rápida que una conexión de red omitida. Los navegadores pueden servir contenido estático (imágenes, scripts, hojas de estilo) directamente desde la caché local. Configure el servidor para que envíe las instrucciones de almacenamiento en caché correctas al navegador.

La configuración más eficaz es enviar una cabecera Cache-Control como esta:

Cache-Control: public, max-age=31536000, immutable

• public: Permite que el recurso sea almacenado en caché tanto por los navegadores como por las cachés intermedias.
• max-age=31536000: Establece el tiempo máximo que el recurso se considera fresco en un año (31.536.000 segundos).
• immutable: Indica que el recurso no cambiará con el tiempo, evitando solicitudes de revalidación innecesarias.

Para que esta estrategia funcione de forma segura, utilice nombres de archivo con hash de contenido (por ejemplo, hero-abc123.webp) para que, cuando la imagen cambie, el nombre del archivo también cambie, invalidando la caché automáticamente.

Compresión Brotli vs. Gzip

Para los recursos basados en texto (HTML, CSS, JavaScript, SVG), la compresión en el lado del servidor es esencial. Brotli, desarrollado por Google, supera sistemáticamente a Gzip en relación de compresión manteniendo velocidades de descompresión comparables. La siguiente comparación ilustra la diferencia:

La configuración ideal es pre-comprimir los recursos estáticos con Brotli a un nivel de compresión alto (por ejemplo, nivel 11) durante su proceso de construcción (build), y usar Gzip como respaldo para los clientes que no soportan Brotli. La mayoría de los CDNs, incluido Cloudflare, gestionan esto automáticamente. Para más detalles sobre la configuración del CDN, consulte nuestra guía sobre configuración de Cloudflare para el rendimiento.

HTTP/2 y HTTP/3: Beneficios de los protocolos modernos

El protocolo de entrega es más importante cuando el navegador descarga varios recursos al mismo tiempo.

• HTTP/2 introdujo la multiplexación, que permite enviar múltiples solicitudes y respuestas simultáneamente a través de una única conexión TCP. Esto elimina el problema de bloqueo de cabeza de línea de HTTP/1.1, donde un recurso lento podía retrasar a todos los demás. HTTP/2 también admite la compresión de cabeceras (HPACK) y el server push.
• HTTP/3 va más allá al sustituir TCP por QUIC, un protocolo basado en UDP. HTTP/3 elimina el bloqueo de cabeza de línea a nivel de TCP (donde un solo paquete perdido detiene todos los flujos), proporciona un establecimiento de conexión más rápido a través de 0-RTT (reanudación del tiempo de ida y vuelta cero para los visitantes que regresan) y gestiona la pérdida de paquetes de forma más elegante. Estas mejoras aceleran principalmente el Time to First Byte, pero también reduzen la resource load duration.

Para comprobar si HTTP/3 está habilitado, simplemente inspeccione su red con el atajo Ctrl+Shift+I. Seleccione la pestaña de red, haga clic con el botón derecho en las cabeceras de las columnas de red y asegúrese de que 'protocol' esté habilitado. Recargue la página y compruebe el protocolo. Para HTTP/3, el protocolo debería decir 'h3'.

Redes de entrega de contenido (CDN)

Un CDN es una red de servidores distribuidos que almacenan en caché y sirven recursos estáticos como imágenes, CSS y JavaScript desde ubicaciones más cercanas al usuario. Esto reduce el tiempo de viaje de los datos (el tiempo de ida y vuelta), lo que afecta directamente a la Resource Load Duration.

Más allá de la proximidad, los CDNs modernos ofrecen varias ventajas de rendimiento que reducen la duración de la carga:

• Optimización automática de imágenes: Muchos CDNs pueden comprimir, redimensionar y convertir imágenes sobre la marcha. Por ejemplo, Cloudflare Polish, Imgix y Cloudinary pueden servir WebP o AVIF automáticamente basándose en la cabecera Accept del navegador.
• Edge caching: Los recursos estáticos se almacenan en caché en los nodos de borde de todo el mundo, eliminando por completo la necesidad de obtenerlos del servidor de origen.
• Optimización de protocolos: Los CDNs suelen habilitar HTTP/2 y HTTP/3 por defecto, junto con la compresión Brotli, sin requerir cambios en la configuración del servidor.
• Reutilización de conexiones: Dado que el CDN sirve todos los recursos desde un único dominio, el navegador reutiliza una sola conexión, eliminando la sobrecarga de múltiples búsquedas DNS y handshakes TLS.

Los CDNs de imágenes especializados pueden ir más allá proporcionando optimizaciones automáticas en tiempo real, como la conversión de formato, el redimensionamiento y la compresión.

Auto-alojamiento de recursos

Los recursos de red importantes y tempranos deberían, por defecto, estar siempre alojados en el servidor de origen. El auto-alojamiento evita la necesidad de conectarse a servidores de terceros, lo que puede causar retrasos considerables debido a búsquedas DNS adicionales, negociaciones SSL y configuraciones de conexión. El auto-alojamiento garantiza la reutilización de una única conexión ya abierta y reduce la sobrecarga de establecer conexiones independientes. Los recursos auto-alojados también permiten un control total sobre las políticas de compresión y caché.

3. Optimizar la priorización de recursos

Después de recortar el tamaño de los recursos y optimizar la red, también existe el problema de la competencia de red. Cuando el navegador solicita varios recursos al mismo tiempo en una conexión lenta, estos compiten por el ancho de banda. Minimice esa competencia programando las descargas de recursos.

Priorizar los recursos críticos

Marque los recursos esenciales, como las imágenes hero o el CSS que aparece en la parte superior de la página (above-the-fold), con fetchpriority="high". Esto indica al navegador que descargue estos recursos primero, evitando que se vean frenados por scripts, widgets o elementos de terceros que no necesitan una carga instantánea. Priorizar estos recursos críticos reduce el tiempo de carga del contenido que más les importa a sus usuarios. La combinación de preload (para solucionar el descubrimiento tardío) y fetchpriority="high" (para solucionar la competencia de red) es la técnica más potente para garantizar que el recurso LCP se obtenga lo antes posible y con la mayor rapidez.

<!-- Para imágenes LCP visibles en el HTML inicial -->
<img src="hero-image.webp" fetchpriority="high" alt="...">

<!-- Para mejorar el descubrimiento  -->
<link rel="preload" href="hero-image.webp" as="image" fetchpriority="high">

Reducir la competencia de red

Agilice las descargas iniciales difiriendo o cargando de forma perezosa (lazy-loading) los recursos no esenciales. Posponga la carga de cualquier imagen o video que no sea visible de inmediato, así como de los elementos de fondo o secundarios. Utilizar loading="lazy" para los medios que están fuera de la pantalla es un buen punto de partida, mientras que diferir aún más otros scripts y recursos no esenciales liberará ancho de banda y reducirá cualquier competencia con sus recursos críticos, manteniendo el contenido principal de su página rápido de cargar y mostrar. Nunca aplique loading="lazy" a su imagen LCP; este es un anti-patrón crítico que perjudicará su puntuación.

4. Configurar Speculation Rules

Las Speculation Rules permiten a los navegadores realizar prefetch o prerender de páginas web basándose en la navegación prevista del usuario. El prefetching elimina eficazmente la subparte Time to First Byte del LCP y no tiene impacto en la resource load duration. El prerendering renderiza la página siguiente en una pestaña oculta y descarga todos los recursos de la página. Esto elimina la mayor parte de las duraciones de carga para el elemento LCP, como se muestra en este ejemplo de desglose de LCP de una página pre-renderizada.

Próximos pasos: Continuar optimizando el LCP

La Resource Load Duration es solo una de las cuatro fases del LCP. Después de optimizar el tiempo de descarga, continúe con las otras fases del LCP:

• Corregir e identificar problemas de LCP: La metodología de diagnóstico completa para encontrar y corregir todos los problemas de LCP utilizando datos de campo y herramientas de laboratorio.
• Optimizar la imagen LCP: Selección del formato de imagen, imágenes responsivas, preloading y errores comunes de optimización de imágenes.
• Resource Load Delay: Asegúrese de que el navegador descubra el recurso LCP lo antes posible. Esto suele ser un cuello de botella mayor que la propia duración de la carga.
• Element Render Delay: Después de que el recurso se descargue, asegúrese de que el navegador pueda pintarlo de inmediato liberando el main thread.