Optimizar la imagen de Largest Contentful Paint

Optimizar la imagen de Largest Contentful Paint

Esta guía forma parte del centro de recursos de Largest Contentful Paint (LCP). En la mayoría de los sitios web, el elemento LCP es una imagen. Si la imagen no es la correcta, su puntuación de LCP se verá afectada. 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 ordenadores como móviles) tienen una puntuación de Largest Contentful Paint "buena". Eso significa que el 35% de las páginas vistas están fallando, y esto se debe en parte a errores cometidos con las imágenes. Este artículo desglosa los patrones de buenas prácticas comunes y los errores cuando las imágenes se convierten en el elemento Largest Contentful Paint.

Aunque todos estos factores importan, si su elemento LCP es una imagen (¡y con frecuencia lo es!), hay pasos sencillos que puede tomar 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 se fíe de la palabra de nadie. Hay demasiados "gurús" que predican información errónea. Por eso he creado un experimento de LCP totalmente automático donde puede comprobar por sí mismo qué ocurre cuando el elemento LCP no se carga de forma óptima. ¡Eche un vistazo a mi LCP Test en github o pruebe la demo en vivo!

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

1. Controlar el candidato a LCP: La estrategia de "Primero el texto"

¿La forma más rápida de mejorar su Largest Contentful Paint basado en imágenes? ¡No use una imagen! Espere, ¿qué? Sí, ha oído bien. Permítame explicarlo.

Por qué el texto es más rápido que una imagen. La diferencia de rendimiento se reduce a la canalización de solicitudes (request pipeline). Un nodo de texto (como un <h1> o <p>) forma parte del documento HTML principal. No tiene una solicitud de recurso separada; su renderizado solo está bloqueado por el 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 estar bloqueada por el CSS. Esta distinción es la razón principal de la diferencia de rendimiento y 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 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, suele coincidir con el First Contentful Paint.

Entonces, ¿debería cambiar a un elemento Largest Contentful Paint basado en texto? ¡Depende! Las imágenes importan y hacen que su sitio sea visualmente atractivo. Eso significa que no me oirá abogar por cambiar a viejos y aburridos elementos de texto. ¡Pero también se cometen errores! Ojalá tuviera un dólar por cada página de categoría que fue víctima del antipatrón "Accidental LCP". Esto ocurre cuando una página "olvida" añadir un texto descriptivo de la categoría en la parte superior (above the fold), lo que provoca que una imagen de producto cargada de forma perezosa (lazy-loaded) se convierta en el LCP, retrasando los tiempos de carga durante segundos. Esto suele ocurrir cuando los diseñadores colocan un gran banner hero en la parte superior del DOM, antes de cualquier titular significativo, dejando al navegador sin otra opción que seleccionar un candidato a LCP más lento.

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

Sin entrar en un acalorado debate sobre cómo exprimir el último byte o los ajustes perfectos para WebP frente a AVIF, pongámonos de acuerdo en una cosa: 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 obtener una visión completa de las técnicas de optimización de imágenes, consulte nuestra guía sobre optimización de imágenes.

As a general rule, debería servir una versión WebP o AVIF con pérdida de su imagen LCP (mejor aún, utilice estos formatos para todas sus imágenes, pero aquí nos centramos en el LCP). Con el soporte de WebP en torno al 95% y el soporte de AVIF al 92%, sigue teniendo sentido servir también imágenes de respaldo más antiguas. Para ello, utilice la "mejora progresiva" (progressive enhancement) en la que servimos estos formatos modernos solo a los navegadores que los soportan.

Velocidad de decodificación frente al compromiso de compresión

Aunque AVIF ofrece la mejor compresión (el 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 WebP. Se trata de una tarea que depende de la CPU, que se realiza en los hilos de rasterización (Rasterizer threads) del navegador y que aumenta directamente el Element Render Delay. 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. Puede diagnosticar esto en el panel Performance de Chrome DevTools buscando tareas de "Decode Image" de larga duración asociadas a 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 experta: El caso de JPEG-XL. Una verdadera guía experta debe abordar el JPEG XL. Es un formato técnicamente notable, especialmente por su capacidad para volver a comprimir sin pérdidas los JPEGs existentes (una gran ventaja para los sitios antiguos) y su soporte para la decodificación progresiva, de la que carece el AVIF. Sin embargo, su inconveniente decisivo es la falta de un amplio soporte por parte de los navegadores después de que Chrome lo abandonara. Esto hace que todavía no sea viable para el uso web general, pero lo posiciona como uno de los formatos a seguir en el futuro.

Uso del elemento <picture>: El elemento <picture> permite a los navegadores omitir los formatos de imagen no compatibles, seleccionando el primero que puedan manejar. He aquí cómo hacerlo:

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

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

Para obtener el máximo rendimiento, debe combinar la selección de formato con tamaños de imagen responsivos en un único elemento <picture>. Esto garantiza 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 utiliza los atributos srcset y sizes para elegir la resolución adecuada.

<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="Texto alternativo descriptivo para la imagen hero"
    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 recurrirá a un JPEG de tamaño correcto.

Uso de la 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 mediante la cabecera Accept. Por ejemplo, en Chrome, la cabecera 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 la cabecera Accept y, basándose en ella, sirva el "mejor formato".

3. Utilizar imágenes responsivas

Cuando se trata de optimizar las 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 sigan viéndose 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 los usuarios con conexiones lentas o dispositivos móviles.

To ensure you're not wasting pixels, siga estos pasos:

Imágenes responsivas:

Utilice 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 obtienen imágenes más pequeñas, lo que ayuda a acelerar el LCP.

Por qué el atributo sizes es crítico

Utilizar 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 masiva de su lista srcset, incluso si la imagen solo se muestra en una pequeña columna de 500px. Ha proporcionado los ingredientes adecuados (srcset) pero ha omitido la receta (sizes), lo que conlleva un desperdicio de ancho de banda y un LCP más lento. El atributo sizes proporciona el contexto de diseño necesario, indicando al navegador qué ancho tendrá realmente la imagen en los diferentes puntos de interrupción (breakpoints) del viewport, permitiéndole realizar una elección de descarga inteligente.

Entender los descriptores w frente a x

El atributo srcset admite dos tipos de descriptores. Para el diseño responsivo, en el que el tamaño de una imagen cambia con el viewport, el descriptor w (width) es la opción superior y necesaria. Se utiliza con el atributo sizes para que el navegador elija la mejor imagen en función de su tamaño renderizado en el diseño. El descriptor x (device-pixel-ratio), más sencillo, solo tiene en cuenta la densidad de píxeles de la pantalla, ignorando el tamaño real de la imagen en el diseño, por lo que solo es adecuado 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="Imagen" width="123" height="123">

4. ¡Ajuste sus imágenes al tamaño de la pantalla!

Evite servir imágenes más grandes de lo necesario. Si el elemento LCP solo tiene 600px de ancho en el viewport, asegúrese de que la imagen no sea más grande que eso. ¡Créame, veo que esto ocurre todos los días! Para comprobarlo, haga lo siguiente: inspeccione la imagen haciendo clic con el botón derecho sobre ella y seleccione "inspeccionar elemento". Verá las herramientas de desarrollo y el HTML de la imagen aparecerá resaltado con un fondo azul. Ahora puede ver que el tamaño renderizado de la imagen (443 x 139px) es mucho menor que el ancho intrínseco de la imagen (1090 x 343px). 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. Utilizar imágenes LCP cargadas ansiosamente (Eager Loaded)

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

Carga ansiosa (Eager Loading): El elemento LCP (normalmente contenido en la parte superior, above-the-fold) siempre debe cargarse ansiosamente. Esto asegura que aparezca lo antes posible, reduciendo el tiempo que tarda en renderizarse su Largest Contentful Paint. Por defecto, las imágenes se cargan ansiosamente a menos que se especifique lo contrario, pero compruebe dos veces que no ha establecido loading="lazy" en la imagen LCP. Hacerlo puede retrasar significativamente el LCP y perjudicar su puntuación de 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 asegurarse de que loading="lazy" not esté presente.

Alerta geek: Las imágenes perezosas (lazy images) no son puestas en cola por el escáner de precarga (preload scanner). El escáner de precarga es un escáner HTML secundario súper rápido que pone en cola los recursos importantes inmediatamente. Cuando se omite el escáner de precarga, el navegador tendrá que esperar a que el motor de renderizado finalice 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 (render tree). Solo después de calcular el diseño (layout) puede el navegador determinar si la imagen está en el viewport. Esto significa que todo su CSS se convierte en una dependencia bloqueante para la descarga de la imagen LCP, lo cual es un desastre para el rendimiento.

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

Para las imágenes que aparecen debajo del pliegue (las que no son visibles cuando la página se carga por primera vez), la carga perezosa es el camino a seguir. Al retrasar la carga de estas imágenes hasta que el usuario se desplaza cerca de ellas, libera ancho de banda para el contenido más importante, como su elemento LCP. De esta forma, la carga perezosa es un cuchillo de doble filo: si se usa correctamente, acelerará su contenido LCP; si se usa incorrectamente, lo ralentizará.

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

El equilibrio? Cargue ansiosamente el contenido crítico (como su imagen LCP) y cargue perezosamente los recursos menos críticos y las imágenes debajo del pliegue.

6. Preload de la imagen LCP

El preload de la imagen LCP le indica al navegador que la obtenga inmediatamente, antes de que la descubra de forma natural en el HTML. Para obtener una guía completa sobre el preload, consulte nuestro artículo dedicado sobre preload de la imagen LCP.

¿Por qué hacer preload de 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 llega a ella más tarde de lo que debería. El preload de la imagen LCP permite al navegador saber de antemano que esta imagen es crítica y debe cargarse inmediatamente, reduciendo el retraso en el renderizado de su elemento más grande.

Cómo hacer preload de la imagen LCP

Mediante el uso de 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 garantiza que la imagen LCP esté en la cola del navegador desde el principio, evitando la espera que suele producirse si la imagen está enterrada en el CSS o en los 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">

Recuerde: Solo haga preload de la imagen LCP, ya que el preload de demasiados recursos puede abrumar al navegador y perjudicar el rendimiento. Céntrese en lo que más importa para sus Core Web Vitals.

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

Las animaciones de desvanecimiento pueden ser visualmente atractivas, 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 el tiempo de LCP y puede perjudicar significativamente sus métricas de rendimiento.

El tiempo de LCP se produce después de que termine la animación: El navegador considera el LCP completado solo cuando el elemento es totalmente visible. Si tiene una animación de fade-in, el temporizador sigue funcionando hasta que la imagen o el contenido se ha desvanecido por completo, lo que puede añadir fácilmente segundos extra a su puntuación de LCP.

Manténgalo simple: Para asegurarse de que el elemento LCP aparezca lo antes posible, evite utilizar efectos de fade-in. Deje que la imagen se cargue y se muestre inmediatamente, sin ninguna transición o animación.

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

8. Auto-alojamiento del elemento LCP

Aloje usted mismo su imagen LCP (Self-host). Confiar en servidores de terceros introduce retrasos que están completamente fuera de su control, lo que puede perjudicar su LCP y el rendimiento general de la página.

Piénselo de esta manera: No auto-alojar su elemento LCP es como pedir prestado azúcar a su vecino constantemente. Cada vez, tiene que ir caminando, esperar en la puerta y esperar que estén en casa. Confiar en un servidor de terceros para su LCP hace que su sitio web espere a ese recurso externo, ralentizando los tiempos de carga. El auto-alojamiento es como tener el azúcar en su cocina: rápido, directo y fiable.

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

Utilizar el almacenamiento en caché y las optimizaciones: Al auto-alojar, 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 utiliza un CDN. Esto reduce el tiempo que se tarda en cargar el elemento LCP, lo que resulta en un renderizado más rápido.

Control sobre la optimización de la imagen: El auto-alojamiento le da control sobre cómo se optimiza la imagen, ya sea la compresión, el redimensionamiento o la selección del formato, sin depender de la gestión de terceros. De esta forma, puede asegurarse de que la imagen está perfectamente adaptada para una carga rápida.

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

El renderizado del lado del cliente (CSR) es una de las peores cosas que puede hacer a su LCP. Si su elemento LCP (normalmente una imagen grande, un bloque de texto o un vídeo) 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, se analicen y se ejecuten antes de mostrar el contenido crítico.

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

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

Minimizar el 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 los scripts no críticos para evitar que retrasen la aparición de su LCP.

10. Reservar espacio para evitar cambios de diseño (Layout Shifts)

Incluya siempre 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 experta: Comportamiento moderno de width y height

Una idea errónea 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 se establece en width: 100%; height: auto;. Proporcionar estos atributos es superior a utilizar 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, lo que le da una ventaja crítica.

Gestión de imágenes de fondo CSS

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

11. Auditoría del bloqueo del hilo principal (Main-Thread Blocking)

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 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 Performance de Chrome DevTools para identificar tareas de larga duración durante la carga inicial, atribúyalas a su origen y posponga o elimine cualquiera que no sea crítica para el renderizado inicial. Para saber más sobre este tema, consulte nuestra guía sobre Element Render Delay.

Guías relacionadas con la optimización del LCP

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

• Identificar y corregir problemas de LCP: La metodología de diagnóstico completa para encontrar y corregir todos los 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 mediante la compresión, la configuración del CDN y la optimización de la red.
• Element Render Delay: Libere el hilo principal para que el navegador pueda pintar el elemento LCP inmediatamente después de la descarga.