Optimiza la duración de carga del recurso LCP

Esta guía es parte de la sección de Largest Contentful Paint (LCP) de nuestro centro de recursos de Core Web Vitals. La duración de carga del recurso es la tercera de las cuatro fases secuenciales del LCP. Mide el tiempo necesario para descargar el recurso del 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 descarga sigue siendo esencial para lograr una buena puntuación del LCP.

Optimiza la duración de carga del recurso del LCP

El Largest Contentful Paint (LCP) es una de las tres métricas de rendimiento de Core Web Vitals que miden la experiencia de tu usuario en línea. El LCP captura el tiempo que tarda el elemento de contenido más grande (una imagen, un vídeo o un bloque de texto) en ser visible en el viewport. La duración de carga del recurso es una subparte del LCP que indica cuánto tiempo se dedica a obtener el recurso de red para el elemento del LCP.

¿Qué es la duración de carga del recurso en el LCP?

La duración de carga del recurso, a menudo llamada duración de carga, es el tiempo que necesita el navegador para descargar el recurso de red (como una imagen) que finalmente será el elemento del LCP. Para imágenes y vídeos, esta duración abarca desde que la imagen comienza a descargarse hasta que el navegador completa la descarga. Para elementos del LCP de texto, la duración de carga suele ser cero. La guía de optimización del LCP de Google divide el LCP en cuatro subpartes secuenciales. La duración de carga del recurso es el tiempo que se invierte en descargar realmente los bytes del recurso.

La duración de carga del recurso se mide desde el momento en que el navegador comienza a descargar el recurso del LCP hasta que termina la descarga. Cuatro factores principales determinan la duración de 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 prolongan de forma natural la duración de carga.
• Respuesta del servidor: Los retrasos en la respuesta del servidor ralentizan la obtención de recursos.
• Descargas simultáneas: Los recursos descargados a la vez compiten por el ancho de banda. Esto puede aumentar los tiempos de carga.

Cómo detectar la duración de carga del recurso

Hay dos formas efectivas de identificar y medir la duración de carga del recurso:

Inspección de red en Chrome DevTools: Usa el atajo Ctrl + Shift + I para abrir las Developer Tools de Chrome. Selecciona la pestaña "Network" y recarga la página. Busca el elemento del LCP en las peticiones de red (si quieres saber cuál es el elemento del LCP, prueba el Core Web Vitals Visualizer). El inspector de red te mostrará cuánto tiempo tardó en descargarse el recurso.

Consejo experto: Activa las filas de peticiones grandes para ver detalles adicionales, como la latencia del LCP, el tamaño transferido y el tamaño real.

Usa datos de Real User Monitoring (RUM):

Las herramientas de RUM suelen registrar datos de atribución del LCP. Los datos de atribución del Largest Contentful Paint contienen información sobre la duración de carga del recurso. Con estos datos puedes crear gráficos de tendencias de la duración de carga a lo largo del tiempo o por página. Así detectarás las páginas o elementos que ralentizan todo.

Guía paso a paso: Para una medición precisa en laboratorio, graba una traza en el panel Performance. El desglose del LCP muestra la duración de carga del recurso junto a las otras tres subpartes. Guía completa: Diagnostica el LCP con el panel Performance de Chrome DevTools.

Cómo mejorar la duración de carga del LCP

Los problemas de duración de carga del recurso 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 u optimizar la entrega de los datos.

1. Optimiza el tamaño del archivo

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

Usa 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 en fotos complejas, sin pérdida de calidad visible. WebP tiene mayor soporte en los navegadores y funciona bien para imágenes más simples. Según el Web Almanac de 2025, WebP ya se usa en más del 40% de las peticiones de imágenes. La adopción de AVIF casi se ha duplicado año tras año, pero sigue por debajo del 10%.

Elige el ajuste de calidad adecuado

Los formatos de imagen modernos como WebP y AVIF permiten una gran reducción de calidad antes de que la degradación visual sea evidente. Por 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 normales de visión pero con una fracción del tamaño del archivo. Prueba siempre con tus propias imágenes. La calidad óptima depende del tipo de contenido (fotografías, ilustraciones o imágenes con mucho texto).

Automatiza la compresión de imágenes con Sharp

Para la optimización de imágenes durante el build, la biblioteca sharp es una de las herramientas más rápidas y usadas 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)  // Redimensionar 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 necesarias para un elemento <picture> responsivo con soporte de formatos modernos. Para sitios en WordPress, plugins como ShortPixel o Imagify gestionan esta conversión de forma automática al subir los archivos.

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 y mayor resolución para pantallas grandes. Aquí tienes un ejemplo de configuración:

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

Dimensiones correctas de la imagen

Las imágenes responsivas son solo una parte de la solución. Que sean responsivas no significa que tengan el tamaño correcto. No 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 2000 px de ancho para un área de visualización de 500 px desperdicia ancho de banda y puede ralentizar visiblemente los tiempos de carga.

Optimización de archivos de fuentes

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

• Usa el formato WOFF2: WOFF2 ofrece la mejor compresión para fuentes web. Suele ser un 30% más pequeño que WOFF y mucho más ligero que los archivos TTF u OTF.
• Haz subconjuntos de tus fuentes: Si tu sitio solo usa caracteres latinos, haz un subconjunto (subset) de la fuente para eliminar los caracteres que no usas (cirílico, griego, CJK). Herramientas como glyphhanger o pyftsubset automatizan esto. A menudo reducen el tamaño del archivo de la fuente en un 50% o más.
• Limita las variaciones de la fuente: Cada peso y estilo (regular, negrita, cursiva) es una descarga independiente. Incluye solo los pesos que tu diseño usa realmente.

2. Mejora 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 evitar la red por completo.

Evita la red con la caché del navegador

No hay conexión de red más rápida que la conexión que te saltas. Los navegadores pueden servir contenido estático (imágenes, scripts, hojas de estilo) directamente desde la caché local. Configura el servidor para enviar las instrucciones de caché correctas al navegador.

La configuración más efectiva 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 navegadores como por 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. Esto evita peticiones de revalidación innecesarias.

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

Compresión Brotli vs. Gzip

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

La configuración ideal es precomprimir los activos estáticos con Brotli a un nivel de compresión alto (por ejemplo, nivel 11) durante tu proceso de build. Usa Gzip como fallback para los clientes que no soporten Brotli. La mayoría de los CDN, incluido Cloudflare, gestionan esto automáticamente. Para más detalles sobre la configuración del CDN, consulta nuestra guía sobre cómo configurar Cloudflare para el rendimiento.

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

El protocolo de entrega importa sobre todo cuando el navegador descarga varios recursos a la vez.

• HTTP/2 introdujo la multiplexación. Esto permite enviar múltiples peticiones y respuestas simultáneamente a través de una sola conexión TCP. Elimina el problema del bloqueo de cabecera de HTTP/1.1, donde un recurso lento podía retrasar al resto. HTTP/2 también soporta la compresión de cabeceras (HPACK) y el server push.
• HTTP/3 va más allá al reemplazar TCP por QUIC, un protocolo basado en UDP. HTTP/3 elimina el bloqueo de cabecera a nivel de TCP (donde un solo paquete perdido paraliza todos los flujos). Ofrece un establecimiento de conexión más rápido mediante 0-RTT (reanudación en cero viajes de ida y vuelta para visitantes recurrentes) y maneja la pérdida de paquetes con mayor elegancia. Estas mejoras aceleran principalmente el Time to First Byte, pero también reducen la duración de carga del recurso.

Para comprobar si HTTP/3 está activado, simplemente inspecciona tu red con el atajo Ctrl+Shift+I. Selecciona la pestaña Network, haz clic derecho en las cabeceras de las columnas de red y asegúrate de que 'Protocol' esté activado. Recarga la página y revisa el protocolo. Para HTTP/3, el protocolo debería indicar 'h3'.

Redes de distribución de contenido (CDN)

Un CDN es una red de servidores distribuidos que cachean 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 duración de carga del recurso.

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

• Optimización automática de imágenes: Muchos CDN pueden comprimir, redimensionar y convertir imágenes al vuelo. Por ejemplo, Cloudflare Polish, Imgix y Cloudinary pueden servir WebP o AVIF de forma automática basándose en la cabecera Accept del navegador.
• Edge caching: Los recursos estáticos se cachean en nodos perimetrales en todo el mundo. Esto elimina por completo la necesidad de pedirlos al servidor de origen.
• Optimización de protocolos: Los CDN suelen activar 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 solo dominio, el navegador reutiliza una sola conexión. Esto elimina la sobrecarga de múltiples búsquedas de DNS y handshakes de TLS.

Los CDN especializados en imágenes pueden ir más allá proporcionando optimizaciones automáticas y en tiempo real como conversión de formatos, redimensionado y compresión.

Alojar tus propios recursos (Self-hosting)

Por defecto, los recursos de red tempranos e importantes siempre deben alojarse en el servidor de origen. El autoalojamiento (self-hosting) evita la necesidad de conectar con servidores de terceros. Estas conexiones externas pueden causar retrasos enormes debido a búsquedas adicionales de DNS, negociaciones SSL y el establecimiento de la conexión. Alojar los recursos tú mismo asegura la reutilización de una sola conexión ya abierta. Esto reduce la sobrecarga de establecer conexiones separadas. Los recursos autoalojados también permiten un control total sobre la compresión y las políticas de caché.

3. Optimiza la priorización de los recursos

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

Prioriza los recursos críticos

Marca los recursos esenciales, como las imágenes hero o el CSS above-the-fold, con fetchpriority="high". Esto indica al navegador que descargue estos activos primero. Así evitas que queden atascados por scripts, widgets o elementos de terceros que no necesitan carga instantánea. Priorizar estos recursos críticos reduce el tiempo de carga del contenido que más importa a tus usuarios. La combinación de preload (para resolver el descubrimiento tardío) y fetchpriority="high" (para resolver la contención de red) es la técnica más potente para asegurar que el recurso del LCP se obtenga lo antes y más rápido posible.

<!-- Para imágenes del 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">

Reduce la contención de red

Agiliza las descargas iniciales aplazando o usando lazy loading en los activos no esenciales. Pospón la carga de cualquier imagen o vídeo que no sea visible de inmediato, así como los elementos secundarios o de fondo. Usar loading="lazy" para medios fuera de pantalla es un buen punto de partida. Aplazar aún más otros scripts y activos no esenciales liberará ancho de banda. Esto reduce cualquier competencia con tus recursos críticos y mantiene la carga y visualización del contenido principal de tu página rápidas. Nunca apliques loading="lazy" a tu imagen del LCP. Es un antipatrón crítico que arruinará tu puntuación.

4. Configura las Speculation Rules

La API de Speculation Rules permite a los navegadores hacer un prefetch o prerender de las 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 duración de carga del recurso. El prerendering renderiza la siguiente página 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 del LCP, como se muestra en este ejemplo de desglose del LCP de una página prerenderizada.

Próximos pasos: Continúa optimizando el LCP

La duración de carga del recurso es solo una de las cuatro fases del LCP. Después de optimizar el tiempo de descarga, continúa con las otras fases del LCP:

• Soluciona e identifica problemas del LCP: La metodología de diagnóstico completa para encontrar y solucionar todos los problemas del LCP usando field data y herramientas de laboratorio.
• Optimiza la imagen del LCP: Selección del formato de imagen, imágenes responsivas, preloading y errores comunes de optimización de imágenes.
• Resource Load Delay: Asegura que el navegador descubra el recurso del LCP lo antes posible. A menudo es un cuello de botella mayor que la propia duración de carga.
• Element Render Delay: Tras la descarga del recurso, asegura que el navegador pueda pintarlo de inmediato liberando el main thread.