Entiende srcset, sizes, los descriptores de anchura y densidad, picture, la dirección artística y cómo el navegador elige la imagen responsive adecuada.
Publicado el 31 de agosto de 2026Lectura : 18 minPor Bethemesh Team
Las imágenes responsive resuelven un problema sencillo en apariencia, pero con mecanismos bastante sutiles: un mismo contenido visual puede mostrarse con tamaños y densidades de píxeles muy diferentes. Enviar siempre un archivo enorme desperdicia datos; enviar siempre uno pequeño puede producir una imagen borrosa.
HTML permite que el navegador negocie el recurso adecuado mediante srcset, sizes y, cuando hace falta, <picture>. La clave consiste en describir correctamente el diseño real y ofrecer variantes bien preparadas para que el navegador pueda elegir.
Una imagen fluida no es necesariamente una imagen responsive
Una regla como max-width: 100% permite que la imagen se adapte visualmente a su contenedor. Sin embargo, el navegador puede seguir descargando exactamente el mismo archivo grande en un móvil y en un monitor de escritorio.
Las imágenes responsive añaden una segunda dimensión: la selección del recurso. En lugar de ofrecer un único archivo, declaramos varios candidatos y dejamos que el navegador elija el más apropiado según el espacio de visualización y la densidad de la pantalla.
¿Por qué no enviar la imagen más grande a todo el mundo?
Porque es sencillo, pero costoso. Un teléfono que muestra una imagen con unos pocos cientos de píxeles CSS puede terminar descargando millones de píxeles que nunca va a utilizar.
Eso afecta al ancho de banda, al tiempo de descarga, a la memoria necesaria para decodificar la imagen y, en muchos casos, a métricas de rendimiento como el Largest Contentful Paint.
¿Y por qué no enviar siempre la más pequeña?
Porque esa misma imagen puede mostrarse mucho más grande en escritorio o en una pantalla de alta densidad. Si el recurso de origen es demasiado pequeño, el navegador tendrá que ampliarlo y el resultado puede perder nitidez.
El objetivo no es encontrar el archivo más pequeño en términos absolutos, sino el archivo con una resolución suficiente para el uso real.
Preparar las variantes antes de escribir srcset
Las variantes deben generarse a partir de un original de buena calidad. No tiene sentido crear una versión de 1200 píxeles ampliando una derivada de 600 píxeles: aumentar las dimensiones no recupera el detalle perdido.
No existe un número universal. Necesitas suficientes anchuras para evitar saltos enormes entre candidatos, pero no decenas de archivos casi idénticos.
Una serie típica podría ser 480, 768, 1024, 1280 y 1600 píxeles. Debe adaptarse a las dimensiones reales de tus componentes, al tamaño del original y a los dispositivos que quieres cubrir.
src sigue siendo importante
Aunque utilices srcset, el atributo src del elemento <img> sigue teniendo sentido. Sirve como fallback y también puede formar parte del comportamiento de selección del navegador.
Elige un recurso razonable. No apuntes automáticamente al original de máxima resolución.
Descriptores de anchura: w
Con los descriptores w, cada candidato declara su anchura intrínseca real en píxeles:
480w significa que el archivo correspondiente tiene 480 píxeles de ancho. No es un breakpoint ni una media query.
Los valores declarados deben coincidir con las dimensiones reales de los archivos. Si declaras 800w para una imagen que en realidad mide 640 píxeles, estás proporcionando información falsa al algoritmo de selección.
¿Para qué sirve sizes?
Cuando se utilizan descriptores w, el navegador necesita estimar cuánto espacio ocupará la imagen en el diseño antes de que todo el layout esté completamente calculado.
sizes describe ese slot de visualización. El navegador combina esa información con la densidad de píxeles del dispositivo y con los candidatos declarados en srcset para seleccionar un archivo apropiado.
Entender vw
100vw representa aproximadamente el ancho completo del viewport. No significa que el archivo tenga 100 píxeles ni que la imagen vaya a ocupar necesariamente toda la pantalla después de aplicar el CSS.
Este detalle es fundamental: el viewport y el contenedor de la imagen no siempre tienen el mismo ancho.
Cuándo puede servir sizes="100vw"
Para una imagen hero que realmente ocupa todo el ancho en móvil, 100vw puede ser una aproximación correcta.
Pero si una imagen de artículo está limitada a un contenedor de 720 píxeles en escritorio, mantener 100vw en todos los tamaños de pantalla puede hacer creer al navegador que necesita un archivo mucho más grande de lo necesario.
El navegador elige
srcset no es una lista de instrucciones rígidas del tipo «en este breakpoint descarga este archivo». Es un conjunto de candidatos.
El navegador conserva la decisión final y puede tener en cuenta la densidad de píxeles, los recursos ya presentes en caché y otros criterios de implementación.
Por eso es mejor describir correctamente el problema que intentar controlar cada descarga de forma manual.
Imagen limitada por un contenedor
Imagina que el cuerpo de un artículo utiliza un ancho equivalente a min(100% - 2rem, 720px).
En pantallas pequeñas, la imagen ocupará casi todo el viewport menos los márgenes. En escritorio, dejará de crecer alrededor de 720 píxeles. sizes debería comunicar ese comportamiento real.
No es necesario copiar literalmente los breakpoints del CSS; lo importante es representar de forma suficientemente precisa el ancho que tendrá la imagen.
El orden de las condiciones de sizes
Las condiciones se evalúan de izquierda a derecha. El navegador utiliza la primera que coincide y el último valor funciona como fallback.
Por tanto, coloca primero las condiciones específicas y termina con el tamaño por defecto.
¿Tiene que reproducir sizes exactamente el CSS?
No. Debe aproximar suficientemente bien la anchura renderizada para que el navegador pueda tomar una buena decisión.
Una expresión ligeramente simplificada pero mantenible suele ser mejor que una fórmula extremadamente compleja que nadie actualizará cuando cambie el diseño.
El problema aparece cuando la estimación es sistemáticamente demasiado grande: entonces se descargan archivos innecesariamente pesados.
Ejemplo de una cuadrícula
Una cuadrícula puede mostrar una tarjeta a ancho completo en móvil, dos columnas en tablet y tres columnas en escritorio.
En ese caso, cada imagen no ocupa 100vw en escritorio: ocupa aproximadamente un tercio del contenedor, descontando los espacios entre columnas.
Declarar 100vw para todas las tarjetas puede anular gran parte de la optimización.
Un sizes incorrecto puede arruinar el trabajo
Puedes tener imágenes perfectamente comprimidas, formatos modernos y una buena lista de candidatos. Si una tarjeta de 320 píxeles declara que ocupa todo un monitor de 1440 píxeles, el navegador puede seleccionar un recurso mucho mayor de lo necesario.
La optimización responsive depende tanto de los archivos como de la descripción correcta del layout.
Descriptores de densidad: x
Cuando el tamaño CSS de la imagen es fijo o muy predecible, los descriptores de densidad pueden resultar más sencillos:
2x indica un recurso pensado aproximadamente para dos píxeles de origen por cada píxel CSS.
¿Cuándo utilizar x?
Los descriptores de densidad funcionan bien para avatares, iconos o recursos cuyo tamaño visual cambia poco.
Para fotografías y contenidos fluidos que pueden ocupar anchuras muy diferentes, w combinado con sizes suele describir mejor la situación.
No mezcles w y x en el mismo srcset
Elige un modelo de descriptores para cada conjunto de candidatos.
Con w, el navegador ya puede incorporar la densidad del dispositivo al relacionar el ancho del slot con las anchuras intrínsecas disponibles.
¿Cómo funciona la selección con w?
De forma conceptual, el navegador:
estima el ancho de visualización mediante sizes;
tiene en cuenta la densidad de la pantalla;
compara esa necesidad con las anchuras declaradas;
selecciona uno de los candidatos disponibles.
Los detalles exactos pertenecen al navegador y pueden incluir heurísticas adicionales.
¿Por qué un slot de 400 px puede descargar una imagen de 800 px?
Porque en una pantalla con DPR 2, una imagen mostrada a 400 píxeles CSS puede necesitar aproximadamente 800 píxeles físicos de origen para conservar una buena nitidez.
Por eso comparar únicamente el ancho CSS con el ancho del archivo puede llevar a conclusiones erróneas.
¿Hace falta cubrir exactamente todos los DPR?
No. La calidad visual y el coste de red deben equilibrarse.
Una fotografía puede seguir viéndose perfectamente con una densidad algo inferior a la teórica. No necesitas crear una variante para cada combinación posible de anchura y DPR.
Resolución, compresión y formato siguen importando
El HTML responsive no puede corregir derivados mal preparados.
Debes redimensionar correctamente, comprimir con criterio y elegir formatos adecuados. Consulta también Comparación de formatos de imagen.
¿Para qué sirve <picture>?
<picture> permite declarar varios elementos <source> antes de un <img> final.
Es especialmente útil para dos necesidades distintas:
ofrecer formatos alternativos;
realizar dirección artística.
No necesitas <picture> simplemente para utilizar srcset.
<picture> para formatos alternativos
Puedes ofrecer AVIF, después WebP y finalmente un formato de fallback.
Cada <source> puede contener su propio srcset. El navegador determina primero qué fuente puede utilizar y después selecciona el candidato apropiado dentro de ella.
<picture> para dirección artística
La dirección artística consiste en proporcionar una composición realmente distinta según el contexto.
Por ejemplo, una fotografía panorámica para escritorio puede sustituirse en móvil por un recorte vertical que mantenga visible al sujeto principal.
No se trata únicamente de reducir el archivo: cambia el encuadre.
Cambio de resolución frente a dirección artística
El cambio de resolución mantiene el mismo contenido visual y modifica principalmente el número de píxeles.
La dirección artística modifica el encuadre, la composición o incluso la ilustración. Conviene mantener ambos objetivos separados mentalmente y en el código.
No utilices <picture> para controlar cada dispositivo
Las imágenes responsive están diseñadas precisamente para que el navegador pueda elegir.
Crear una fuente específica para cada teléfono o resolución conocida produce un marcado frágil, difícil de mantener y rápidamente obsoleto.
El <img> final es imprescindible
Dentro de <picture>, el elemento <img> final sigue siendo esencial.
Aporta el fallback, el texto alternativo, las dimensiones intrínsecas, los atributos de carga y el elemento semántico que representa la imagen.
Los elementos <source> no sustituyen esa función.
Texto alternativo
Las variantes responsive que transmiten la misma información comparten el atributo alt del <img> final.
No pongas alt en <source>.
Si los diferentes recortes cambian tanto el contenido que necesitarían textos alternativos contradictorios, probablemente las variantes ya no sean semánticamente equivalentes.
Conserva width y height
Declarar las dimensiones intrínsecas ayuda al navegador a reservar espacio antes de descargar la imagen y reduce los cambios de layout.
Si todos los candidatos comparten la misma relación de aspecto, utiliza dimensiones coherentes con esa proporción. El CSS puede seguir escalando la imagen.
Genera cada anchura desde el original o desde una fuente de calidad suficiente.
Evita encadenar varias recomprasiones con pérdida. Una imagen JPEG exportada, redimensionada, vuelta a exportar y recomprimida repetidamente acumula degradación.
Nombres de archivo previsibles
Puedes utilizar nombres como:
hero-480.webphero-800.webphero-1200.webp
o dejar que tu pipeline de build genere nombres con hash.
En ambos casos, el descriptor del HTML debe corresponder a la anchura intrínseca real.
¿Qué candidato utilizar en src?
Escoge una variante intermedia razonable que funcione cuando srcset no se tenga en cuenta.
No conviertas automáticamente el original de máxima resolución en el fallback.
Imágenes hero y LCP
Una imagen hero suele convertirse en el Largest Contentful Paint de la página.
Si es el elemento LCP, normalmente no debe utilizar loading="lazy". Debe poder descubrirse pronto, tener un marcado responsive correcto y, en casos justificados, puede beneficiarse de fetchpriority="high".
No marques muchas imágenes como prioritarias: si todo es prioritario, nada lo es.
Lazy loading
loading="lazy" es útil para imágenes situadas por debajo del primer viewport.
No es una estrategia de selección de resolución y no sustituye a srcset. Lazy loading y responsive images resuelven problemas distintos.
decoding y fetchpriority
decoding="async" puede ser apropiado para muchas imágenes no críticas.
fetchpriority proporciona una indicación sobre la prioridad de red, pero no corrige un sizes erróneo ni un recurso sobredimensionado.
Por qué DevTools puede sorprenderte
Los navegadores reutilizan recursos en caché. Si ya han descargado una variante grande, reducir la ventana no significa necesariamente que vuelvan a descargar una versión pequeña.
Por eso una prueba realizada únicamente redimensionando el viewport puede parecer incoherente.
Utiliza recargas limpias y revisa currentSrc.
Utiliza currentSrc
La propiedad img.currentSrc permite saber qué recurso ha seleccionado realmente el navegador.
Combínala con:
el ancho renderizado;
el ancho intrínseco;
el DPR;
el tamaño transferido en Network.
Así podrás comprobar si sizes representa correctamente el layout.
Prueba varias anchuras y densidades
Una configuración responsive debe verificarse en varios escenarios:
móvil estrecho;
móvil grande;
tablet;
escritorio;
diferentes densidades de píxeles.
Comprueba tanto la nitidez como los bytes transferidos.
El problema de la explosión combinatoria
Cinco anchuras multiplicadas por tres formatos y varios recortes pueden generar decenas de archivos para una sola imagen.
La automatización facilita el proceso, pero no elimina el coste de almacenamiento, build y mantenimiento.
Genera únicamente las combinaciones que aporten un beneficio real.
CDN de imágenes y pipelines automáticos
Una CDN de imágenes puede crear variantes de anchura y formato bajo demanda.
Un sitio estático puede generarlas durante el build.
Ambos enfoques son válidos si conservan un original fiable y reglas de transformación deterministas.
¿Puede el navegador elegir según el ancho de banda?
Los navegadores pueden utilizar heurísticas e información del entorno, pero no conviene diseñar la estrategia suponiendo una promesa exacta basada en la velocidad de conexión.
Tu responsabilidad es ofrecer candidatos sensatos y una descripción precisa del slot.
¿srcset garantiza el archivo con menos bytes?
No.
La selección se basa principalmente en la adecuación del candidato, no en comparar el peso de todos los archivos disponibles.
Dos imágenes de 800 píxeles pueden pesar cantidades muy diferentes según su contenido, formato y nivel de compresión.
¿Por qué puede mantenerse una variante grande al reducir la ventana?
Una vez descargada una imagen de alta resolución, el navegador suele preferir reutilizarla en lugar de descargar otra más pequeña para ahorrar bytes que ya se han transferido.
Cuando analices el algoritmo de selección, prueba desde una carga en frío.
Imágenes responsive y SEO
La entrega responsive puede mejorar el rendimiento sin ocultar el significado de la imagen.
Mantén:
un alt pertinente;
HTML correcto;
recursos accesibles para los rastreadores;
URLs estables cuando corresponda;
dimensiones coherentes.
Las mejoras de rendimiento contribuyen a la calidad global de la página, pero las imágenes responsive no son un truco SEO por sí mismas.
Imágenes responsive y accesibilidad
Todos los candidatos deberían transmitir información equivalente, salvo que la dirección artística adapte deliberadamente el encuadre.
Asegúrate de que un recorte móvil no elimine una parte esencial de un diagrama, una captura de pantalla o una fotografía informativa.
SVG y comportamiento responsive
Un SVG vectorial puro suele necesitar una única fuente porque puede escalar sin depender de una resolución raster fija.
En ese caso, un viewBox correcto y el CSS de dimensionado suelen ser más importantes que srcset.
Al generar variantes puedes copiar EXIF, GPS u otros metadatos en todos los derivados.
Define una política de metadatos para los archivos públicos y aplícala de forma consistente. Consulta Metadatos de imagen y privacidad.
Caso práctico: hero a ancho completo
Para una hero responsive:
genera varias anchuras grandes;
utiliza descriptores w;
escribe sizes según el espacio real;
evita lazy loading si es el LCP;
declara las dimensiones;
prueba el resultado con una conexión limitada.
Caso práctico: imagen de artículo
Si la columna del artículo está limitada a unos 720 píxeles, crea candidatos adaptados a móviles y a ese ancho de columna.
Una variante de 1440 píxeles puede seguir siendo útil para pantallas de alta densidad, pero no debería descargarse por defecto en todos los escritorios.
Caso práctico: tarjetas de una cuadrícula
Describe el ancho de cada tarjeta en cada breakpoint.
El error más habitual consiste en declarar el ancho del viewport cuando en realidad dos o tres tarjetas comparten la misma fila.
Caso práctico: avatar fijo
Un avatar de 64 × 64 píxeles es un buen candidato para 1x y 2x.
Los descriptores w aportan menos valor cuando el slot CSS es prácticamente fijo.
Caso práctico: recorte móvil
Utiliza <picture> y condiciones media para proporcionar un recorte diferente cuando la composición lo requiera.
No lo hagas simplemente para entregar una copia más pequeña de la misma imagen: para eso ya existe srcset.
Caso práctico: AVIF + WebP + varias anchuras
Cada fuente de formato puede declarar la misma escala de anchuras.
El navegador identifica primero un formato compatible y después selecciona el candidato adecuado.
Conserva siempre el <img> final como fallback.
¿Cómo elegir las anchuras de los candidatos?
Parte de los tamaños reales de visualización y de los rangos de densidad útiles.
Evita crear variantes tan próximas entre sí que rara vez cambien la decisión del navegador.
También conviene medir su peso. Si 640w pesa 55 KB y 720w pesa 58 KB, conservar ambas puede aportar poco. Si el salto siguiente es 1200w y 160 KB, una anchura intermedia puede tener mucho más sentido.
No amplíes por encima del original
Crear una variante de 2400 píxeles desde una fuente de 1200 píxeles no añade detalle.
Detén la escala en la resolución útil del original, salvo que dispongas de un master de mayor resolución.
¿Por qué una imagen puede seguir viéndose borrosa?
Hay varias causas posibles:
el candidato seleccionado es demasiado pequeño para el slot y el DPR;
el original ya carece de detalle;
el CSS amplía la imagen;
la compresión ha eliminado demasiado detalle.
Comprueba currentSrc, las dimensiones naturales y el tamaño renderizado antes de culpar a srcset.
¿Por qué una página puede seguir siendo pesada?
Las causas habituales incluyen:
sizes demasiado optimista;
demasiadas imágenes visibles al cargar;
candidatos máximos excesivos;
calidad de compresión demasiado alta;
formatos poco eficientes;
recursos decorativos innecesarios.
El marcado responsive forma parte de un sistema de optimización más amplio.
Escribir sizes a partir del layout, paso a paso
Una forma fiable de construir sizes consiste en ignorar al principio los nombres de los archivos y observar únicamente el CSS.
Pregúntate cuánto mide realmente el slot en cada rango de viewport.
Si un artículo móvil ocupa casi todo el ancho menos 32 píxeles de padding, una estimación puede ser calc(100vw - 32px). Si en escritorio la columna deja de crecer a 720 píxeles, el valor final puede ser 720px.
Para una cuadrícula, calcula el ancho de la tarjeta y no el de la página. Si dos tarjetas comparten un contenedor de 900 píxeles con un gap de 24 píxeles, cada imagen ronda los 438 píxeles, no los 900.
No necesitas reproducir cada cálculo del layout con precisión matemática. Una aproximación estable y fácil de mantener suele ser suficiente.
Cuando cambie el diseño, revisa también sizes. Una declaración correcta para dos columnas puede quedar sobredimensionada cuando el componente pasa a tres.
Diseñar la escala de candidatos pensando en los bytes
El navegador no selecciona comparando el peso de cada candidato, pero tú sí deberías analizar ese peso al diseñar la escala.
Mide fotografías, capturas e ilustraciones representativas. El tamaño de archivo no crece de forma perfectamente proporcional al número de píxeles.
También recuerda que formato y anchura interactúan. AVIF, WebP y JPEG de la misma resolución pueden tener costes muy distintos.
Si mantienes varias familias de formatos, ajusta la calidad de cada una en lugar de aplicar ciegamente un único preset.
Dirección artística sin perder significado
Un recorte móvil debe conservar la información que hacía útil a la imagen original.
Si una fotografía de escritorio muestra a una persona utilizando un producto y el recorte móvil conserva únicamente su rostro, el significado puede haber cambiado.
La dirección artística no es solo una optimización técnica: es una decisión editorial.
Para imágenes decorativas existe más libertad. Para diagramas, capturas o fotografías que sirven como evidencia, conserva la información esencial o replantea la presentación móvil.
Depurar una imagen responsive que parece incorrecta
Empieza comprobando:
currentSrc;
el ancho CSS renderizado;
naturalWidth;
el DPR del dispositivo.
Si el ancho natural es mucho menor que el ancho renderizado multiplicado por el DPR, la falta de nitidez es esperable.
Después revisa sizes. El navegador puede estar seleccionando exactamente lo que le has pedido, aunque no sea lo que pretendías.
Comprueba la condición activa y recuerda que el orden importa.
A continuación, prueba con caché fría. Finalmente, verifica que cada descriptor w coincide con la anchura real del archivo.
Mantener las imágenes responsive a largo plazo
Trata la configuración responsive como parte de la API del componente.
Cuando tu framework lo permita, centraliza las escalas de anchura y patrones sizes habituales. Documenta qué componentes son:
full width;
limitados por contenedor;
basados en cuadrícula;
de tamaño fijo.
Los tests automáticos pueden verificar que los candidatos generados existen y que sus anchuras declaradas coinciden con sus metadatos.
El objetivo no es crear el srcset más sofisticado posible, sino ofrecer al navegador un conjunto pequeño, fiable y coherente con el layout real.
Errores frecuentes
Evita especialmente estos errores:
confundir el ancho del viewport con el del contenedor;
utilizar x para imágenes muy fluidas;
declarar valores w que no coinciden con los archivos;
utilizar sizes como si fuera una media query de descarga;
mezclar w y x en el mismo conjunto;
olvidar el <img> final dentro de <picture>;
colocar alt en <source>;
aplicar lazy loading a la imagen LCP;
generar variantes ampliando derivados pequeños;
mantener sizes="100vw" para imágenes que en escritorio ocupan solo una fracción del viewport.
Checklist antes de publicar
Antes de poner una implementación responsive en producción:
verifica la anchura real de cada candidato;
comprueba que todos mantienen la relación de aspecto prevista;
Después escribe srcset y sizes a partir de las dimensiones que realmente has generado y del layout que realmente utiliza tu página.
Lo que debes recordar
srcset proporciona candidatos. sizes describe el espacio de visualización cuando utilizas descriptores de anchura. El navegador toma la decisión final.
Utiliza:
w para imágenes fluidas;
x para recursos de tamaño fijo o predecible;
<picture> para formatos alternativos o dirección artística.
Y recuerda que una buena estrategia responsive no depende únicamente del HTML: necesita originales correctos, redimensionado, compresión, formatos adecuados y pruebas en condiciones reales.
Preguntas frecuentes
¿Basta con srcset sin sizes?
Con descriptores w, omitir sizes conduce a una estimación basada en el viewport que puede ser incorrecta para imágenes limitadas por un contenedor.
¿Puedo mezclar w y x?
No dentro del mismo conjunto de candidatos.
¿Necesito <picture> para utilizar WebP?
Puede ser útil para ofrecer formatos alternativos, aunque la política de compatibilidad de tu proyecto puede permitir soluciones más simples.
¿Debo aplicar lazy loading a la hero?
Normalmente no si es la imagen LCP.
¿Cómo sé qué archivo ha cargado el navegador?
Comprueba currentSrc y el panel Network de las herramientas de desarrollo.
¿Tengo que crear una variante para cada breakpoint CSS?
No. Las anchuras deben responder a los tamaños reales del slot y a diferencias útiles de resolución, no a una copia mecánica de todos los breakpoints.
¿Es obligatorio utilizar <picture> con srcset?
No. Un <img> con srcset y sizes es suficiente para la mayoría de los casos de cambio de resolución.
¿Una imagen responsive mejora automáticamente Core Web Vitals?
No automáticamente. Puede reducir transferencias innecesarias y ayudar al LCP, pero un sizes incorrecto, una mala compresión o una prioridad de carga inadecuada pueden seguir perjudicando el rendimiento.
Comprende rastreo, indexación, canonical, metadatos, datos estructurados, rendimiento y enlazado interno sin confundir optimización con posicionamiento.
