Una foto de 72 píxeles que pesaba 2 MB: cómo saber si las imágenes de tu web pesan de más

Ayer pasamos una auditoría SEO a forjacms.com, nuestra propia web. Entre los avisos había uno incómodo: dos imágenes de casi 2 MB cada una. Una era la foto del autor que sale junto a cada artículo del blog, la que estás viendo en la columna de al lado. En pantalla mide 72 × 72 píxeles.

El original es un PNG de 1.087 × 1.446 píxeles y 1,96 MB. La versión que debería haberse descargado, un WebP de 400 píxeles de ancho, pesa 19 kB. Es unas cien veces menos para verse exactamente igual.

Lo contamos porque es el error de rendimiento más común que vemos en webs de pymes, y porque nos pasó a nosotros, con un sistema que sí genera las versiones pequeñas. Abajo tienes cómo detectarlo en tu web en dos minutos, por qué pasa y qué hay que exigir para que no pase.

No hace falta ninguna herramienta de pago. Con Chrome basta:

1. Abre tu web, pulsa F12 y ve a la pestaña Red (Network).
2. Filtra por Img y recarga la página.
3. Ordena por la columna Tamaño.

Cualquier imagen por encima de 200 kB merece una pregunta, y cualquiera por encima de 500 kB casi seguro es un error. Pasa el ratón por encima de la imagen en la página (clic derecho → Inspeccionar) y compara dos números: el tamaño al que se pinta y el tamaño real del fichero. Si se pinta a 300 píxeles y el fichero mide 2.000, el navegador está descargando más de cuarenta veces los píxeles que va a enseñar.

La otra vía es PageSpeed Insights: el aviso se llama «Mejora la entrega de imágenes» (antes, «Usa un tamaño adecuado para las imágenes») y te dice cuántos kB te ahorrarías en cada una.

Una imagen de 2 MB no solo tarda en aparecer ella. Compite por la conexión con todo lo demás: el CSS, las fuentes, la imagen principal. En un móvil con 4G normal, 2 MB son entre uno y dos segundos de descarga, y Google mide la velocidad con móviles así, no con tu fibra de la oficina.

Si la imagen pesada es la principal de la página (la del hero, la portada de un artículo), empeora directamente el LCP, la métrica de Core Web Vitals que mide cuándo se ve el contenido principal. Si está más abajo y lleva carga diferida (loading="lazy"), al menos no bloquea la carga inicial, pero sigue gastando datos de quien la visita. Ese era nuestro caso: no hundía la nota de PageSpeed, pero cada lector del blog se bajaba 2 MB para ver una cara del tamaño de un sello.

Lo hemos explicado más a fondo en por qué tu web va lenta. La versión corta: casi nunca es el hosting, casi siempre es lo que la página obliga a descargar.

La solución no es «subir las fotos más pequeñas». Una misma imagen se ve a 1.200 píxeles en un portátil y a 360 en un móvil, y la página no puede saber de antemano dónde la van a abrir.

Lo que hace una web bien construida es guardar varias versiones de cada imagen (por ejemplo, de 400, 800, 1.200 y 1.600 píxeles de ancho) y decirle al navegador dos cosas:

• srcset: qué versiones existen y cuánto mide cada una.
• sizes: a qué tamaño se va a pintar la imagen en esta página.

Con eso, el navegador elige solo la versión más pequeña que se vea nítida en esa pantalla, teniendo en cuenta incluso si es una pantalla de alta densidad (las de los móviles y los Mac). Nuestra foto de 72 píxeles, en un móvil con pantalla doble, necesita 144: el navegador coge la de 400 y se olvida del original.

Esa era exactamente nuestra avería: las versiones pequeñas existían, generadas al subir la foto, pero esa caja concreta pintaba la imagen sin srcset. Sin la lista, el navegador solo conoce el original y se baja el original. Era una línea de código, y ya está corregida.

El formato importa casi tanto como el tamaño. La regla práctica para una web de empresa:

Formato	Para qué	Comentario
WebP	Fotos e ilustraciones en la web	Entre un 25 % y un 35 % más ligero que JPEG con la misma calidad. Lo leen todos los navegadores actuales
AVIF	Fotos, cuando se pueda generar	Aún más ligero que WebP, pero más lento de generar y peor soportado por algunas herramientas
JPEG	Original y respaldo	Sigue siendo el formato universal; bien como fichero de partida
PNG	Logos, capturas con texto, transparencias	Nunca para fotos: una foto en PNG pesa varias veces lo que en JPEG
SVG	Iconos y logos vectoriales	Pesa casi nada, pero cuidado si lo sube cualquiera desde el panel

Nuestra foto tenía los dos problemas a la vez: era una fotografía guardada como PNG (de ahí los 1,96 MB para 1.087 píxeles) y se servía sin srcset. Cualquiera de los dos por separado ya habría salido caro.

En parte. Desde la versión 4.4, WordPress genera varios tamaños de cada imagen al subirla y añade srcset a las imágenes que insertas dentro del contenido de una entrada. Desde la 5.3 recorta también los originales gigantes a 2.560 píxeles. Es un buen punto de partida, y por eso el problema rara vez está en el texto de los artículos.

Está en todo lo demás:

• Los constructores visuales. Una imagen de fondo de sección en Elementor o Divi es una background-image de CSS, y ahí no hay srcset que valga: se sirve el tamaño que elijas en el editor, para todas las pantallas. Lo contamos en Elementor y el peso.
• Los temas y los campos personalizados. Muchos temas pintan el logo, la cabecera o la foto de un equipo con la URL del original. Un campo de ACF que devuelve «URL de la imagen» en lugar del objeto completo pierde las versiones pequeñas por el camino.
• El formato. WordPress acepta WebP desde la 5.8 y AVIF desde la 6.5, pero no convierte tus JPEG a WebP por defecto. Para eso hace falta un plugin (Imagify, ShortPixel, EWWW…), que suele ser de pago por volumen y es un plugin más que mantener.

El resultado es que una web WordPress puede tener el blog perfecto y la portada sirviendo cuatro fotos de 3 MB, y nadie se entera hasta que alguien abre la pestaña Red.

Por orden de esfuerzo:

1. Localiza las peores. Las cinco imágenes más pesadas de la portada y de tus páginas de servicio suelen ser el 80 % del problema.
2. Rehaz el fichero. Una foto no debería subirse a más de 2.000–2.500 píxeles de ancho, y nunca en PNG. Exportarla en JPEG de calidad 80 o en WebP ya baja el peso a una fracción.
3. Comprueba que se sirve con srcset. Inspecciona la imagen: si el <img> no lleva srcset ni está dentro de un <picture>, el navegador solo tiene el original. Esto es cosa del tema o del constructor, no de la foto.
4. Mira si es la imagen principal. La del hero no debe llevar carga diferida y conviene marcarla como prioritaria; las de más abajo, sí deben ir en diferido.

Si los pasos 3 y 4 te suenan a chino, es normal: no deberían depender de ti. Deberían venir resueltos en cómo está hecha la web.

En Forja, cada imagen que se sube desde el panel se guarda con un techo de 2.560 píxeles y se generan a su lado las versiones WebP de 400, 800, 1.200 y 1.600 píxeles. Se hace una vez, al subirla, no cada vez que se publica. Todas las imágenes de los bloques salen con su srcset y su sizes, y la principal de cada página se marca como prioritaria.

Lo que aprendimos ayer es que «todas» tiene que ser literal. Las tres excepciones —la foto del autor, las miniaturas de «Seguir leyendo» y las fotos de los testimonios— eran imágenes pequeñas, y precisamente por eso nadie miró cuánto pesaban. Ahora salen todas por el mismo camino.

Y una lección sobre auditorías: la segunda imagen de 2 MB que nos marcó la herramienta no era un problema. Iba dentro de un <picture> y el navegador se bajaba la versión de 17 kB; la herramienta solo había leído el fichero de respaldo. Antes de arreglar un aviso, conviene comprobar qué se descarga de verdad.