Optimiza la imagen del Largest Contentful Paint

Optimiza la imagen del Largest Contentful Paint

Esta guía es parte de la sección principal del Largest Contentful Paint (LCP). En la mayoría de los sitios web, el elemento del LCP es una imagen. Si fallas con la imagen, la puntuación de tu LCP sufre. Este artículo cubre todas las técnicas para hacerla rápida.

Según Google, solo el 65% de todas las páginas vistas en internet (incluyendo escritorio y móvil) tienen una puntuación 'buena' del Largest Contentful Paint. Esto significa que el 35% de las páginas vistas suspenden, en parte por errores cometidos con las imágenes. Este artículo analiza los patrones de buenas prácticas comunes y los errores cuando las imágenes se convierten en el elemento del Largest Contentful Paint.

Aunque todos estos factores importan, si el elemento de tu LCP es una imagen (¡y suele serlo!), hay pasos sencillos que puedes seguir para asegurar que cargue lo más rápido posible.

Experimentos con el Largest Contentful Paint

Siempre digo: escucha y aprende, pero no te fíes de la palabra de nadie. Hay demasiados 'gurús' predicando información equivocada. Por eso he creado un experimento del LCP totalmente automático donde puedes comprobar por ti mismo qué ocurre cuando el elemento del LCP no se carga de manera óptima. ¡Revisa mi prueba del LCP en github o prueba la demo en vivo!

Probará automáticamente múltiples escenarios del LCP por ti y te mostrará los resultados. Abajo analizaré esos escenarios y explicaré cómo y por qué aceleran o ralentizan el elemento de imagen del LCP.

1. Controla el candidato del LCP: la estrategia del texto primero

¿La forma más rápida de mejorar un Largest Contentful Paint basado en imágenes? ¡No uses una imagen! Espera, ¿qué? Sí, me has oído bien. Déjame explicarlo.

Por qué el texto es más rápido que una imagen. La diferencia de rendimiento se reduce al pipeline de peticiones. Un nodo de texto (como un <h1> o <p>) es parte del documento HTML principal. No tiene petición de recurso separada; su renderizado solo está bloqueado por el CSS. Una imagen, en cambio, es un recurso externo que requiere su propia petición HTTP. Esto introduce latencia de red (DNS, TCP, TLS y tiempo de descarga) además del bloqueo del CSS. Esta distinción es la razón principal de la diferencia de rendimiento y el motivo por el cual controlar el candidato del LCP es una estrategia poderosa y de nivel experto.

Entonces, ¿cuál es el argumento para las imágenes frente al texto? Las imágenes son importantes; hacen tu sitio visualmente atractivo. Pero a las Core Web Vitals les da igual qué elemento se convierte en el LCP. Cuando el elemento del LCP está basado en texto, normalmente ocurre al mismo tiempo que el First Contentful Paint.

¿Deberías cambiar a un elemento del Largest Contentful Paint basado en texto? ¡Depende! Las imágenes importan y hacen tu sitio visualmente atractivo. Eso significa que no me oirás defender el cambio a los viejos y aburridos elementos de texto. ¡Pero también ocurren errores! Ojalá tuviera un dólar por cada página de categoría que cae víctima del antipatrón del "LCP accidental". Esto sucede cuando una página "olvida" añadir un texto descriptivo de categoría en el viewport inicial, provocando que una imagen de producto con lazy loading se convierta en el LCP y retrasando los tiempos de carga durante segundos. Esto a menudo ocurre cuando los diseñadores colocan un hero banner grande en la parte superior del DOM, antes de cualquier titular importante, dejando al navegador sin otra opción que seleccionar un candidato del LCP más lento.

2. Usa el formato de imagen más rápido disponible

Sin entrar en un debate acalorado sobre exprimir hasta el último byte o la configuración perfecta para WebP contra AVIF, estemos de acuerdo en algo: los formatos antiguos como JPEG y PNG son más grandes y lentos en comparación con los formatos modernos como WebP o AVIF. Para un resumen completo de las técnicas de optimización de imágenes, consulta nuestra guía de optimización de imágenes.

Como regla general, debes servir una versión con pérdida en WebP o AVIF de la imagen de tu LCP (mejor aún, usa estos formatos para todas tus imágenes, pero aquí nos centramos en el LCP). Con el soporte para WebP en torno al 95% y el soporte para AVIF en un 92%, todavía tiene sentido servir imágenes antiguas como fallback. Para ello, usa la 'mejora progresiva' donde servimos estos formatos modernos solo a los navegadores que los soportan.

El compromiso entre velocidad de decodificación y compresión

Aunque el AVIF ofrece la mejor compresión (tamaño de archivo más pequeño), sus complejos algoritmos pueden requerir más potencia de CPU para decodificarse en una imagen renderizable en comparación con el WebP. Esta es una tarea dependiente de la CPU que ocurre en los hilos del rasterizador del navegador y aumenta directamente el retraso de renderizado del elemento. Un AVIF más pequeño puede descargarse más rápido, pero su mayor tiempo de decodificación podría anular ese beneficio, especialmente en dispositivos móviles. Puedes diagnosticar esto en el panel de rendimiento de Chrome DevTools buscando tareas largas de "Decode Image" asociadas con el elemento de tu LCP. Si ves esto, es una señal clara de que la velocidad de decodificación es tu cuello de botella, no solo el tiempo de descarga.

Visión de experto: el caso del JPEG-XL. Una verdadera guía experta debe mencionar el JPEG XL. Es un formato técnicamente notable, sobre todo por su capacidad para recomprimir los JPEG existentes sin pérdida (una gran victoria para los sitios antiguos) y su soporte para la decodificación progresiva, algo de lo que carece el AVIF. Sin embargo, su desventaja decisiva es la falta de soporte amplio en los navegadores después de ser descartado por Chrome. Esto hace que aún no sea viable para el uso general en la web, pero lo posiciona como algo a vigilar en el futuro.

Uso del elemento <picture>: El elemento <picture> permite a los navegadores saltarse los formatos de imagen no soportados, seleccionando el primero que pueden procesar. Así es como se hace:

<picture>
<source srcset="img.avif" type="image/avif">
<source srcset="img.webp" type="image/webp">
<img src="img.jpg" alt="Image" width="123" height="123">
</picture>

Combinar la negociación de formatos con tamaños responsivos

Para conseguir el máximo rendimiento, debes combinar la selección de formato con los tamaños de imagen responsivos en un único elemento <picture>. Esto asegura que cada usuario reciba el formato óptimo y el tamaño óptimo para su dispositivo. El navegador evalúa los elementos <source> de arriba a abajo y selecciona el primer formato que soporta, luego usa los atributos srcset y sizes para elegir la resolución correcta.

<picture>
  <source
    type="image/avif"
    srcset="hero-400w.avif 400w, hero-800w.avif 800w, hero-1200w.avif 1200w"
    sizes="(max-width: 600px) 100vw, (max-width: 1200px) 800px, 1200px">
  <source
    type="image/webp"
    srcset="hero-400w.webp 400w, hero-800w.webp 800w, hero-1200w.webp 1200w"
    sizes="(max-width: 600px) 100vw, (max-width: 1200px) 800px, 1200px">
  <img
    src="hero-800w.jpg"
    srcset="hero-400w.jpg 400w, hero-800w.jpg 800w, hero-1200w.jpg 1200w"
    sizes="(max-width: 600px) 100vw, (max-width: 1200px) 800px, 1200px"
    alt="Descriptive alt text for hero image"
    width="1200" height="675"
    fetchpriority="high">
</picture>

Este patrón le da al navegador total libertad para elegir la mejor combinación de formato y resolución. Un usuario móvil en un navegador compatible obtendrá un archivo AVIF pequeño, mientras que un navegador de escritorio antiguo utilizará como fallback un JPEG con el tamaño correcto.

El uso de la negociación de contenido

La negociación de contenido permite a tu servidor entregar diferentes formatos de imagen basándose en el soporte del navegador. Los navegadores anuncian los formatos soportados a través de la cabecera Accept. Por ejemplo, en Chrome, la cabecera Accept para las imágenes se ve así:

Accept: image/avif,image/webp,image/apng,image/*,*/*;q=0.8

Luego, del lado del servidor, lee la cabecera Accept y basándote en ella, sirve el 'mejor formato'.

3. Usa imágenes responsivas

Cuando se trata de optimizar las imágenes del LCP, el tamaño realmente importa. Una de las victorias más fáciles es servir las imágenes con las dimensiones más pequeñas posibles que sigan viéndose bien en las pantallas de tus usuarios. Las imágenes grandes no sirven para nada: desperdician ancho de banda y ralentizan los tiempos de carga, especialmente para usuarios con conexiones lentas o dispositivos móviles.

Para asegurar que no estás desperdiciando píxeles, sigue estos pasos:

Imágenes responsivas:

Usa el atributo srcset para servir diferentes tamaños de imagen según el dispositivo del usuario. De esta forma, los dispositivos más pequeños reciben imágenes más pequeñas, lo que ayuda a acelerar el LCP.

Por qué el atributo sizes es crítico

Usar srcset con descriptores w pero omitir el atributo sizes es un error común y costoso. Sin el atributo sizes, el navegador se ve obligado a asumir un valor por defecto de 100vw (el 100% del ancho del viewport). Esto significa que en una pantalla grande de escritorio, el navegador descargará una imagen masiva de tu lista srcset, incluso si la imagen solo se muestra en una pequeña columna de 500px. Has proporcionado los ingredientes correctos (srcset) pero has olvidado la receta (sizes), lo que provoca un desperdicio de ancho de banda y un LCP más lento. El atributo sizes proporciona el contexto de diseño necesario, diciéndole al navegador lo ancha que será realmente la imagen en los diferentes breakpoints del viewport, permitiéndole hacer una elección de descarga inteligente.

Entendiendo los descriptores w frente a x

El atributo srcset soporta dos tipos de descriptores. Para el diseño responsivo donde el tamaño de una imagen cambia con el viewport, el descriptor w (ancho) es la opción superior y necesaria. Se utiliza con el atributo sizes para permitir que el navegador elija la mejor imagen en función de su tamaño renderizado en el layout. El descriptor x (ratio de píxeles del dispositivo), más simple, solo considera la densidad de píxeles de la pantalla, ignorando el tamaño real de la imagen en el diseño, lo que lo hace adecuado solo para imágenes de tamaño fijo como los iconos.

<img
  src="img.jpg"
  srcset="img-400px.jpg 400w, img-800px.jpg 800w, img-1200px.jpg 1200w"
  sizes="(max-width: 600px) 400px, (max-width: 1200px) 800px, 1200px"
  alt="Image" width="123" height="123">

4. ¡Escala tus imágenes al tamaño de la pantalla!

Evita servir imágenes más grandes de lo necesario. Si el elemento del LCP solo tiene 600px de ancho en el viewport, asegúrate de que la imagen no sea más grande que eso. Créeme, ¡veo que esto pasa todos los días! Para comprobarlo, solo haz esto: inspecciona la imagen haciendo clic derecho en ella y selecciona 'inspeccionar elemento'. Verás las dev-tools y el HTML de la imagen resaltado con un fondo azul. Ahora puedes ver que el tamaño renderizado de la imagen (443 x 139px) es mucho menor que el ancho intrínseco de la imagen (1090x343px). Eso es casi 3 veces más grande, y redimensionar la imagen podría haber ahorrado al menos el 50% del tamaño del archivo.

5. Imágenes del LCP con carga inmediata

Para obtener el mejor rendimiento de tu LCP, debes cargar inmediatamente el elemento del LCP visible (y usar lazy loading en las imágenes que no son visibles de inmediato). Este es uno de los errores más comunes en la optimización del LCP, y lo cubrimos en detalle en nuestro artículo sobre cómo corregir imágenes del LCP con lazy loading.

Carga inmediata: el elemento del LCP (normalmente el contenido en el viewport inicial) siempre debe cargarse inmediatamente. Esto asegura que aparezca lo más rápido posible, reduciendo el tiempo que tarda en renderizarse tu Largest Contentful Paint. Por defecto, las imágenes se cargan de forma inmediata a menos que se especifique lo contrario, pero revisa bien que no hayas puesto loading="lazy" en la imagen del LCP. Hacerlo puede retrasar significativamente el LCP y dañar tu puntuación de las Core Web Vitals. Es importante entender que loading="eager" es el comportamiento por defecto del navegador, por lo que omitir el atributo por completo tiene el mismo efecto. La acción crítica es asegurar que loading="lazy" no esté presente.

Alerta geek: El escáner de precarga no encola las imágenes con lazy loading. El escáner de precarga es un escáner secundario de HTML superrápido que encola los recursos importantes de inmediato. Cuando se esquiva al escáner de precarga, el navegador tendrá que esperar a que el motor de renderizado termine antes de encolar las 'imágenes visibles'. Para que el navegador evalúe el loading="lazy" nativo, primero debe descargar y parsear todo el CSS render blocking para construir el árbol de renderizado. Solo después de calcular el layout puede el navegador determinar si la imagen está en el viewport. Esto significa que todo tu CSS se convierte en una dependencia de bloqueo para la descarga de la imagen del LCP, lo cual es un desastre de rendimiento.

<img src="lcp-image.jpg" alt="Main image" width="800" height="400">

Para las imágenes que aparecen fuera del viewport (las que no se ven cuando la página carga al principio), el lazy loading es el camino a seguir. Al retrasar la carga de estas imágenes hasta que el usuario se desplaza cerca de ellas, liberas ancho de banda para contenido más importante, como el elemento de tu LCP. De esta forma, el lazy loading es un arma de doble filo: si se usa correctamente acelerará el contenido de tu LCP; ¡si se usa mal lo ralentizará!

<img src="non-visible-image.jpg"
     alt="Secondary image"
     
     width="800" height="400">

¿El equilibrio? ¡Carga inmediatamente el contenido crítico (como la imagen de tu LCP) y usa el lazy loading para los recursos menos críticos y las imágenes fuera del viewport!

6. Precarga la imagen del LCP

Precargar la imagen del LCP le dice al navegador que la recupere inmediatamente, antes de que la descubra de forma natural en el HTML. Para una guía completa sobre la precarga, consulta nuestro artículo dedicado a la precarga de la imagen del LCP.

¿Por qué precargar la imagen del LCP?

Cuando el navegador carga una página, procesa el HTML, las hojas de estilo y los scripts en un cierto orden. A veces, la imagen del LCP se referencia más abajo en la cadena, lo que significa que el navegador llega a ella más tarde de lo que debería. Precargar la imagen del LCP hace saber al navegador de antemano que esta imagen es crítica y debe cargarse de inmediato, reduciendo el retraso en el renderizado de tu elemento más grande.

Cómo precargar la imagen del LCP

Usando la etiqueta <link rel="preload">, puedes asegurarte de que el navegador comience a descargar la imagen del LCP lo antes posible en el proceso de carga.

<link rel="preload" href="lcp-image.jpg" as="image" type="image/jpeg">

Esto asegura que la imagen del LCP esté en la cola del navegador desde el principio, evitando la espera que ocurre a menudo si la imagen está enterrada en el CSS o en los scripts.

<!-- In the <head> -->
<link rel="preload" as="image"
      href="lcp-image-800w.jpg"
      imagesrcset="lcp-image-400w.jpg 400w, lcp-image-800w.jpg 800w"
      imagesizes="(max-width: 600px) 400px, 800px">

<!-- In the <body> -->
<img src="lcp-image-800w.jpg"
     srcset="lcp-image-400w.jpg 400w, lcp-image-800w.jpg 800w"
     sizes="(max-width: 600px) 400px, 800px"
     alt="..." width="800" height="450" fetchpriority="high">

Recuerda: Solo precarga la imagen del LCP, ya que precargar demasiados recursos puede saturar el navegador y dañar el rendimiento. Cíñete a lo que más importa para tus Core Web Vitals.

7. Elimina las animaciones de fade-in de la imagen del LCP

Las animaciones de fade-in pueden ser visualmente atractivas, pero son un cuello de botella oculto para el LCP. Si el elemento del LCP (a menudo una imagen) usa un efecto de fade-in, el navegador no contará el LCP hasta que la animación termine. Esto retrasa el tiempo del LCP y puede dañar significativamente tus métricas de rendimiento.

El tiempo del LCP ocurre después de que termina la animación: El navegador considera que el LCP está completo solo cuando el elemento es totalmente visible. Si tienes una animación de fade-in, el cronómetro sigue corriendo hasta que la imagen o el contenido haya aparecido por completo, lo que puede añadir fácilmente segundos extra a tu puntuación del LCP.

Mantenlo simple: Para asegurar que el elemento del LCP aparezca lo más rápido posible, evita usar efectos de fade-in. Deja que la imagen cargue y se muestre inmediatamente, sin ninguna transición ni animación.

Sáltate los fade-ins en la imagen del LCP. El efecto visual no compensa el coste de rendimiento.

8. Autoaloja el elemento del LCP

Autoaloja la imagen de tu LCP. Depender de servidores de terceros introduce retrasos que están totalmente fuera de tu control, lo que puede perjudicar a tu LCP y al rendimiento general de la página.

Piénsalo así: No autoalojar el elemento de tu LCP es como pedir azúcar a tu vecino constantemente. Cada vez, tienes que caminar hasta allí, esperar en la puerta y esperar que estén en casa. Depender de un servidor de terceros para tu LCP hace que tu sitio web espere a ese recurso externo, ralentizando los tiempos de carga. Autoalojar es como guardar el azúcar en tu cocina: rápido, directo y fiable.

Reduce las dependencias externas: Cuando el elemento de tu LCP (como una imagen) está alojado en un servidor de terceros, estás a merced de la velocidad de ese servidor, de su disponibilidad y de cualquier tiempo extra de ida y vuelta (RTT). Autoalojar elimina esta incertidumbre, permitiéndote servir la imagen directamente desde tu propio servidor, asegurando una entrega más rápida y fiable.

Usa la caché y las optimizaciones: Al autoalojar, puedes aprovechar al máximo las estrategias de caché y servir la imagen desde el servidor más cercano al usuario, especialmente si estás usando una CDN. Esto reduce el tiempo que tarda en cargar el elemento del LCP, dando como resultado un renderizado más rápido.

Control sobre la optimización de la imagen: Autoalojar te da control sobre cómo se optimiza la imagen, ya sea en la compresión, el redimensionamiento o la selección de formato, sin depender del manejo de terceros. De esta manera, puedes asegurar que la imagen esté perfectamente adaptada para una carga rápida.

9. Evita el renderizado del lado del cliente para el elemento del LCP

El renderizado del lado del cliente (CSR) es una de las peores cosas que puedes hacerle a tu LCP. Si el elemento de tu LCP (normalmente una imagen grande, un bloque de texto o un video) se renderiza en el lado del cliente mediante JavaScript, a menudo conduce a tiempos de LCP más lentos, ya que el navegador tiene que esperar a que los scripts se descarguen, se analicen y se ejecuten antes de mostrar el contenido crítico.

Retrasos en el renderizado: Con CSR, el elemento del LCP solo se muestra después de que el navegador procesa el JavaScript, lo que puede retrasar significativamente su aparición. Cuanto más tarde esto, peor será la puntuación de tu LCP. Cada segundo extra empleado en procesar scripts se traduce en una espera más larga para que tus usuarios vean el contenido más importante.

Cambia al renderizado del lado del servidor (SSR) o al renderizado estático: Al renderizar el elemento del LCP del lado del servidor o como parte de una respuesta HTML estática, permites que el navegador lo cargue y lo muestre inmediatamente, sin esperar a que entre en acción el JavaScript. Esto mejora drásticamente el tiempo del LCP, ya que el navegador puede renderizar el elemento del LCP enseguida cuando comienza a cargar el HTML.

Minimiza el JavaScript en la ruta crítica: Si no puedes evitar algunos scripts del lado del cliente, asegúrate de que no bloqueen el renderizado del elemento del LCP. Aplaza (defer) o carga asíncronamente (async) los scripts no críticos para evitar que retrasen la aparición de tu LCP.

10. Reserva espacio para prevenir los Layout Shifts

Incluye siempre atributos width y height explícitos en tus etiquetas <img>. Esta es una instrucción crítica para el navegador, que le permite calcular el ratio de aspecto de la imagen y reservar la cantidad correcta de espacio en el layout antes de que la imagen se haya descargado.

Visión de experto: comportamiento moderno de width y height

Un error común es pensar que estos atributos hacen que una imagen no sea responsiva. Esto ya no es cierto en los navegadores modernos. El navegador usa estos atributos HTML para calcular un ratio de aspecto y reservar el espacio, pero la imagen seguirá siendo perfectamente responsiva si su CSS está configurado en width: 100%; height: auto;. Proporcionar estos atributos es superior a usar solo la propiedad CSS aspect-ratio, ya que el navegador puede reservar el espacio antes de que se haya descargado y analizado cualquier CSS render blocking, dándole una ventaja crítica.

Manejo de imágenes de fondo CSS

Este principio también se aplica a los elementos que sirven como contenedores para una background-image en CSS. Una fuente común de Layout Shift es un <div> que colapsa a una altura cero inicialmente y luego aumenta de tamaño cuando se aplica la imagen de fondo. Para evitar esto, usa la propiedad CSS aspect-ratio directamente en el elemento contenedor para reservar el espacio necesario desde el principio.

11. Audita el bloqueo del main thread

Incluso si la imagen de tu LCP está perfectamente optimizada y priorizada, su renderizado final puede retrasarse si el main thread del navegador está ocupado ejecutando JavaScript pesado. A menudo, la fuente de este bloqueo son los scripts de terceros para analíticas, anuncios o widgets de soporte al cliente. Estos scripts pueden monopolizar la CPU, aumentando el retraso de renderizado del elemento. Usa el panel de Performance en Chrome DevTools para identificar los long tasks durante la carga inicial, atribuirlos a su fuente y aplazar o eliminar los que no sean críticos para el renderizado inicial. Para más información sobre este tema, consulta nuestra guía sobre el retraso de renderizado del elemento.

Guía paso a paso: Diagnosticar el LCP con el panel de rendimiento de Chrome DevTools muestra cómo registrar un rastro limitado y detectar estos long tasks en la pista Main.

Guías de optimización del LCP relacionadas

La optimización de imágenes es una pieza del rompecabezas. Cada fase del LCP tiene su propia guía:

• Corrige e identifica los problemas del LCP: La metodología de diagnóstico completa para encontrar y corregir problemas del LCP usando field data y herramientas de laboratorio.
• Retraso de carga del recurso: Asegura que el navegador descubra tu recurso del LCP lo antes posible con la precarga, fetchpriority y una estructura HTML óptima.
• Duración de carga del recurso: Reduce el tiempo de descarga mediante la compresión, la configuración de la CDN y la optimización de la red.
• Retraso de renderizado del elemento: Libera el main thread para que el navegador pueda pintar el elemento del LCP inmediatamente después de la descarga.