Optimizar la imagen del Largest Contentful Paint

Optimizar la imagen del Largest Contentful Paint

Esta guía es parte de la sección Largest Contentful Paint (LCP) de nuestro centro de recursos de Core Web Vitals. El LCP mide el tiempo de renderizado del elemento visible más grande, y las imágenes son el tipo de elemento LCP más común. Este artículo cubre todas las técnicas para asegurar que su imagen LCP se cargue y renderice lo más rápido posible.

Según Google, solo el 65% de todas las visitas a páginas en internet (y eso incluye tanto escritorio como móvil) tienen una puntuación de Largest Contentful Paint 'buena'. Eso significa que el 35% de las visitas están fallando, y esto se debe en parte a errores cometidos con las imágenes. Este artículo desglosa los patrones comunes de buenas prácticas y los errores cuando las imágenes se convierten en el elemento Largest Contentful Paint.

Si bien todos estos factores importan, si su elemento LCP es una imagen (¡y frecuentemente lo es!), ¡hay pasos simples que puede seguir para asegurarse de que se cargue lo más rápido posible!

Experimentos con el Largest Contentful Paint

Siempre digo: escuche y aprenda, pero no confíe ciegamente en la palabra de nadie. Hay demasiados 'gurús' predicando información incorrecta. Es por eso que he creado un experimento LCP completamente automático donde puede comprobar por sí mismo qué sucede cuando el elemento LCP no se carga de manera óptima. ¡Consulte mi LCP Test en github o pruebe la demostración en vivo!

Probará automáticamente múltiples escenarios LCP para usted y le mostrará los resultados. Discutiré esos escenarios a continuación y explicaré cómo y por qué acelerará o ralentizará el elemento de imagen LCP.

1. Controlar el candidato LCP: La estrategia de texto primero

¿La forma más rápida de mejorar su Largest Contentful Paint basado en imágenes? ¡No use una imagen! Espera, ¿qué? Sí, me escuchó bien. Déjeme explicarle.

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

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

¿Entonces debería cambiar a un elemento Largest Contentful Paint basado en texto? ¡Eso depende! Las imágenes importan y hacen que su sitio sea visualmente atractivo. Eso significa que no me escucharán abogar por cambiar a viejos y aburridos elementos de texto. ¡Pero los errores también ocurren! Desearía tener un dólar por cada página de categoría que fue víctima del **anti-patrón "LCP Accidental"**. Aquí es donde una página "olvida" agregar un texto descriptivo de categoría en la parte superior, lo que hace que una imagen de producto con carga diferida se convierta en el LCP y retrase los tiempos de carga en segundos. Esto sucede a menudo cuando los diseñadores colocan un gran banner principal en la parte superior del DOM, antes de cualquier titular significativo, dejando al navegador sin otra opción que seleccionar un candidato LCP más lento.

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

Sin entrar en un acalorado debate sobre exprimir el último byte o la configuración perfecta para WebP más grande frente a AVIF, estemos de acuerdo en una cosa: los formatos más antiguos como JPEG y PNG son más grandes y lentos en comparación con los formatos modernos como WebP o AVIF. Si desea profundizar más, este artículo lo desglosa. Para obtener una descripción completa de las técnicas de optimización de imágenes, consulte nuestra guía sobre optimización de imágenes.

Como regla general, debe servir una versión WebP o AVIF con pérdida de su imagen LCP (mejor aún, use estos formatos para todas sus imágenes, pero nos estamos enfocando en LCP aquí). Con el soporte de WebP en alrededor del 95% y el soporte de AVIF en el 92%, todavía tiene sentido servir imágenes de respaldo más antiguas también. Para hacer esto, use la 'mejora progresiva' donde servimos estos formatos modernos solo a los navegadores que los soportan.

Velocidad de decodificación vs. compromiso de compresión

Si bien 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 decodificar en una imagen renderizable en comparación con WebP. Esta es una tarea vinculada a la CPU que ocurre en los hilos del Rasterizador del navegador y aumenta directamente el Element Render Delay. Un AVIF más pequeño podría descargarse más rápido, pero su mayor tiempo de decodificación podría anular ese beneficio, especialmente en dispositivos móviles. Puede diagnosticar esto en el panel de Rendimiento de Chrome DevTools buscando tareas de "Decode Image" de larga duración asociadas con su elemento LCP. Si ve esto, es una señal clara de que la velocidad de decodificación es su cuello de botella, no solo el tiempo de descarga.

Perspectiva de experto: El caso de JPEG-XL. Una verdadera guía experta debe abordar JPEG XL. Es un formato técnicamente notable, especialmente por su capacidad para recomprimir sin pérdidas los JPEG existentes (una gran victoria para los sitios heredados) y su soporte para la decodificación progresiva, de la cual carece AVIF. Sin embargo, su inconveniente decisivo es la falta de un amplio soporte de navegador después de ser abandonado por Chrome. Esto hace que aún no sea viable para el uso general en la web, pero lo posiciona como uno a tener en cuenta para el futuro.

Usando el elemento <picture>: El elemento <picture> permite a los navegadores omitir formatos de imagen no compatibles, seleccionando el primero que puedan manejar. 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>

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

Para un rendimiento máximo, debe combinar la selección de formato con tamaños de imagen responsivos en un solo elemento <picture>. Esto asegura que cada usuario obtenga 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 pequeño archivo AVIF, mientras que un navegador de escritorio más antiguo recurrirá a un JPEG del tamaño correcto.

Usando negociación de contenido

La negociación de contenido permite que su servidor sirva diferentes formatos de imagen según el soporte del navegador. Los navegadores anuncian los formatos compatibles a través del encabezado Accept. Por ejemplo, en Chrome, el encabezado Accept para imágenes se ve así:

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

Luego, en el lado del servidor, lea el encabezado accept y, según el encabezado, sirva el 'mejor formato'.

3. Use imágenes responsivas

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

Para asegurarse de no desperdiciar píxeles, siga estos pasos:

Imágenes responsivas:

Use el atributo srcset para servir diferentes tamaños de imagen según el dispositivo del usuario. De esta manera, los dispositivos más pequeños obtienen 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 predeterminado de 100vw (100% del ancho de la ventana gráfica). Esto significa que en una pantalla de escritorio grande, el navegador descargará una imagen masiva de su lista srcset, incluso si la imagen solo se muestra en una pequeña columna de 500px. Ha proporcionado los ingredientes correctos (srcset) pero omitió la receta (sizes), lo que lleva a 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 qué tan ancha será realmente la imagen en diferentes puntos de interrupción de la ventana gráfica, permitiéndole tomar una decisión de descarga inteligente.

Entendiendo los descriptores w vs. x

El atributo srcset admite dos tipos de descriptores. Para el diseño responsivo donde el tamaño de una imagen cambia con la ventana gráfica, el descriptor w (ancho) es la opción superior y necesaria. Se usa con el atributo sizes para permitir 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 qué tan grande es realmente la imagen en el diseño, lo que lo hace adecuado solo para imágenes de tamaño fijo como íconos.

<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. ¡Escale sus imágenes al tamaño de la pantalla!

Evite servir imágenes que sean más grandes de lo necesario. Si el elemento LCP tiene solo 600px de ancho en la ventana gráfica, asegúrese de que la imagen no sea más grande que eso. Confíe en mí, ¡veo que esto sucede todos los días! Para verificar, simplemente haga esto: inspeccione la imagen haciendo clic derecho en la imagen y seleccione 'inspect-element'. Ahora verá las dev-tools y el HTML de la imagen resaltado con un fondo azul. Ahora puede ver que el tamaño renderizado de la imagen (443 x 139px) es mucho más pequeño que el ancho intrínseco de la imagen (1090x343px). Eso es casi 3 veces más grande y cambiar el tamaño de la imagen podría haber ahorrado al menos el 50% del tamaño del archivo.

5. Use imágenes LCP de carga inmediata (Eager)

Para obtener el mejor rendimiento de su LCP, debe cargar ansiosamente (eagerly load) el elemento LCP visible (y cargar de forma diferida las imágenes que no son visibles de inmediato). Este es uno de los errores más comunes en la optimización LCP, y lo cubrimos en detalle en nuestro artículo sobre cómo arreglar imágenes LCP cargadas de forma diferida.

Carga Eager: El elemento LCP (generalmente contenido en la parte superior) siempre debe cargarse con eager. Esto asegura que aparezca lo más rápido posible, reduciendo el tiempo que tarda en renderizarse su Largest Contentful Paint. De forma predeterminada, las imágenes se cargan con eager a menos que se especifique lo contrario, pero verifique dos veces que no haya establecido loading="lazy" en la imagen LCP. Hacerlo puede retrasar significativamente el LCP y dañar su puntuación de Core Web Vitals. Es importante entender que loading="eager" es el comportamiento predeterminado 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: Las imágenes Lazy no son puestas en cola por el escáner de precarga. El escáner de precarga es un escáner HTML secundario súper rápido que pone en cola recursos importantes de inmediato. Cuando se omite el escáner de precarga, el navegador tendrá que esperar a que el motor de renderizado se complete antes de poner en cola las 'imágenes visibles'. Para que el navegador evalúe el loading="lazy" nativo, primero debe descargar y analizar todo el CSS que bloquea el renderizado para construir el árbol de renderizado. Solo después de que se calcula el diseño, el navegador puede determinar si la imagen está en la ventana gráfica. Esto significa que todo su CSS se convierte en una dependencia de bloqueo para la descarga de la imagen 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 debajo del pliegue (aquellas que no son visibles cuando la página se carga por primera vez), la carga diferida (lazy loading) es el camino a seguir. Al retrasar la carga de estas imágenes hasta que el usuario se desplace cerca de ellas, libera ancho de banda para contenido más importante, como su elemento LCP. De esta manera, la carga diferida es un arma de doble filo: si se usa correctamente, acelerará su contenido LCP; si se usa incorrectamente, ¡lo ralentizará!

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

¿El equilibrio? ¡Cargue con eager el contenido crítico (como su imagen LCP) y cargue con lazy los recursos menos críticos y las imágenes debajo del pliegue!

6. Precargue la imagen LCP

Precargar la imagen Largest Contentful Paint (LCP) es una de las formas más fáciles de acelerar su aparición en la página. Le dice al navegador que priorice la carga de esta imagen, asegurando que esté lista lo antes posible. Para una guía completa sobre la precarga, consulte nuestro artículo dedicado 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 abajo en la cadena, lo que significa que el navegador llega a ella más tarde de lo que debería. Precargar la imagen LCP le permite al navegador saber de antemano que esta imagen es crítica y debe cargarse de inmediato, reduciendo el retraso en la renderización de su elemento más grande.

Cómo precargar la imagen LCP

Al usar la etiqueta <link rel="preload">, puede asegurarse de que el navegador comience a obtener 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 a menudo ocurre si la imagen está enterrada en CSS o 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">

Recuerde: Solo precargue la imagen LCP, ya que precargar demasiados recursos puede abrumar al navegador y dañar el rendimiento. Apéguese a lo que más importa para sus Core Web Vitals.

7. Elimine las animaciones de desvanecimiento (Fade-In) de la imagen LCP

Las animaciones de desvanecimiento (fade-in) pueden ser visualmente atractivas, pero cuando se trata de su Largest Contentful Paint, son un cuello de botella oculto. Si el elemento LCP (a menudo una imagen) utiliza un efecto de desvanecimiento, el navegador no contará el LCP hasta que termine la animación. Esto retrasa el tiempo de LCP y puede dañar significativamente sus métricas de rendimiento.

El tiempo de LCP ocurre después de que termina la animación: El navegador considera que el LCP está completo solo cuando el elemento es completamente visible. Si tiene una animación de desvanecimiento, el temporizador sigue funcionando hasta que la imagen o el contenido se haya desvanecido por completo, lo que puede agregar fácilmente segundos adicionales a su puntuación LCP.

Manténgalo simple: Para asegurar que el elemento LCP aparezca lo más rápido posible, evite usar efectos de desvanecimiento. Deje que la imagen se cargue y se muestre inmediatamente, sin ninguna transición o animación.

Al omitir los desvanecimientos en la imagen LCP, evitará retrasos innecesarios y mejorará sus Core Web Vitals, asegurando una experiencia más rápida y fluida para los usuarios.

8. Auto-hospede el elemento LCP

Para obtener el mejor rendimiento de su Largest Contentful Paint, siempre debe considerar auto-hospedar el elemento LCP, especialmente si es una imagen u otro recurso crítico. Depender de servidores de terceros puede introducir retrasos que están completamente fuera de su control, lo que puede dañar su LCP y el rendimiento general de la página.

Piénselo de esta manera: No auto-hospedar su elemento LCP es como pedir azúcar prestada constantemente a su vecino. Cada vez, tiene que caminar, esperar en la puerta y esperar que estén en casa. Depender de un servidor de terceros para su LCP hace que su sitio web espere ese recurso externo, ralentizando los tiempos de carga. El auto-hospedaje es como mantener el azúcar en su cocina: rápido, directo y confiable.

Reduzca las dependencias externas: Cuando su elemento LCP (como una imagen) está alojado en un servidor de terceros, está a merced de la velocidad, disponibilidad y cualquier tiempo de ida y vuelta (RTT) adicional de ese servidor. El auto-hospedaje elimina esta incertidumbre, permitiéndole servir la imagen directamente desde su propio servidor, asegurando una entrega más rápida y confiable.

Aproveche el almacenamiento en caché y las optimizaciones: Al auto-hospedar, puede aprovechar al máximo las estrategias de almacenamiento en caché y servir la imagen desde el servidor más cercano al usuario, especialmente si está utilizando un CDN. Esto reduce el tiempo que tarda en cargarse el elemento LCP, lo que resulta en un renderizado más rápido.

Control sobre la optimización de imágenes: El auto-hospedaje le da control sobre cómo se optimiza la imagen, ya sea compresión, cambio de tamaño o selección de formato, sin depender del manejo de terceros. De esta manera, puede asegurarse de que la imagen esté perfectamente adaptada para una carga rápida.

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

El renderizado del lado del cliente (CSR) puede ser un obstáculo importante cuando se trata de optimizar su Largest Contentful Paint. Si su elemento LCP (generalmente una imagen grande, bloque de texto o video) se renderiza en el lado del cliente a través de JavaScript, a menudo conduce a tiempos de LCP más lentos ya que el navegador tiene que esperar a que los scripts se descarguen, analicen y ejecuten 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 procesa JavaScript, lo que puede retrasar significativamente su aparición. Cuanto más tarde esto, peor será su puntuación LCP. Cada segundo extra gastado procesando scripts se traduce en una espera más larga para que sus usuarios vean el contenido más importante.

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

Minimice JavaScript en la ruta crítica: Si no puede evitar algunos scripts del lado del cliente, asegúrese de que no bloqueen el renderizado del elemento LCP. Use defer o async en scripts no críticos para evitar que retrasen la aparición de su LCP.

10. Reserve espacio para prevenir cambios de diseño

Siempre incluya atributos explícitos de width y height en sus etiquetas <img>. Esta es una instrucción crítica para el navegador, que le permite calcular la relación de aspecto de la imagen y reservar la cantidad correcta de espacio en el diseño *antes* de que la imagen se haya descargado.

Perspectiva de experto: Comportamiento moderno de width y height

Un concepto erróneo común es que estos atributos hacen que una imagen no sea responsiva. Esto ya no es cierto en los navegadores modernos. El navegador utiliza estos atributos HTML para calcular una relación de aspecto y mantener 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 que bloquee el renderizado, 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 CSS. Una fuente común de cambio de diseño es un <div> que colapsa a una altura de cero inicialmente y luego aparece en tamaño cuando se aplica la imagen de fondo. Para evitar esto, use la propiedad CSS aspect-ratio directamente en el elemento contenedor para reservar el espacio necesario desde el principio.

11. Audite el bloqueo del hilo principal

Incluso si su imagen LCP está perfectamente optimizada y priorizada, su renderizado final puede retrasarse si el hilo principal del navegador está ocupado ejecutando JavaScript pesado. A menudo, la fuente de este bloqueo son los scripts de terceros para análisis, anuncios o widgets de atención al cliente. Estos scripts pueden monopolizar la CPU, aumentando el Element Render Delay. Utilice el panel de Rendimiento en Chrome DevTools para identificar tareas de larga duración durante la carga inicial, atribuirlas a su fuente y diferir o eliminar cualquiera que no sea crítica para el renderizado inicial. Para obtener más información sobre este tema, consulte nuestra guía sobre Element Render Delay.

Guías relacionadas de optimización LCP

La optimización de imágenes es solo una parte de lograr un LCP rápido. Explore las otras fases de LCP para obtener una estrategia de optimización completa:

• Arreglar e identificar problemas de LCP: La metodología de diagnóstico completa para encontrar y solucionar problemas de LCP utilizando datos de campo y herramientas de laboratorio.
• Resource Load Delay: Asegúrese de que el navegador descubra su recurso LCP lo antes posible con preload, fetchpriority y una estructura HTML óptima.
• Resource Load Duration: Reduzca el tiempo de descarga a través de la compresión, la configuración de CDN y la optimización de la red.
• Element Render Delay: Limpie el hilo principal para que el navegador pueda pintar el elemento LCP inmediatamente después de la descarga.