Una imagen de 1920 píxeles de ancho en una página la descargan entera también los usuarios de móvil, para luego reducirla a 390 píxeles en pantalla: cinco veces más ancho de banda y una carga más lenta sin ningún motivo. srcset permite que el navegador elija la versión que encaja con la pantalla, siempre que hayas producido esas versiones.
Por qué una sola imagen no basta
La cifra LCP de Core Web Vitals suele corresponder a la imagen grande que aparece sobre el pliegue. Si sirves a un móvil un archivo de 1920 de ancho y 400KB, el LCP rara vez baja de 2,5 segundos; una versión de 480 de ancho y 40KB, con la misma conexión, es un orden de magnitud más rápida. La señal de experiencia de página de Google lee ese número directamente.
Al revés, una imagen de 768 de ancho en un escritorio grande se ve borrosa. De ahí la necesidad de varios tamaños, entre los que elige el navegador.
Una tabla práctica de breakpoints
Los breakpoints siguen el ancho al que se muestra la imagen en la página, no el del viewport. Para los dos casos habituales, banners a todo el ancho e imágenes dentro de artículos:
- Imágenes a todo el ancho (hero, banners): 480, 768, 1200, 1920. Móvil, tableta, portátil, pantalla grande.
- Imágenes de artículo (columna de contenido de hasta unos 800): 400, 800, 1200; el 1200 sirve a pantallas de 1,5x–2x.
- Miniaturas y tarjetas (mostradas a unos 300): 300 y 600.
Más escalones no es mejor. Cada uno es otra exportación y otro archivo que almacenar, y los navegadores toleran los desajustes, así que lo ideal son escalones separados 1,5–2x. Cuatro escalones cubren más de nueve de cada diez combinaciones de dispositivo.
¿Hacen falta versiones 2x?
Las pantallas Retina y la mayoría de los móviles tienen una densidad de 2x–3x; una imagen mostrada a 400 de ancho necesita 800 píxeles para verse nítida ahí. Los escalones mayores de la tabla ya hacen de versión 2x de los menores: 768 es el 2x de un móvil de 390 de ancho y 1200 es el 2x de una columna de 600.
Por eso no hace falta un juego «@2x» aparte. Mantén una separación aproximada de 2x entre escalones y el navegador elegirá el mayor según la densidad.
Formato: primero WebP, JPG como alternativa
A igual calidad, WebP pesa entre un 25 y un 35 % menos que JPG y todos los navegadores modernos lo admiten. Exporta WebP en cada tamaño y conserva una alternativa JPG mediante el elemento picture para los navegadores antiguos; si a tu público ya no le importan los navegadores anteriores a 2020, basta con WebP.
AVIF pesa aún menos, pero se codifica mucho más despacio en el navegador, lo que penaliza los lotes grandes. AVIF vs WebP vs JPEG explica los pros y contras con detalle.
Exportar todo el juego por lotes
Arrastra las imágenes originales a Procesamiento de imágenes por lotes y ejecuta una vez por escalón, cambiando cada vez el ancho y el sufijo:
- Tamaño: ancho 480, Permitir ampliar desactivado, salida WebP al 80 %, sufijo -480.
- Los mismos ajustes en 768 con sufijo -768; después 1200; después 1920.
- Para la alternativa JPG, cambia la salida a JPG, mantén los sufijos y ejecuta de nuevo.
Cada ejecución tarda segundos y el ZIP ya contiene hero-480.webp, hero-768.webp y los demás, listos para la carpeta de imágenes. Deja desactivado Permitir ampliar para que un original de 1000 píxeles nunca se estire a 1920.
Para ver la diferencia de peso de cada escalón en una sola imagen, prueba Redimensionar imágenes con un archivo.
Escribir el HTML
Para una imagen a todo el ancho:
<img src="hero-1200.jpg"
srcset="hero-480.webp 480w, hero-768.webp 768w, hero-1200.webp 1200w, hero-1920.webp 1920w"
sizes="100vw" width="1920" height="1080" alt="...">Para imágenes de artículo, ajusta sizes al ancho real, por ejemplo sizes="(max-width: 840px) 100vw, 800px". Incluye siempre width y height para que el navegador reserve el espacio y la página no salte.
Con eso hecho, suma los consejos de carga diferida y compresión de cómo hacer que las imágenes carguen más rápido y la parte de imágenes de tu puntuación de rendimiento queda prácticamente al máximo.