La conclusión clave: WordPress genera automáticamente los atributos srcset y sizes en cada imagen desde la versión 4.4 — el problema en la mayoría de los sitios no es una función faltante, es un valor sizes incorrecto que le dice silenciosamente al navegador que descargue un archivo más grande de lo que el diseño realmente necesita. Corregir ese único atributo suele ser el cambio de imágenes responsivas con mayor impacto que puedes hacer.
Qué hacen realmente srcset y sizes
Una etiqueta <img> responsiva en WordPress se ve más o menos así:
<img src="image-1024x683.jpg"
srcset="image-300x200.jpg 300w, image-768x512.jpg 768w, image-1024x683.jpg 1024w"
sizes="(max-width: 600px) 100vw, 600px">
srcset enumera los candidatos de archivo disponibles y sus anchos reales en píxeles. sizes le indica al navegador cuán ancha se mostrará realmente la imagen en distintos anchos de viewport. El navegador combina ambos, junto con la densidad de pantalla del dispositivo, para elegir el archivo más pequeño que aún se vea nítido — antes de descargar nada.
Esta es la parte que vale la pena subrayar: el navegador es quien toma la decisión, no WordPress ni un plugin. Si sizes es preciso, el navegador toma automáticamente una buena decisión. Si sizes es incorrecto, el navegador toma una decisión segura, rápida e incorrecta — normalmente inclinándose por un archivo más grande "por si acaso".
Dónde falla la estimación por defecto de WordPress
WordPress calcula un valor sizes por defecto con una regla simple: asume que la imagen se muestra a su propio ancho intrínseco, hasta el ancho del viewport. Esa suposición es válida para una entrada de blog simple de una sola columna. Falla en muchos diseños comunes de WordPress:
- Diseños de cuadrícula y columnas — una cuadrícula de productos que muestra 3 imágenes por fila muestra cada imagen a aproximadamente un tercio del ancho del contenedor, no al ancho intrínseco completo de la imagen.
- Diseños de constructores de páginas — Elementor, Divi y constructores similares a menudo establecen anchos de contenedor mediante CSS, algo que el cálculo de
sizesdel lado PHP de WordPress no puede ver. - Temas con barra lateral — la columna de contenido real es más estrecha que el viewport, pero el cálculo por defecto no lo sabe.
En cada caso, se le dice al navegador "esta imagen se muestra cerca del ancho completo del viewport", así que descarga un candidato dimensionado para eso — aunque la imagen se renderice mucho más pequeña en pantalla.
Cómo comprobar si tu sitio tiene este problema
- Abre la página en Chrome, haz clic derecho en una imagen de contenido y elige Inspeccionar.
- En el panel Elements, busca el atributo
sizesen la etiqueta<img>. - Compáralo con el ancho realmente renderizado de la imagen — visible en el panel Computed como
width. - Si
sizesafirma algo cercano al ancho completo del viewport pero la imagen se renderiza, digamos, al 33% del contenedor, es muy probable que el navegador esté descargando un archivo de 2 a 3 veces más grande de lo necesario.
Una comprobación más rápida: abre la pestaña Network, filtra por Img, y compara las dimensiones en píxeles del archivo descargado (visibles en la pestaña Preview) con su tamaño CSS renderizado. Una gran diferencia entre ambos es la firma de un valor sizes roto.
Corregir el atributo sizes
Para la mayoría de los temas, esto significa sobrescribir el cálculo por defecto de WordPress con un valor que coincida con tu diseño real, usando el filtro wp_calculate_image_sizes:
add_filter('wp_calculate_image_sizes', function ($sizes, $size) {
return '(max-width: 768px) 100vw, (max-width: 1200px) 50vw, 33vw';
}, 10, 2);
Los puntos de ruptura exactos deben coincidir con el comportamiento real de tu cuadrícula CSS o contenedor del tema — este ejemplo asume un diseño que muestra una columna en móvil, dos en tablet y tres en escritorio. Revisa los puntos de ruptura reales en la hoja de estilos de tu tema en lugar de adivinarlos.
Registrar los tamaños de imagen correctos desde el principio
srcset solo puede ofrecer candidatos que realmente existan. Si tu tema solo registra un tamaño de miniatura de 1024px y otro de 300px, el navegador no tiene una opción de 600px para elegir en un viewport de tamaño medio — tiene que elegir la más cercana disponible, que a menudo sigue siendo demasiado grande. Registrar tamaños intermedios con add_image_size() le da al navegador opciones más granulares:
| Nombre del tamaño | Ancho | Uso típico |
|---|---|---|
| thumbnail | 150px | Listas de administración, tarjetas de artículos relacionados |
| medium | 600px | Ancho de contenido móvil |
| medium_large | 900px | Ancho de contenido tablet |
| large | 1200px | Ancho de contenido escritorio |
| full | Subida original | Rara vez es la opción correcta para servir directamente |
Registrar un tamaño no lo regenera para las imágenes ya subidas — los tamaños nuevos solo aplican de ahí en adelante, o tras ejecutar una herramienta de regeneración sobre los medios existentes.
Un ejemplo concreto
En una auditoría reciente de un blog de WordPress que usa una cuadrícula de artículos relacionados de 3 columnas, el atributo sizes por defecto afirmaba que cada miniatura se mostraba al 100vw (ancho completo del viewport) en todos los tamaños de pantalla. En realidad, cada miniatura se renderizaba a unos 320px en escritorio.
| Antes de corregir | Después de corregir | |
|---|---|---|
| Candidato elegido por el navegador | Archivo de 1024px de ancho | Archivo de 384px de ancho |
| Tamaño medio de archivo por miniatura | 145 KB | 38 KB |
| Peso total para una cuadrícula de 6 miniaturas | 870 KB | 228 KB |
Corregir un solo filtro sizes recortó unos 640 KB en esa única página — más de lo que la mayoría de los ajustes de compresión de imagen lograrían por sí solos, porque el problema no era la compresión, sino pedir un archivo cuatro veces más grande de lo que se mostraba.
Dónde sigue encajando la optimización de formato
Configurar bien srcset/sizes controla qué dimensiones se descargan. No controla el formato de esos archivos. Un JPEG de 384px correctamente dimensionado sigue siendo más grande de lo necesario si una versión WebP o AVIF de 384px pudiera verse idéntica con un tamaño de archivo menor. Aquí es donde Erdo Image Optimizer encaja como una corrección complementaria, no como un reemplazo: convierte automáticamente cada tamaño de imagen registrado — incluidos los candidatos srcset más pequeños que genera WordPress — a WebP y AVIF, de modo que la elección correctamente dimensionada del navegador también se sirva en el formato más pequeño utilizable.
Para más información sobre el lado del formato, consulta nuestra guía de conversión de imágenes de WordPress a WebP y nuestra checklist de PageSpeed Insights más amplia, que muestra dónde encajan las imágenes responsivas en el panorama de rendimiento general.
Para saber más
Para la especificación técnica completa de cómo evalúan los navegadores srcset y sizes, la guía de web.dev sobre imágenes responsivas es la referencia más fiable — cubre la selección basada en densidad, la dirección de arte con el elemento <picture> y casos límite que esta guía no trata.
Para terminar
Las imágenes responsivas en WordPress no están rotas por defecto — el mecanismo funciona automáticamente desde 2015. Lo que se rompe es el valor sizes en diseños más complejos que un blog de una columna, diciéndole silenciosamente a los navegadores que descarguen archivos dos o tres veces más grandes de lo que realmente se muestra. Revisa el atributo frente a tu diseño real antes de asumir que tus imágenes responsivas ya funcionan correctamente, y combina la corrección con la conversión de formato para obtener la ganancia completa.