Imágenes Responsivas (srcset)

TL;DR — Las imágenes responsive permiten que un navegador cargue una versión del tamaño adecuado de una imagen en lugar de un archivo gigante: una pequeña en un teléfono, una grande en un escritorio. Se hace con los atributos srcset y sizes en tu etiqueta <img> (enumera los tamaños que tienes; el navegador elige). Esto no aumenta directamente tu posicionamiento, pero hace que las páginas sean más rápidas y evita que “salten” mientras se cargan las imágenes, y la velocidad sí es algo que Google mide.

Qué son las imágenes responsive

Una imagen “responsive” se adapta al dispositivo que la ve. En lugar de enviar la misma foto enorme a un teléfono y a un escritorio, le das al navegador algunas versiones a diferentes tamaños y dejas que tome la que encaje. Los teléfonos reciben un archivo pequeño; las pantallas grandes reciben uno grande. Menos datos desperdiciados, páginas más rápidas.

Hay dos formas de hacer esto, y vale la pena saber cuál es cuál:

• srcset + sizes en <img> — la común. Misma imagen, diferentes tamaños. Enumera lo que tienes y el navegador elige. Esto se llama cambio de resolución.
• El elemento <picture> — para cuando quieres una imagen genuinamente diferente a diferentes tamaños (por ejemplo, un recorte ancho en escritorio y un recorte alto y ajustado en móvil), o un formato de archivo moderno con un respaldo. Esto se llama dirección de arte, y la mayoría de los sitios no lo necesitan.

La versión básica

Así es como se ve el cambio de resolución:

<img
  src="puppy-1000.jpg"
  srcset="puppy-1000.jpg 1000w, puppy-2000.jpg 2000w, puppy-3000.jpg 3000w"
  sizes="(max-width: 600px) 480px, 1000px"
  width="1000" height="1000"
  alt="Puppy with balloons" />

• src es tu respaldo normal, siempre presente. Consérvalo.
• srcset enumera las versiones que tienes y qué tan ancha es cada una (1000w = 1000 píxeles de ancho).
• sizes le dice al navegador qué tan grande aparecerá realmente la imagen para que pueda elegir el archivo correcto antes de cargar cualquier cosa.
• width y height reservan espacio para que la página no salte mientras se carga la imagen.
• alt es la misma descripción que siempre escribirías. Mantenla idéntica en cada versión.

Por qué molestarse (la respuesta honesta)

Las imágenes responsive no te otorgan un “impulso” en el posicionamiento. Lo que hacen es hacer que las páginas carguen más rápido y evitar que el diseño se desplace — y esas son cosas que Google mide como parte de la experiencia de página. Si una herramienta de velocidad (Lighthouse, PageSpeed Insights) te está insistiendo para que “dimensiones las imágenes correctamente”, srcset/sizes es la solución que está pidiendo.

Una cosa más: esto no cambia lo que aparece en Google Imágenes. Google indexa la imagen en tu atributo src — las variantes responsive son solo entrega. Así que mantén tu texto alt, el nombre del archivo y la URL de la imagen principal iguales sin importar qué versión cargue el navegador.

¿Quieres la versión precisa — descriptores w vs x, cuándo realmente necesitas <picture>, los mecanismos de LCP y cambio de diseño, y las reglas de indexación móvil — cambia a la pestaña Avanzado.

TL;DR — Dos trabajos, una familia de sintaxis. srcset/sizes en <img> = cambio de resolución (misma imagen, el navegador elige la mejor opción — una sugerencia); <picture> = dirección de arte o cambio de formato (recortes/formato dictados por el autor — un comando). La mayoría de los sitios solo necesitan la primera. Las imágenes responsive no son una señal de posicionamiento directa y no cambian lo que Google indexa — Google indexa la URL src, así que mantén el texto alt, los nombres de archivo y las URLs de imagen estables en todos los puntos de interrupción (indexación móvil primero). El beneficio real son los Core Web Vitals: dimensionar correctamente las imágenes es la solución detrás de la auditoría “Properly size images” de Lighthouse (falla con una brecha de 4 KiB), y width/height (o aspect-ratio) — no srcset — es lo que previene el CLS. No cargues de forma diferida la imagen LCP. Reutilizo el patrón exacto de srcset + width/height de mi artículo sobre CLS en Ahrefs.

Dos trabajos diferentes, una familia de sintaxis

Todo en este tema se reduce a dos mecanismos, y la mitad de la confusión que hay por ahí viene de mezclarlos:

1. Cambio de resolución — la misma imagen en diferentes tamaños o densidades de píxeles. Le das al navegador un menú con srcset y sizes en el <img>, y el navegador decide qué archivo descargar según la ventana gráfica y la densidad de pantalla. Este es el caso común.
2. Dirección de arte — una imagen genuinamente diferente por condición: un recorte ancho en escritorio, un recorte vertical ajustado en móvil, o un formato de archivo completamente distinto. Aquí tú dictas la elección con el elemento <picture>.

El curso web.dev Learn: Responsive images plantea la diferencia exactamente bien: con srcset el navegador recibe sugerencias, mientras que “el elemento picture da comandos.” Y la frase que define el alcance y que vale la pena tatuarse en la pared, también de web.dev: “You probably won’t need to use the picture element for most of your responsive images — the srcset and sizes attributes on the img element cover a lot of use cases.” (traducción) «Probablemente no necesitarás usar el elemento picture para la mayoría de tus imágenes responsivas — los atributos srcset y sizes en el elemento img cubren muchos casos de uso.» Recurre a <picture> solo cuando realmente necesites una imagen diferente, no un tamaño diferente de la misma.

srcset y sizes — cambio de resolución

Descriptores w frente a descriptores x

srcset acepta una lista separada por comas de archivos candidatos, cada uno etiquetado con un descriptor. Hay dos tipos:

• Descriptores de ancho (w) — indicas el ancho de píxeles intrínseco de cada archivo (puppy-2000.jpg 2000w). El navegador combina eso con tu valor de sizes para determinar qué archivo se ajusta mejor al espacio y a la densidad de píxeles del dispositivo. Esta es la opción flexible y la que usarás la mayor parte del tiempo.
• Descriptores de densidad de píxeles (x) — indicas qué archivo es para cada relación de píxeles del dispositivo (logo.png 1x, logo@2x.png 2x). Úsalos para imágenes de tamaño fijo (un avatar, un logo) donde el tamaño mostrado nunca cambia; no necesitas sizes con descriptores x.

Regla general: imágenes fluidas de ancho de contenido → descriptores w + sizes; imágenes de interfaz de tamaño fijo → descriptores x.

Por qué importa sizes (y qué pasa si lo omites)

Con descriptores w, sizes no es cosmética opcional — es cómo el navegador sabe qué tan grande se renderizará la imagen para poder elegir antes del layout. Según web.dev, sizes “tells the browser what size you expect the image to be displayed at under different conditions,” (traducción) «indica al navegador a qué tamaño esperas que se muestre la imagen en distintas condiciones», como una lista separada por comas de condiciones de medios y anchos:

sizes="(max-width: 600px) 480px, 1000px"

Léelo como: “si la ventana gráfica es de 600px o menos, la imagen tendrá unos 480px de ancho; de lo contrario, unos 1000px.” Omite sizes y el navegador asume que la imagen llena todo el ancho de la ventana gráfica (100vw) — así que en una pantalla ancha puede descargar tu archivo más grande para una imagen que en realidad se renderiza a 400px, anulando silenciosamente todo el propósito. Faltar sizes es el error de srcset más común.

No adivines esos valores de ancho desde el layout en tu cabeza — verifica el ancho CSS real renderizado de la imagen en el navegador (DevTools → Elements → el ancho calculado de la caja del <img>) en cada punto de interrupción que te importe, y configura sizes para que coincida. Un valor de sizes que no coincide con el ancho renderizado real aún hace que el navegador seleccione el candidato incorrecto aunque el marcado sea sintácticamente correcto — la validación de sintaxis por sí sola no detectará eso; consulta la verificación de currentSrc abajo para confirmar qué se cargó realmente.

Ejemplo práctico (mi patrón reutilizable)

Este es el patrón exacto de mi artículo en Ahrefs, What Is Cumulative Layout Shift (CLS) & How To Improve It, expandido con sizes:

<img
  src="puppy-1000.jpg"
  srcset="puppy-1000.jpg 1000w,
          puppy-2000.jpg 2000w,
          puppy-3000.jpg 3000w"
  sizes="(max-width: 600px) 480px, 1000px"
  width="1000" height="1000"
  alt="Puppy with balloons" />

Cada pieza es esencial: src es el respaldo y la URL que Google indexa; srcset lista los candidatos con descriptores w; sizes le dice al navegador el ancho renderizado; width/height reservan espacio (la solución para CLS, más abajo); alt permanece idéntico sin importar qué archivo se cargue.

El elemento picture: dirección de arte y cambio de formato

Cuándo realmente lo necesitas

Usa <picture> para dos cosas que srcset no puede hacer:

1. Dirección de arte: un recorte diferente por punto de interrupción. El ejemplo de web.dev: en un teléfono estrecho podrías servir un recorte alto y ajustado; en un escritorio ancho, uno corto y ancho. Mismo sujeto, encuadre deliberadamente diferente.
2. Cambio de formato: ofrece AVIF/WebP con un respaldo JPEG mediante <source type="…">, dejando que el navegador tome el primer formato que soporte. Esto se conecta directamente con la guía de formatos en el centro de SEO de imágenes.

La sintaxis (y la regla del respaldo)

El elemento <picture> envuelve uno o más elementos <source> y siempre termina con un <img> simple:

<!-- Art direction: different crop per breakpoint -->
<picture>
  <source media="(max-width: 600px)" srcset="hero-crop-mobile.jpg">
  <img src="hero-crop-desktop.jpg" width="1200" height="675"
       alt="Product hero shot">
</picture>

<!-- Format switching: modern format with a fallback -->
<picture>
  <source type="image/avif" srcset="hero.avif">
  <source type="image/webp" srcset="hero.webp">
  <img src="hero.jpg" width="1200" height="675" alt="Product hero shot">
</picture>

Ese <img src> final no es opcional. Google lo afirma directamente: según la sección 4.8.1 del estándar HTML, “make sure that you provide an img element as a fallback with a src attribute when using the picture element.” (traducción) «Asegúrate de proporcionar un elemento img como respaldo con un atributo src cuando uses el elemento picture». Es el archivo al que recurren los navegadores antiguos y los rastreadores, y, de nuevo, el que Google indexa.

¿Ayuda srcset al SEO? Directo vs. indirecto

Aquí está el enfoque que todas las guías competidoras fallan, así que seré directo.

Directamente: no. El marcado de imágenes responsivas no es una señal de clasificación como lo son el texto alt o los nombres de archivo para la búsqueda de imágenes. Agregar srcset no eleva tus posiciones, y no cambia lo que aparece en Google Imágenes. Google indexa la imagen referenciada en src; las variantes srcset/<picture> son un mecanismo de entrega, no activos indexables por separado. Mantén tu texto alt, nombre de archivo y datos estructurados adjuntos a esa imagen src principal.

Indirectamente: sí, y es una de las mayores palancas que tienes. Las imágenes con el tamaño correcto son la solución concreta más efectiva para dos Core Web Vitals: LCP y CLS, que alimentan las señales de experiencia de página de Google. Ese es todo el beneficio. Tiene la misma forma que la historia de WebP/AVIF en el centro de SEO de imágenes: sin impulso para el formato en sí, la ganancia es velocidad.

Imágenes responsivas y LCP

Las imágenes sobredimensionadas son una de las causas más comunes de un Largest Contentful Paint lento, y las imágenes responsivas son la solución recomendada por Lighthouse. La auditoría de Lighthouse “Properly size images” lista “all images in your page that aren’t appropriately sized, along with the potential savings” (traducción) «todas las imágenes en tu página que no tienen el tamaño adecuado, junto con los ahorros potenciales» — cualquier cosa más grande de lo necesario “just results in wasted bytes and slows down page load time.” (traducción) «solo resulta en bytes desperdiciados y ralentiza el tiempo de carga de la página». Su solución, textualmente: “With responsive images, you generate multiple versions of each image, and then specify which version to use in your HTML or CSS using media queries, viewport dimensions, and so on.” (traducción) «Con imágenes responsivas, generas múltiples versiones de cada imagen y luego especificas qué versión usar en tu HTML o CSS mediante consultas de medios, dimensiones de viewport, etc.»

Dos detalles que vale la pena conocer:

• El umbral de fallo es 4KiB. Lighthouse solo marca una imagen cuando “the rendered size is at least 4KiB smaller than the actual size.” (traducción) «el tamaño renderizado es al menos 4KiB más pequeño que el tamaño real». Los excesos pequeños no cuentan; servir un archivo de 3000px en un espacio de 400px sí.
• Un atajo de herramientas. Google recomienda RespImageLint, “a helpful bookmarklet for identifying the optimal srcset and sizes values for your images.” (traducción) «un bookmarklet útil para identificar los valores óptimos de srcset y sizes para tus imágenes». Ejecútalo antes de calcular manualmente los puntos de interrupción.

No cargues perezosamente la imagen LCP

Esta es la regla que la gente más incumple. srcset en tu hero está bien, pero nunca lo combines con carga diferida en el elemento LCP. La imagen más grande visible sin desplazamiento debe cargarse de forma eager con fetchpriority="high", exactamente como cubre el centro de SEO de imágenes. Y cuando construyas un hero responsivo con <picture>, mantén la lógica de intercambio nativa: Google advierte que “no cargará contenido que requiera interacciones del usuario” como deslizar o hacer clic, por lo que un esquema JS que solo carga la imagen real después de la interacción la oculta de Google.

Imágenes responsivas y CLS

Aquí está la trampa: srcset por sí solo no hace nada por el desplazamiento del diseño. El cambio de resolución decide qué archivo se carga; no reserva espacio para él. Sin dimensiones, según la guía de Optimización de CLS de web.dev, “a medida que las imágenes se cargan, el texto se desplaza hacia abajo en la página para hacerles espacio” — porque el espacio “no se puede asignar hasta que el navegador comienza a descargarlo y puede determinar sus dimensiones.”

La solución son dimensiones explícitas, y se combina con el marcado responsivo:

• Establece los atributos width y height en el <img>. Los navegadores modernos “establecen la relación de aspecto predeterminada de las imágenes basándose en los atributos width y height de la imagen”, por lo que esos dos números reservan el cuadro correcto antes de que se descargue cualquier variante de srcset. (web.dev)
• Combínalos con height: auto en CSS para contenedores fluidos. Esta es la parte que parece contradictoria pero no lo es: la propia guía de web.dev es “usar CSS para redimensionar la imagen al ancho del contenedor” y “establecer height: auto; para evitar usar un valor fijo para la altura de la imagen.” Los atributos HTML establecen la relación de aspecto intrínseca; el CSS permite que la imagen se escale fluidamente. Juntos previenen el CLS y siguen siendo responsivos.
• O usa aspect-ratio en CSS para reservar el espacio cuando no puedas establecer atributos.

Lo que acaba con un mito persistente: los atributos width/height no rompen los diseños fluidos. Atributos + height: auto es la combinación correcta, no un conflicto. Explico la mecánica completa del desplazamiento del diseño en mi artículo de CLS de Ahrefs; la versión corta es “reserva el espacio para que no haya desplazamiento” y deja que la imagen lo llene.

Implicaciones de la indexación móvil primero

Google indexa principalmente la versión móvil de tus páginas, por lo que dos reglas importan más que antes cuando sirves variantes responsivas:

• Mantén el texto alternativo idéntico en todos los puntos de interrupción. Las mejores prácticas de indexación móvil primero de Google dicen “make sure that the mobile site has the same alt text for images as the desktop site.” (traducción) «asegúrate de que el sitio móvil tenga el mismo texto alternativo para las imágenes que el sitio de escritorio». Un recorte móvil con dirección de arte no debe perder el contexto que Google necesita.
• Mantén las URLs de las imágenes estables. No uses URLs que cambien cada vez que la página carga para las imágenes. Esto encaja con la guía de SEO de imágenes de Google de referenciar consistentemente la imagen con la misma URL para que pueda almacenarla en caché y reutilizarla. Los CDN responsivos que generan una URL nueva por solicitud rompen esto — fija URLs estables para tus variantes.

El propio resumen de Google de por qué molestarse es claro: “diseñar páginas web responsivas conduce a una mejor experiencia de usuario, ya que las personas pueden acceder a ellas en una gran variedad de tipos de dispositivos.”

¿Y Bing?

No existe una guía específica de Bing sobre srcset, sizes o el elemento <picture> — la documentación pública de Bing no aborda el marcado de imágenes responsivas en absoluto. Así que no justifiques las imágenes responsivas con un gancho de algoritmo de Bing; el caso es el rendimiento y la UX, que Bing (como Google) trata como calidad de experiencia de página en lugar de algo que puedas señalar a una regla documentada de imágenes responsivas.

Errores comunes

• Olvidar sizes con descriptores w — el navegador asume 100vw y puede descargar tu archivo más grande para un espacio pequeño.
• Omitir el src de respaldo en <picture> — una violación de especificación que Google señala explícitamente, y es la URL que los rastreadores indexan.
• Proporción width/height desajustada vs. la imagen realmente servida — sigue causando desplazamiento.
• Carga diferida del hero LCP — retrasa el LCP sin razón; cárgalo de forma eager con fetchpriority="high".
• Regenerar URLs de imagen por solicitud — rompe el caché de Google y la regla de “URL estable” mobile-first.
• Recurrir a <picture> cuando srcset/sizes bastarían — complejidad innecesaria; web.dev dice que la mayoría de los sitios no lo necesitan.

Dónde encaja esto

Esta es la inmersión profunda en dimensionamiento y entrega bajo el hub más amplio de SEO de imágenes — la mitad de rendimiento del SEO de imágenes, en paralelo a cómo la guía de texto alternativo maneja la mitad de búsqueda de imágenes. Para los mecanismos completos de desplazamiento de diseño, consulta mi artículo de Ahrefs sobre CLS; para LCP, fetchpriority y la estrategia de carga, eso es trabajo de Core Web Vitals con sombrero de imagen.

Resumen de IA

Una versión condensada de la versión avanzada:

• Dos mecanismos, una familia. srcset/sizes en <img> = cambio de resolución (misma imagen, el navegador elige la mejor opción — una sugerencia). <picture> = dirección de arte o cambio de formato (recortes/formato dictados por el autor — un comando). La mayoría de los sitios solo necesitan srcset/sizes.
• Descriptores: los descriptores w (ancho) necesitan un atributo sizes y cubren imágenes fluidas de ancho de contenido; los descriptores x (densidad de píxeles) son adecuados para imágenes de UI de tamaño fijo y no necesitan sizes.
• sizes es obligatorio con descriptores w — omítelo y el navegador asume 100vw, a menudo descargando el archivo más grande innecesariamente. El error más común de srcset.
• No es una señal de clasificación directa. El marcado responsivo no cambia lo que Google indexa — Google indexa la URL src; las variantes son solo de entrega. Mantén el texto alternativo, los nombres de archivo y los datos estructurados en la imagen src principal.
• Beneficio de LCP: las imágenes sobredimensionadas son una causa principal de LCP lento; las imágenes responsivas son la solución recomendada de Lighthouse (auditoría “Properly size images”; falla con una brecha de 4KiB; RespImageLint ayuda a elegir srcset/sizes).
• CLS: srcset solo no hace nada contra el desplazamiento — establece atributos width/height (o CSS aspect-ratio), combinados con height: auto para diseños fluidos. Atributos + height: auto es la combinación correcta, no un conflicto.
• Nunca cargues de forma diferida la imagen LCP; cárgala de forma eager con fetchpriority="high", y mantén los intercambios responsivos nativos (Google no cargará contenido activado por interacción).
• Indexación mobile-first: mismo texto alternativo y URLs de imagen estables en todos los puntos de interrupción; no generes una URL nueva por solicitud.
• Bing: sin guía dedicada de imágenes responsivas — justifica el trabajo en rendimiento/UX.

Documentación oficial

Documentación de fuentes primarias y guía para desarrolladores.

Google — Búsqueda

• Google Images best practices — la nota de srcset, el requisito de src de respaldo en <picture>, la guía de misma URL y la justificación de diseño responsivo.
• Mobile-first indexing best practices — mismo texto alternativo y URLs de imagen estables en móvil y escritorio; no cargues de forma diferida el contenido principal en interacción.

Google — web.dev (guía para desarrolladores)

• Aprende: Imágenes responsive — srcset complementa a src; cómo funcionan sizes y las condiciones de medios.
• Aprende: El elemento picture — cuándo necesitas <picture>, dirección de arte y “sugerencias vs. comandos”.
• Optimiza el cambio de diseño acumulado — atributos width/height, relación de aspecto y height: auto para imágenes fluidas.
• API de prioridad de carga — fetchpriority="high" para la imagen LCP.

Chrome DevTools / Lighthouse

• Dimensiona correctamente las imágenes (uses-responsive-images) — la auditoría, el umbral de 4 KiB y el bookmarklet RespImageLint.

MDN

• Uso de imágenes responsive en HTML — la referencia para srcset, sizes, descriptores w/x y la sintaxis de <picture>.

Citas de la fuente

Declaraciones públicas de la documentación y las guías para desarrolladores de Google. Cuando una página expone el texto, el enlace es un enlace profundo que salta al pasaje citado.

Google — Documentación de SEO de imágenes

• “The srcset attribute allows specifying different versions of the same image, specifically for different screen sizes.” (traducción) «El atributo srcset permite especificar diferentes versiones de la misma imagen, específicamente para diferentes tamaños de pantalla.» Ir a la cita
• “Designing responsive web pages leads to better user experience, since people can access them across a plethora of device types.” (traducción) «Diseñar páginas web responsive conduce a una mejor experiencia de usuario, ya que las personas pueden acceder a ellas desde una gran variedad de tipos de dispositivos.» Fuente
• Sobre mantener URLs de imágenes estables: “consistently reference the image with the same URL, so that Google can cache and reuse the image.” (traducción) «referencia la imagen de manera consistente con la misma URL, para que Google pueda almacenarla en caché y reutilizarla.» Ir a la cita

Google — Documentación de indexación móvil primero

• “Make sure that the mobile site has the same alt text for images as the desktop site.” (traducción) «Asegúrate de que el sitio móvil tenga el mismo texto alternativo para las imágenes que el sitio de escritorio.» Ir a la cita
• “Don’t use URLs that change every time the page loads for images.” (traducción) «No uses URLs que cambien cada vez que la página se carga para las imágenes.» Ir a la cita

web.dev — srcset vs. picture

• “Where the srcset attribute gives suggestions to the browser, the picture element gives commands.” (traducción) «Mientras que el atributo srcset da sugerencias al navegador, el elemento picture da comandos.» Ir a la cita

Yo — sobre la corrección del CLS

• “Reserve the space so that there’s no shift” (traducción) «Reserva el espacio para que no haya desplazamiento»; la imagen simplemente lo llena. Ir a la cita

Patrones de imágenes responsive para copiar y pegar

Tres patrones que cubren casi todos los casos reales. Todos mantienen un src de respaldo, width/height explícitos (la corrección del CLS) y un texto alt idéntico.

1. Cambio de resolución: el <img srcset> de uso diario (mi patrón reutilizable)

<img
  src="puppy-1000.jpg"
  srcset="puppy-1000.jpg 1000w,
          puppy-2000.jpg 2000w,
          puppy-3000.jpg 3000w"
  sizes="(max-width: 600px) 480px, 1000px"
  width="1000" height="1000"
  alt="Puppy with balloons" />

Combínalo con este CSS para que la imagen se adapte de forma fluida sin provocar desplazamientos del diseño:

img {
  max-width: 100%;
  height: auto; /* with width/height attributes set, this prevents CLS */
}

2. Imagen de tamaño fijo — descriptores de densidad de píxeles (x), sin necesidad de sizes

<img
  src="logo.png"
  srcset="logo.png 1x, logo@2x.png 2x"
  width="200" height="60"
  alt="Company logo" />

3. El héroe LCP: carga inmediata + prioridad alta, y respaldo de formato mediante <picture>

<picture>
  <source type="image/avif" srcset="hero.avif">
  <source type="image/webp" srcset="hero.webp">
  <img
    src="hero.jpg"
    width="1200" height="675"
    fetchpriority="high"
    loading="eager"
    alt="Product hero shot" />
</picture>

Reglas integradas en estos patrones:

• Mantén siempre el <img src> final: es el respaldo y la URL que Google indexa.
• Con descriptores w, sizes es obligatorio; sin él, el navegador asume 100vw.
• Con descriptores x, omite sizes.
• Nunca añadas loading="lazy" a la imagen LCP (patrón 3): eso retrasa el LCP; usa fetchpriority="high" en su lugar.

Para encontrar los valores correctos de srcset/sizes en lugar de adivinar, ejecuta RespImageLint, el bookmarklet que recomienda Google, sobre la página en vivo.

¿Cuál necesitas realmente: srcset/sizes o picture?

Recorre la rama real que el artículo traza entre el cambio de resolución y la dirección de arte / cambio de formato.

La mayoría de los sitios se detienen en la primera rama y nunca salen de srcset/sizes: recurre a <picture> solo cuando la imagen en sí necesita cambiar, no solo su tamaño.

Qué no hacer

Seis errores concretos que el artículo señala, cada uno con el motivo por el que está mal y la solución.

• Olvidar el atributo sizes con descriptores w. Por qué está mal: sin sizes, el navegador asume que la imagen ocupa todo el ancho de la ventana (100vw), por lo que puede descargar tu candidato más grande para un espacio que se renderiza mucho más pequeño. En su lugar: siempre combina srcset con descriptores w con un valor de sizes que coincida con cómo se renderiza realmente la imagen en cada punto de interrupción.
• Omitir el <img src> de respaldo en <picture>. Por qué está mal: es una violación de la especificación que Google señala explícitamente, y es la URL que los rastreadores y Google Images indexan realmente — sin respaldo no hay imagen indexable. En su lugar: cada bloque <picture> termina con un <img src="..."> simple, nunca solo elementos <source>.
• Relación de width/height desajustada con la imagen realmente servida. Por qué está mal: los atributos establecen la relación de aspecto reservada; si la imagen real no coincide, el diseño aún se desplaza una vez que la imagen se carga. En su lugar: mantén la relación de width/height (o aspect-ratio) idéntica a los archivos de imagen que realmente estás sirviendo en todas las variantes de srcset/<picture>.
• Carga diferida de la imagen hero de LCP. Por qué está mal: loading="lazy" retrasa la descarga de exactamente la imagen que Largest Contentful Paint está midiendo, retrasando LCP sin beneficio. En su lugar: carga la imagen de LCP de forma eager con fetchpriority="high", nunca loading="lazy".
• Regenerar URLs de imagen en cada solicitud. Por qué está mal: rompe el caché de imágenes de Google y viola la regla de indexación móvil primero contra URLs que cambian cada vez que la página se carga. En su lugar: fija URLs estables y consistentes por variante de imagen para que Google pueda cachearlas y reutilizarlas.
• Usar <picture> cuando srcset/sizes serían suficientes. Por qué está mal: es complejidad innecesaria — web.dev es explícito en que la mayoría de los sitios no necesitan <picture> en absoluto. En su lugar: usa por defecto el cambio de resolución con srcset/sizes; solo añade <picture> cuando realmente necesites un recorte o formato diferente por condición.

Problemas comunes

Búsqueda por síntoma para los dos problemas de imágenes responsivas que los lectores realmente encuentran.

El diseño aún se desplaza (CLS) aunque srcset esté configurado

• Síntoma: Lighthouse o PageSpeed Insights aún reportan desplazamiento de diseño en una imagen, o puedes ver visualmente cómo el contenido salta mientras la imagen se carga, a pesar de tener un srcset/sizes funcional.
• Causa probable: srcset solo no hace nada contra el desplazamiento de diseño — solo decide qué archivo se carga, no cuánto espacio reservar. La imagen no tiene atributos width/ height (o CSS aspect-ratio), por lo que el navegador no puede asignar espacio hasta que el archivo comienza a descargarse y se conocen sus dimensiones.
• Solución + confirmación: Añade atributos explícitos width y height al <img> (o establece CSS aspect-ratio), y combínalos con height: auto en CSS para que la imagen siga escalando fluidamente. Confirma volviendo a ejecutar la verificación de CLS (Lighthouse o una verificación de CrUX en vivo) y observa si el desplazamiento desaparece — la caja reservada debería ahora mantener su tamaño antes de que la imagen termine de cargarse.

Lighthouse marca “Properly size images” / se está cargando una imagen sobredimensionada

• Síntoma: La auditoría de Lighthouse “Properly size images” enumera una o más imágenes con bytes desperdiciados, o una página tarda en alcanzar su Largest Contentful Paint incluso aunque la imagen en sí se vea bien.
• Causa probable: El tamaño renderizado de la imagen es al menos 4KiB menor que el archivo real que se está sirviendo — comúnmente porque no hay ningún srcset, o falta sizes por lo que el navegador usó 100vw por defecto y descargó el candidato más grande para un espacio pequeño.
• Solución + confirmación: Añade (o corrige) srcset con candidatos de tamaño adecuado y un valor de sizes que coincida con el ancho renderizado real; ejecuta RespImageLint para comprobar los valores en lugar de adivinar. Confirma volviendo a ejecutar la auditoría de Lighthouse “Properly size images” y comprobando que la imagen marcada ya no aparece (o que sus ahorros potenciales caen por debajo del umbral de 4KiB).

Hoja de referencia: descriptores, picture vs. srcset, y las reglas de CLS/LCP

Pruebas de validación

Comprobaciones de aprobado/fallo que confirman que un cambio de imagen responsive realmente surtió efecto.

Las imágenes con el tamaño correcto se envían correctamente

Prueba a ejecutar: Ejecuta la auditoría de Lighthouse “Properly size images” (Chrome DevTools > Lighthouse > Performance, o PageSpeed Insights) en la página que acabas de actualizar. Resultado esperado: La imagen que corregiste ya no aparece en la lista marcada de la auditoría, o sus ahorros potenciales caen por debajo del umbral de 4KiB. Interpretación del fallo: Si sigue marcada, o los candidatos de srcset siguen siendo demasiado grandes para el tamaño renderizado, o falta/está mal sizes y el navegador sigue usando 100vw por defecto. Ventana de monitoreo: Inmediata — vuelve a ejecutarla justo después de implementar el cambio. Disparador de reversión: La auditoría sigue marcando la misma imagen con ahorros potenciales sin cambios después de confirmar que sizes coincide con el ancho renderizado real.

Los valores de srcset/sizes son realmente óptimos

Prueba a ejecutar: Ejecuta RespImageLint (el marcador que recomienda Google) contra la página en vivo. Resultado esperado: Sin advertencias sobre candidatos sobredimensionados o un valor de sizes faltante/incorrecto. Interpretación del fallo: Una advertencia significa que o un candidato es innecesariamente grande para su punto de interrupción, o sizes no coincide con el ancho renderizado real del contenedor. Ventana de monitoreo: Inmediata, en la URL en vivo después del despliegue. Disparador de reversión: RespImageLint sigue marcando la misma imagen después de que hayas corregido el valor de sizes.

El navegador realmente seleccionó el candidato que esperabas

Prueba a ejecutar: Superar las comprobaciones de Lighthouse/RespImageLint confirma que tu marcado es válido; no confirma que el navegador haya elegido el archivo que pretendías en un viewport determinado. Carga la página en el punto de interrupción que te interese, abre DevTools, selecciona la <img> y comprueba su propiedad currentSrc en la consola ($0.currentSrc en Chrome/Firefox DevTools); el propio ejemplo de MDN hace exactamente esto: comparar currentSrc con el nombre de archivo esperado para confirmar qué candidato se cargó. Contrasta con la pestaña Network para ver qué archivo se solicitó realmente. Repite la prueba en tus puntos de interrupción estrechos y anchos, y a 1x y 2x de densidad de píxeles del dispositivo si lo emulas. Resultado esperado: currentSrc coincide con el archivo candidato que esperarías para ese ancho de viewport y densidad de píxeles, y la pestaña Network muestra que solo se obtuvo ese archivo. Interpretación del fallo: Si currentSrc devuelve un candidato más grande o más pequeño de lo esperado, o el valor de sizes no coincide con el ancho CSS real renderizado de la imagen (consulta “Por qué importa sizes” en la pestaña Advanced) o un descriptor de srcset es incorrecto. Ten en cuenta que la selección del navegador está definida por la implementación: el estándar HTML deja la elección exacta entre candidatos válidos al navegador (la densidad, el zoom y las condiciones de red pueden influir), así que no esperes un comportamiento idéntico byte a byte entre navegadores; busca un “candidato razonable”, no una respuesta fija. Ventana de monitoreo: Inmediata: comprueba cada punto de interrupción justo después de implementar. Disparador de reversión: currentSrc sigue devolviendo un candidato sobredimensionado en un viewport estrecho después de haber corregido sizes para que coincida con el ancho real renderizado.

Sin desplazamiento de diseño por la imagen

Prueba a ejecutar: Comprueba el Cumulative Layout Shift de la página: la puntuación CLS de Lighthouse o una comprobación en vivo de datos de campo de CrUX/PageSpeed Insights para la URL. Resultado esperado: El CLS atribuible a la imagen cae a (casi) cero una vez que se establecen width/height (o aspect-ratio). Interpretación del fallo: Un desplazamiento persistente suele significar que la proporción de width/height no coincide con la imagen real que se sirve, o que los atributos faltan por completo. Ventana de monitoreo: Los datos de laboratorio son inmediatos; los datos de campo (CrUX) necesitan unos 28 días para acumular una tendencia fiable. Disparador de reversión: El CLS en los datos de campo no mejora después de 28 días a pesar de que la comprobación de laboratorio pase: revisa si la proporción de la imagen servida coincide realmente con la caja reservada.

Ponte a prueba: Imágenes responsive

Cinco preguntas rápidas sobre srcset, sizes, <picture> y cómo afectan las imágenes responsive al SEO. Elige una respuesta para cada una y luego compruébalo.

Registro de cambios