Mantys Core¿Por qué PageSpeed Insights sigue diciendo “Properly size images” si ya tengo un srcset?
Resumen en una frase: srcset le ofrece al navegador una lista de tamaños, pero es el atributo sizes el que le indica cuál elegir. Si sizes falta, es incorrecto o se ignora, el navegador descarga la imagen más grande de la lista, y PageSpeed lo marca, haya o no srcset.
Usted hizo todo lo que le indicaron. Sus imágenes tienen un srcset bien completo, con varios anchos generados, WebP (un formato de imagen de nueva generación, más ligero que JPEG o PNG). Y aun así, la auditoría de PageSpeed Insights sigue mostrando Properly size images, con varios cientos de KB señalados como ahorro potencial.
No se trata de un error de PageSpeed. Es un malentendido muy común sobre cómo funcionan realmente las imágenes responsivas. Aclarémoslo de una vez por todas.
Qué hace srcset y qué no hace
Veamos un caso típico:
<img
src="photo-1200.jpg"
srcset="photo-400.jpg 400w,
photo-800.jpg 800w,
photo-1200.jpg 1200w,
photo-2000.jpg 2000w">Mucha gente piensa que el navegador “elegirá la más adecuada”. En realidad, srcset por sí solo es solo un menú. Dice: aquí están los tamaños disponibles y su ancho real en píxeles. No dice nada sobre el espacio que la imagen ocupa en su página.
Sin información sobre el ancho de visualización, el navegador aplica un valor por defecto: sizes="100vw" (vw = ancho del viewport, el ancho de la ventana), lo que significa “asumir que la imagen ocupa todo el ancho de la ventana”. Y ahí es donde todo sale mal.
La causa real: el atributo sizes (y la trampa de la densidad de píxeles de pantalla)
El cálculo que hace el navegador es simple:
ancho de visualización (según sizes) × densidad de píxeles de la pantalla (el DPR, por Device Pixel Ratio) = ancho objetivo en píxeles → toma la primera imagen del srcset ≥ ese objetivo.
Veamos dos escenarios en un móvil de 400px de ancho con pantalla Retina (DPR = 2, lo habitual en móvil):
Escenario A: sizes ausente (por defecto 100vw)
Ancho asumido: 400px (100vw)
× DPR 2 = objetivo de 800px
Pero si su imagen en realidad solo mide 180px en pantalla (una miniatura en una cuadrícula), el navegador igualmente descarga la variante de 800w. 4× demasiado pesada.
Escenario B: sizes correcto
sizes="(max-width: 600px) 180px, 300px"Ancho real: 180px × DPR 2 = objetivo de 360px
El navegador toma la variante 400w. Peso dividido entre 4 y 5.
La conclusión que duele: un srcset sin un sizes correcto es casi inútil. El navegador, en caso de duda, toma algo demasiado grande, y PageSpeed lo detecta.
El DPR es el factor que todo el mundo olvida: en móvil, la mayoría de las pantallas tienen DPR 2 o 3. Una imagen mostrada a 200px físicos necesita una fuente de 400 a 600px. Eso no es desperdicio; más allá de eso, sí lo es.
El caso de WordPress: el sizes por defecto suele ser incorrecto (la causa #1 en la práctica)
Si usted usa WordPress, es muy probable que su problema venga de aquí, y no se trata de un sizes ausente, sino de un sizes automático e incorrecto.
WordPress genera el srcset y un sizes por su cuenta. Pero el valor que coloca por defecto tiene este aspecto:
sizes="(max-width: 1024px) 100vw, 1024px"En otras palabras: “esta imagen ocupa todo el ancho del contenido”. Eso es cierto para una imagen de artículo a ancho completo. Es incorrecto en cuanto la imagen vive en una cuadrícula, una columna, una barra lateral, una tarjeta, una galería, que es la mayoría de los casos. El resultado: sizes anuncia un ancho mucho mayor que el real, el navegador carga algo demasiado grande, y PageSpeed lo detecta.
Peor aún: muchos constructores de páginas (Divi, Elementor…) y los temas no ajustan este sizes a la columna real. Así que usted tiene un srcset impecable, variantes bien generadas… y un sizes que las sabotea. Es la causa más frecuente de la queja “Properly size images” en un sitio WordPress, y precisamente la que nunca se piensa en revisar porque “WordPress ya se encarga”.
Diagnostique en 30 segundos (sin adivinar)
Abra Chrome DevTools, vaya a la pestaña Elements, pase el cursor sobre la etiqueta <img>. Chrome muestra:
- Rendered size: el tamaño al que la imagen se muestra realmente.
- Rendered aspect ratio y Intrinsic size: el tamaño del archivo descargado.
- Current source: qué variante del srcset se eligió.
El veredicto es inmediato. Si ve un Rendered size de 180px pero el Current source es photo-800.jpg, su sizes falta o es incorrecto. Si el rendered size es 180px y el current source es photo-400.jpg, está en lo correcto: 400 = 180 × DPR 2, redondeado al siguiente escalón.
También puede usar la pestaña Network: ordene por tamaño, recargue y observe qué variante viaja por la red.
La solución genérica (lo que hace un desarrollador a mano)
a. Escriba un sizes que coincida con su maquetación real
Este es el corazón del problema. sizes debe reflejar el ancho real de la imagen, el que impone su CSS, en cada breakpoint (el ancho de pantalla en el que cambia la maquetación). Ejemplo para una imagen a ancho completo en móvil pero en 3 columnas en escritorio:
sizes="(max-width: 600px) 100vw,
(max-width: 1024px) 50vw,
33vw"b. Genere las variantes correctas
No tiene sentido tener una variante de 2000w si su imagen nunca supera los 600px en pantalla. Y a la inversa: proporcione los escalones que cubran sus anchos reales × DPR (hasta 2, a veces 3).
c. No olvide width ni height
No cambian el peso, pero evitan el CLS (Cumulative Layout Shift, contenido que salta mientras carga), la otra queja recurrente de PageSpeed.
El caso en el que incluso un sizes perfecto no basta
Algunos elementos no llevan ningún srcset en absoluto: sliders (Nivo, Swiper, muchos temas), imágenes de fondo CSS, o cualquier marcado que genere un <img src="...">. Ahí, no hay literalmente nada que reescribir: ningún plugin de optimización puede actuar, porque no hay srcset/sizes que corregir. Es un problema aparte (imágenes sin srcset), que exige un enfoque distinto al descrito aquí.
Por qué es tan doloroso mantener esto a mano
Escribir el sizes correcto exige saber, para cada imagen y cada breakpoint, el ancho real de visualización en CSS. En un sitio vitrina de 5 páginas, es factible. En un sitio con decenas de plantillas, cuadrículas que cambian, contenido editorial… es inmanejable, y se desincroniza con cada rediseño.
Este es exactamente el problema que Mantys Core resuelve midiendo en lugar de adivinar:
renderiza la página como un navegador real y mide el ancho realmente mostrado de cada imagen, en cada breakpoint;
reescribe el
sizesa partir de esa medición: se acabó el100vwpor defecto, se acabó la descarga excesiva;genera las variantes útiles (y su versión WebP) alineadas con esos anchos reales;
y, para las imágenes sin
srcset(sliders, fuentes en bruto), aplica una sustitución hacia la variante medida, el caso que las herramientas clásicas dejan de lado.
El resultado concreto: la queja “Properly size images” desaparece porque el navegador finalmente descarga el tamaño correcto, el que su maquetación realmente pide.
En resumen
srcset= un menú de tamaños. sizes = la instrucción de elección. Sin el segundo, el primero es casi inútil.- El DPR móvil (×2, ×3) duplica o triplica el ancho objetivo, de ahí la descarga excesiva.
- Diagnostique con Rendered size frente a Current source en las DevTools.
- La solución = un
sizesfiel a su maquetación real + las variantes correctas. A mano es tedioso y frágil; medido y automatizado, es fiable.