Optimiza la duración de carga del recurso LCP

Esta guía forma 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 de LCP y mide el tiempo que tarda en descargarse el recurso LCP a través de la red. Aunque el retraso en la carga del recurso suele representar una mayor proporción del tiempo de LCP, optimizar la duración de descarga sigue siendo esencial para lograr una buena puntuación de LCP.

Optimiza la duración de carga del recurso LCP

Largest Contentful Paint (LCP) es una de las tres métricas de rendimiento de Core Web Vitals que miden la experiencia del usuario en línea. El LCP captura el tiempo que tarda el elemento de contenido más grande (una imagen, video o bloque de texto) en hacerse visible en el viewport. La duración de carga del recurso es una sub-parte del LCP que indica cuánto tiempo se dedica a obtener el recurso de red del elemento LCP. Profundicemos en el aspecto de la duración de carga del recurso del LCP y exploremos su impacto y estrategias de optimización.

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

La duración de carga del recurso, a menudo llamada duración de carga, 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 elementos LCP basados en texto, la duración de carga es típicamente cero.

La duración de carga del recurso se mide desde el momento en que el navegador comienza a descargar el recurso LCP hasta que ha terminado de descargarlo. Esta medición es importante porque impacta directamente en la rapidez con la que los usuarios pueden ver e interactuar con el contenido principal de una página web. La duración de carga del recurso puede verse influenciada por varios factores, entre ellos:

• Tamaño del archivo: Los archivos más grandes requieren tiempos de descarga más largos.
• Velocidad de red: Las conexiones más lentas naturalmente extienden la duración de carga.
• Capacidad de respuesta del servidor: Los retrasos en la respuesta del servidor ralentizan la obtención de recursos.
• Descargas simultáneas: Los recursos descargados simultáneamente compiten por el ancho de banda, lo que 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 herramientas de desarrollo de Chrome, luego selecciona la pestaña "Network" y recarga la página. Busca el elemento LCP en las solicitudes de red (si quieres conocer el elemento LCP, prueba el Core Web Visualizer). El inspector de red te mostrará cuánto tiempo tardó en descargarse el recurso.

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

Aprovecha los datos de Real User Monitoring (RUM):

Las herramientas de RUM a menudo registran datos de atribución de LCP. Los datos de atribución del Largest Contentful Paint contienen información sobre la duración de carga del recurso. Estos datos permiten visualizaciones de las tendencias de duración de carga a lo largo del tiempo o por página, proporcionando una vista clara de los tiempos de carga en todo el sitio. Al analizar estos patrones, es posible identificar elementos que pueden ralentizar los tiempos de carga y descubrir oportunidades específicas para un rendimiento más rápido y fluido.

Cómo mejorar la duración de carga de 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 datos. Aquí tienes técnicas y patrones efectivos para mejorar la duración de carga del recurso LCP:

1. Optimiza el tamaño del archivo

Optimizar el tamaño del archivo reduce el número de bytes que se envían a través de la red. Menos datos generalmente significan menos tiempo de descarga. Para una guía completa sobre optimización de imágenes, consulta nuestro artículo sobre cómo optimizar imágenes.

Usa formatos de imagen modernos

AVIF y WebP lideran en compresión. AVIF, en particular, ofrece amplias capacidades de compresión, a menudo reduciendo el tamaño de los archivos hasta un 50% en comparación con WebP, lo que lo hace ideal para fotos complejas sin sacrificar calidad. WebP, sin embargo, mantiene una fuerte compatibilidad con una gama más amplia de navegadores y es especialmente efectivo para imágenes más simples.

Elegir el ajuste de calidad correcto

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, producirá imágenes que son visualmente indistinguibles del original a distancias de visualización normales, logrando al mismo tiempo un ahorro sustancial en el tamaño del archivo. Siempre prueba con tus imágenes específicas, ya que la calidad óptima depende del tipo de contenido (fotografías vs. ilustraciones vs. imágenes con mucho texto).

Automatización de la compresión de imágenes con Sharp

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

const sharp = require('sharp');

// Convert to WebP with optimized quality
await sharp('input.jpg')
  .resize(1200)  // Resize to maximum needed width
  .webp({ quality: 80, effort: 6 })
  .toFile('output.webp');

// Convert to AVIF with optimized quality
await sharp('input.jpg')
  .resize(1200)
  .avif({ quality: 65, effort: 6 })
  .toFile('output.avif');

// Generate multiple sizes for responsive images
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 necesitas para un elemento <picture> responsive con soporte de formatos modernos. Para sitios WordPress, plugins como ShortPixel o Imagify manejan esta conversión automáticamente al subir imágenes.

Imágenes responsive

El elemento <picture> y el atributo srcset permiten imágenes adaptadas según el tamaño de pantalla, permitiendo versiones de imagen más pequeñas para dispositivos móviles y versiones de alta resolución para pantallas más 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 de imagen correctas

Las imágenes responsive son solo parte de la solución porque responsive no significa que estén correctamente dimensionadas. Hacer coincidir las dimensiones de la imagen con 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 fuente se convierte en el recurso LCP. Optimiza la duración de carga de la fuente mediante:

• Usa el formato WOFF2: WOFF2 proporciona la mejor compresión para fuentes web, típicamente un 30% más pequeño que WOFF y significativamente más pequeño que archivos TTF u OTF.
• Haz un subconjunto de tus fuentes: Si tu sitio solo usa caracteres latinos, haz un subconjunto de la fuente para eliminar conjuntos de caracteres no utilizados (cirílico, griego, CJK). Herramientas como glyphhanger o pyftsubset pueden automatizar esto, a menudo reduciendo el tamaño del archivo de fuente en un 50% o más.
• Limita las variaciones de fuente: Cada peso y estilo (regular, negrita, cursiva) es una descarga de archivo separada. Solo incluye los pesos que tu diseño realmente utiliza.

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. Esto se puede lograr mediante:

Evita la 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 tienen la opción de servir contenido estático (que no cambia) como imágenes, scripts y hojas de estilo directamente desde la caché local del navegador. Configura el servidor para enviar instrucciones de almacenamiento en caché correctas al navegador.

La configuración más efectiva es enviar un encabezado Cache-Control como este:

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 en 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, usa nombres de archivo con hash de contenido (por ejemplo, hero-abc123.webp) de modo que cuando la imagen cambie, el nombre del archivo también cambie, invalidando la caché automáticamente.

Compresión Brotli vs. Gzip

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

La configuración ideal es pre-comprimir los activos estáticos con Brotli a un nivel de compresión alto (por ejemplo, nivel 11) durante el proceso de compilación, y usar Gzip como fallback para clientes que no soporten Brotli. La mayoría de los CDN, incluyendo Cloudflare, manejan esto automáticamente. Para más detalles sobre la configuración de CDN, consulta nuestra guía sobre cómo configurar Cloudflare para un rendimiento óptimo.

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

El protocolo utilizado para entregar recursos tiene un impacto significativo en la duración de carga, especialmente cuando se descargan múltiples recursos de forma concurrente.

• HTTP/2 introdujo la multiplexación, permitiendo que múltiples solicitudes y respuestas se envíen 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 todos los demás. HTTP/2 también soporta compresión de encabezados (HPACK) y server push.
• HTTP/3 va más allá al reemplazar TCP con QUIC, un protocolo basado en UDP. HTTP/3 elimina el bloqueo de cabeza de línea a nivel TCP (donde un solo paquete perdido paraliza todos los flujos), proporciona un establecimiento de conexión más rápido a través de 0-RTT (reanudación con cero viajes de ida y vuelta para visitantes recurrentes) y maneja la pérdida de paquetes de forma más eficiente. Estos beneficios son especialmente impactantes para el Time to First Byte pero también reducen la duración general de carga de recursos.

Para verificar si HTTP/3 está habilitado, simplemente inspecciona tu red con el atajo Ctrl+Shift+I. Selecciona la pestaña de red, haz clic derecho en los encabezados de columna de la red y asegúrate de que 'protocol' esté habilitado. Recarga la página y verifica el protocolo. Para HTTP/3, el protocolo debería mostrar 'h3'.

Redes de distribución 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 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 sobre la marcha. Por ejemplo, Cloudflare Polish, Imgix y Cloudinary pueden servir WebP o AVIF automáticamente según el encabezado Accept del navegador.
• Caché en el borde: Los recursos estáticos se almacenan en caché en nodos de borde en todo el mundo, eliminando la necesidad de obtenerlos del servidor de origen.
• Optimización de protocolo: Los CDN típicamente habilitan HTTP/2 y HTTP/3 por defecto, junto con compresión Brotli, sin requerir cambios de configuración del lado del servidor.
• Reutilización de conexión: 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 CDN de imágenes especializados pueden ir más allá proporcionando optimizaciones automáticas en tiempo real como conversión de formato, redimensionamiento y compresión.

Alojamiento propio de recursos

Los recursos de red importantes y tempranos deberían por defecto siempre alojarse en el servidor de origen. El alojamiento propio 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 alojamiento propio asegura la reutilización de una única conexión ya abierta y reduce la sobrecarga de establecer conexiones separadas. Los recursos autoalojados también permiten un control total sobre las políticas de compresión y caché.

3. Optimiza la priorización de recursos

Después de reducir el tamaño de los recursos y optimizar la red, también está el problema de la competencia de red. Cuando se solicitan múltiples recursos al mismo tiempo bajo condiciones de red deficientes, esto puede ralentizar considerablemente el tiempo de descarga de recursos. Por eso tiene sentido minimizar la competencia de red 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 le indica al navegador que descargue estos activos primero, evitando que se vean atrasados 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 poderosa para asegurar que el recurso LCP se obtenga lo más temprano y rápido posible.

<!-- For LCP images visible in the initial HTML -->
<img src="hero-image.webp" fetchpriority="high" alt="...">

<!-- To improve discovery  -->
<link rel="preload" href="hero-image.webp" as="image" fetchpriority="high">

Reduce la contención de red

Optimiza las descargas iniciales aplazando o cargando de forma diferida los activos no esenciales. Pospón la carga de imágenes o videos que no sean inmediatamente visibles, así como elementos secundarios o de fondo. Usar loading="lazy" para contenido multimedia fuera de pantalla es un buen punto de partida, mientras que aplazar aún más otros scripts y activos no esenciales liberará ancho de banda y reducirá cualquier competencia con tus recursos críticos, manteniendo el contenido principal de tu página rápido de cargar y mostrar. Nunca apliques loading="lazy" a tu imagen LCP; este es un antipatrón crítico que perjudicará tu puntuación.

4. Configura Speculation Rules

Speculation Rules permite a los navegadores hacer prefetch o prerender de páginas web basándose en la navegación prevista del usuario. El prefetching elimina efectivamente la sub-parte de 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 del elemento LCP como se muestra en este ejemplo de desglose de LCP de una página pre-renderizada.

Próximos pasos: continúa optimizando LCP

La duración de carga del recurso es solo una de las cuatro fases de LCP. Después de optimizar el tiempo de descarga, explora estas guías relacionadas:

• Soluciona e identifica problemas de LCP: La metodología de diagnóstico completa para encontrar y solucionar todos los problemas de LCP usando datos de campo y herramientas de laboratorio.
• Optimiza la imagen LCP: Selección de formato de imagen, imágenes responsive, preloading y errores comunes de optimización de imágenes.
• Retraso en la carga del recurso: Asegura que el navegador descubra el recurso LCP lo antes posible. Este suele ser un cuello de botella mayor que la propia duración de carga.
• Retraso en el renderizado del elemento: Después de que el recurso se descargue, asegura que el navegador pueda pintarlo inmediatamente liberando el hilo principal.