Optimiza la imagen del Largest Contentful Paint

Optimiza la imagen de Largest Contentful Paint

Esta guía es parte del hub de Largest Contentful Paint (LCP). En la mayoría de los sitios web, el elemento LCP es una imagen. Si fallas con la imagen, tu puntuación de LCP se resiente. 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 tanto escritorio como móvil) tienen una puntuación de Largest Contentful Paint "buena". Eso significa que el 35% de las páginas vistas fallan, y eso se debe en parte a errores cometidos con las imágenes. Este artículo analiza los patrones comunes de buenas prácticas y los errores cuando las imágenes se convierten en el elemento de Largest Contentful Paint.

Aunque todos estos factores importan, si tu elemento 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 Largest Contentful Paint

Siempre lo digo: escucha y aprende, pero no te fíes de nadie. Hay demasiados 'gurús' predicando información falsa. Por eso he creado un experimento de LCP totalmente automático. En él puedes comprobar por ti mismo qué pasa cuando el elemento LCP no se carga de forma óptima. ¡Prueba mi LCP Test en GitHub o usa la demo en vivo!

Probará automáticamente múltiples escenarios de LCP y te mostrará los resultados. A continuación, analizaré estos escenarios y explicaré cómo y por qué aceleran o ralentizan el elemento de imagen LCP.

1. Controla el candidato a LCP: la estrategia de texto primero

¿La forma más rápida de mejorar tu Largest Contentful Paint basado en imágenes? No uses una imagen. Espera, ¿qué? Sí, has leído bien. Te lo explico.

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

Entonces, ¿cuál es el caso de las imágenes frente al texto? Las imágenes son importantes; hacen que tu sitio sea visualmente atractivo. Pero a Core Web Vitals no le importa qué elemento se convierta en el LCP. Cuando el elemento LCP está basado en texto, suele coincidir con el First Contentful Paint.

¿Deberías entonces cambiar a un elemento de Largest Contentful Paint basado en texto? ¡Depende! Las imágenes importan y hacen que tu sitio sea visualmente atractivo. Por tanto, no me verás defender el cambio a elementos de texto antiguos y aburridos. ¡Pero los errores ocurren! Ojalá tuviera un dólar por cada página de categoría que cae víctima del antipatrón del "LCP accidental". Esto ocurre cuando una página "olvida" añadir un texto descriptivo de la categoría por encima del pliegue. Como consecuencia, una imagen de producto con lazy loading se convierte en el LCP y retrasa los tiempos de carga varios segundos. Esto suele ocurrir cuando los diseñadores colocan un banner principal grande en la parte superior del DOM, antes de cualquier título importante, lo que no deja al navegador otra opción que seleccionar un candidato a LCP más lento.

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

Sin entrar en debates acalorados sobre cómo exprimir el último byte o la configuración ideal de WebP frente a AVIF, admitamos algo: los formatos antiguos como JPEG y PNG son más grandes y lentos que los formatos modernos como WebP o AVIF. Para ver una descripción completa de las técnicas de optimización de imágenes, consulta nuestra guía sobre optimización de imágenes.

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

Velocidad de decodificación frente a compresión

Aunque AVIF ofrece la mejor compresión (menor tamaño de archivo), sus complejos algoritmos pueden requerir más CPU para decodificarse en una imagen renderizable en comparación con WebP. Esta es una tarea vinculada a la CPU que ocurre en los hilos de rasterización 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 este beneficio, sobre todo en dispositivos móviles. Puedes diagnosticar esto en el panel Performance de Chrome DevTools buscando tareas de "Decode Image" de larga duración asociadas con tu elemento LCP. Si las ves, es una señal clara de que la velocidad de decodificación es tu cuello de botella, no solo el tiempo de descarga.

Opinión experta: el caso de JPEG XL. Una guía experta real debe abordar JPEG XL. Es un formato técnicamente sobresaliente, sobre todo por su capacidad para recomprimir sin pérdidas los JPEG existentes (una gran ventaja para sitios web heredados) y por su soporte de decodificación progresiva, algo de lo que AVIF carece. Sin embargo, su desventaja decisiva es la falta de soporte generalizado en los navegadores tras ser descartado por Chrome. Esto hace que aún no sea viable para el uso web general, pero lo posiciona como un formato a tener en cuenta para el futuro.

Uso del elemento <picture>: El elemento <picture> permite a los navegadores omitir los formatos de imagen no soportados, seleccionando el primero que puedan procesar. Aquí tienes cómo hacerlo:

<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 formato con tamaños adaptables

Para obtener el máximo rendimiento, debes combinar la selección de formato con tamaños de imagen adaptables 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 utiliza 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 más antiguo recurrirá a un JPEG de tamaño correcto como fallback.

Uso de la negociación de contenido

La negociación de contenido permite al servidor servir diferentes formatos de imagen según 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 imágenes tiene este aspecto:

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

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

3. Usa imágenes adaptables

Cuando se trata de optimizar imágenes LCP, el tamaño realmente importa. Una de las victorias más sencillas es servir 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 asegurarte de no desperdiciar píxeles, sigue estos pasos:

Imágenes adaptables:

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 (100% del ancho del viewport). Esto significa que en una pantalla de escritorio grande, el navegador descargará una imagen enorme de tu lista srcset, incluso si la imagen solo se muestra en una columna pequeña de 500px. Has proporcionado los ingredientes correctos (srcset) pero has omitido la receta (sizes), lo que desperdicia ancho de banda y ralentiza el LCP. El atributo sizes proporciona el contexto de maquetación necesario al indicarle al navegador el ancho real que tendrá la imagen en diferentes puntos de ruptura del viewport, lo que le permite tomar una decisión de descarga inteligente.

Entender los descriptores w frente a x

El atributo srcset admite dos tipos de descriptores. Para el diseño adaptable donde el tamaño de la imagen cambia con el viewport, el descriptor w (ancho) es la opción superior y necesaria. Se utiliza junto con el atributo sizes para que el navegador elija la mejor imagen según su tamaño renderizado en el diseño. El descriptor x (relación 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 la maquetación. Esto lo hace adecuado únicamente 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 LCP mide solo 600px de ancho en el viewport, asegúrate de que la imagen no sea mayor que eso. ¡Créeme, lo veo todos los días! Para comprobarlo, haz esto: haz clic derecho en la imagen y selecciona 'inspeccionar'. Se abrirán las DevTools y el HTML de la imagen aparecerá resaltado en azul. Ahí verás que el tamaño renderizado de la imagen (443 x 139px) es mucho menor que su ancho intrínseco (1090x343px). Es casi 3 veces más grande; redimensionarla habría ahorrado al menos el 50% del tamaño del archivo.

5. Usa imágenes LCP con carga anticipada

Para obtener el mejor rendimiento de tu LCP, debes cargar de forma anticipada el elemento LCP visible (y aplicar lazy loading a 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 solucionar imágenes LCP cargadas con lazy loading.

Carga anticipada: El elemento LCP (habitualmente el contenido por encima del pliegue) siempre debe cargarse de forma anticipada. Esto asegura que aparezca lo antes posible, reduciendo el tiempo que tarda en renderizarse el Largest Contentful Paint. Por defecto, las imágenes se cargan de forma anticipada a menos que se indique lo contrario. Asegúrate de no haber configurado loading="lazy" en la imagen LCP. Hacerlo puede retrasar significativamente el LCP y perjudicar tu puntuación de Core Web Vitals. Es importante entender que loading="eager" es el comportamiento predeterminado del navegador, por lo que omitir el atributo tiene el mismo efecto. Lo crucial es garantizar que loading="lazy" no esté presente.

Alerta geek: El preload scanner no pone en cola las imágenes con lazy loading. El preload scanner es un escáner HTML secundario ultrarrápido que encola los recursos importantes de inmediato. Si se omite el preload scanner, 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 loading="lazy" de forma nativa, primero debe descargar y procesar todo el CSS que sea render blocking para construir el render tree. 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 bloqueante para la descarga de la imagen LCP, lo que resulta en un desastre de rendimiento.

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

Para las imágenes por debajo del pliegue (aquellas que no son visibles en la carga inicial), usar lazy loading es el camino a seguir. Al retrasar la carga de estas imágenes hasta que el usuario hace scroll cerca de ellas, liberas ancho de banda para el contenido más importante, como el elemento LCP. En este sentido, el lazy loading es un arma de doble filo: si lo usas bien, acelerará tu LCP; si lo usas mal, lo ralentizará.

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

¿El equilibrio? Carga de forma anticipada el contenido crítico (como tu imagen LCP) y aplica lazy loading a los recursos menos críticos y a las imágenes por debajo del pliegue.

6. Precarga la imagen LCP

Precargar la imagen LCP le indica al navegador que la descargue de inmediato, antes de que la descubra de forma natural en el HTML. Para ver una guía completa sobre precarga, lee nuestro artículo específico sobre precargar la imagen LCP.

¿Por qué precargar la imagen LCP?

Cuando el navegador carga una página, procesa el HTML, las hojas de estilo y los scripts en un orden determinado. A veces, la imagen LCP se referencia más adelante en la cadena, lo que significa que el navegador la detecta más tarde de lo que debería. Precargar la imagen LCP le indica al navegador de antemano que la imagen es crítica y debe descargarse de inmediato, reduciendo el retraso en el renderizado de tu elemento más grande.

Cómo precargar la imagen LCP

Al usar la etiqueta <link rel="preload">, puedes asegurarte de que el navegador comience a descargar la imagen 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 LCP esté en la cola del navegador desde el principio, evitando la espera que suele ocurrir si la imagen está enterrada en el CSS o en scripts.

<!-- En el <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">

<!-- En el <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 LCP, ya que precargar demasiados recursos puede saturar al navegador y perjudicar el rendimiento. Céntrate en lo que más importa para tus Core Web Vitals.

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

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

La medición de LCP ocurre tras terminar la animación: El navegador considera que el LCP se ha completado solo cuando el elemento es totalmente visible. Si usas una animación de fade-in, el cronómetro sigue corriendo hasta que la imagen o el contenido se ha mostrado por completo, lo que puede sumar fácilmente segundos adicionales a tu puntuación de LCP.

Hazlo sencillo: Para garantizar que el elemento LCP aparezca lo antes posible, evita usar efectos de fade-in. Deja que la imagen cargue y se muestre de inmediato, sin ninguna transición o animación.

Evita los fade-ins en la imagen LCP. El efecto visual no compensa el coste de rendimiento.

8. Aloja el elemento LCP en tu servidor

Aloja la imagen LCP en tu propio servidor. Depender de servidores de terceros introduce retrasos que están completamente fuera de tu control, lo que puede perjudicar tu LCP y el rendimiento general de la página.

Piénsalo así: No alojar el elemento LCP en tu servidor es como pedirle azúcar constantemente a tu vecino. Cada vez tienes que ir hasta allí, esperar en la puerta y ver si está en casa. Depender de un servidor externo para tu LCP obliga a tu web a esperar por ese recurso externo, ralentizando el tiempo de carga. Alojarlo tú mismo es como tener el azúcar en tu propia cocina: rápido, directo y fiable.

Reduce dependencias externas: Cuando tu elemento LCP (como una imagen) está alojado en un servidor externo, quedas a merced de la velocidad de ese servidor, su disponibilidad y los tiempos de ida y vuelta (RTT) adicionales. Alojarlo en tu propio servidor elimina esta incertidumbre. Te permite servir la imagen directamente desde tu servidor, garantizando una entrega más rápida y fiable.

Aprovecha el almacenamiento en caché y las optimizaciones: Al alojar el contenido en tu servidor, puedes aprovechar al máximo las estrategias de caché y servir la imagen desde el servidor más cercano al usuario, especialmente si usas una CDN. Esto reduce el tiempo necesario para cargar el elemento LCP, lo que agiliza el renderizado.

Control sobre la optimización de imágenes: Alojar la imagen en tu servidor te otorga control sobre cómo se optimiza (ya sea compresión, cambio de tamaño o selección de formato) sin depender de procesamientos de terceros. Así te aseguras de que la imagen esté perfectamente adaptada para una carga rápida.

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

El renderizado del lado del cliente (CSR) es una de las peores cosas que puedes hacerle a tu LCP. Si tu elemento LCP (habitualmente una imagen grande, un bloque de texto o un vídeo) se renderiza en el lado del cliente mediante JavaScript, suele provocar tiempos de LCP más lentos. Esto se debe a que el navegador tiene que esperar a que los scripts se descarguen, analicen y ejecuen antes de mostrar el contenido crítico.

Retrasos en el renderizado: Con CSR, el elemento LCP solo se muestra después de que el navegador procese el JavaScript, lo que puede retrasar considerablemente su aparición. Cuanto más tarde, peor será tu puntuación de LCP. Cada segundo adicional dedicado a procesar scripts se traduce en una espera más larga para que los usuarios vean el contenido más importante.

Cambia a renderizado del lado del servidor (SSR) o renderizado estático: Al renderizar el elemento LCP en el servidor o como parte de una respuesta HTML estática, permites que el navegador lo cargue y muestre de inmediato, sin esperar a que JavaScript se ejecute. Esto mejora drásticamente los tiempos de LCP, ya que el navegador puede renderizar el elemento LCP directamente al comenzar 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 LCP. Usa defer o async en los scripts no críticos para evitar que retrasen la aparición de tu LCP.

10. Reserva espacio para evitar desplazamientos de diseño

Incluye siempre atributos width y height explícitos en tus etiquetas <img>. Esta es una instrucción crítica para el navegador, ya que le permite calcular la relación de aspecto de la imagen y reservar el espacio correcto en el diseño antes de que esta se descargue.

Opinión experta: comportamiento moderno de width y height

Una idea errónea muy común es que estos atributos hacen que la imagen no sea adaptable. Esto ya no es así en los navegadores modernos. El navegador utiliza estos atributos HTML para calcular la relación de aspecto y reservar el espacio, pero la imagen seguirá siendo perfectamente adaptable si su CSS se define como width: 100%; height: auto;. Proporcionar estos atributos es mejor que usar únicamente la propiedad CSS aspect-ratio, ya que el navegador puede reservar el espacio antes de descargar y procesar el CSS que bloquea el renderizado (render blocking), lo que le da una ventaja inicial crítica.

Manejo de imágenes de fondo en CSS

Este principio también se aplica a los elementos que actúan como contenedores de una background-image de CSS. Una causa común de desplazamiento de diseño es un <div> que al principio colapsa a altura cero y luego se expande cuando se aplica la imagen de fondo. Para evitar esto, usa la propiedad CSS aspect-ratio directamente en el contenedor para reservar el espacio necesario desde el principio.

11. Audita el bloqueo del main thread

Incluso si tu imagen LCP está perfectamente optimizada y priorizada, su renderizado final puede retrasarse si el main thread del navegador está ocupado ejecutando JavaScript pesado. Con frecuencia, el origen de este bloqueo son los scripts de terceros para analítica, anuncios o widgets de soporte al cliente. Estos scripts pueden monopolizar la CPU, lo que aumenta el retraso de renderizado del elemento. Usa el panel Performance de Chrome DevTools para identificar tareas de larga duración durante la carga inicial, atribúyelas a su origen y pospón o elimina cualquiera que no sea crítica para el renderizado inicial. Para profundizar en esto, consulta nuestra guía sobre el retraso de renderizado del elemento.

Guías relacionadas de optimización de LCP

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

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