Puntos clave
- Servir la imagen al tamaño en que se muestra es lo que más ahorra, y por mucho.
- El ancho de más se paga al cuadrado: el doble de ancho pesa el cuádruple.
- AVIF y WebP pesan entre un 30 y un 70 % menos que PNG o JPG para el mismo resultado.
- loading=lazy no ahorra peso: ahorra espera, que es lo que mide el usuario.
- Toda imagen necesita width y height declarados, o la página salta mientras carga.
Y a diferencia de otras optimizaciones, esta se nota: es de las pocas cosas que mejoran la experiencia y el SEO por el mismo motivo.
Las 4 decisiones, por cuánto ahorran
La primera explica casi todo, y es la que menos se hace.
1. El tamaño: el ancho de más se paga al cuadrado
Una foto de 4000 px de ancho mostrada en un hueco de 600 px no pesa un poco de más: pesa muchísimo de más, porque el área crece con el cuadrado del ancho.
La misma foto, a distintos anchos
La regla práctica: el doble del ancho en que se muestra. Ese doble cubre las pantallas densas y no se nota la diferencia con un archivo más grande.
Para huecos que cambian de ancho según el dispositivo, srcset deja que el navegador elija. Vale la pena solo cuando la diferencia entre el móvil y el escritorio es grande.
2. El formato: cuál para qué
No hay un formato mejor: hay uno mejor para cada tipo de contenido.
Qué usar
- AVIF para todo, con WebP de respaldo
- SVG para logos, íconos y diagramas de líneas
- PNG solo cuando hace falta transparencia sin pérdida
- Un <picture> con varias fuentes si necesitás respaldo
Qué evitar
- PNG para fotografías: es el peor caso posible
- JPG para capturas de pantalla con texto: lo emborrona
- GIF para animaciones: un video pesa mucho menos
- Un formato único para todo el sitio
Los dos casos extremos que más se equivocan:
PNG para fotos. El PNG guarda cada píxel exacto. En una fotografía eso significa guardar el ruido del sensor, que no aporta nada visible y pesa mucho.
JPG para capturas con texto. El JPG comprime suavizando, y el texto suavizado se ve sucio. Para capturas de pantalla conviene PNG, WebP o AVIF.
Los dibujos de colores planos —diagramas, esquemas, gráficos— son el caso donde el cambio de formato rinde más: el mismo archivo puede pesar un tercio en AVIF.
3. La calidad: dónde está el punto de no retorno
Por encima de 85 se paga peso que casi nadie ve.
Un valor entre 75 y 85 suele ser indistinguible del original a simple vista y pesa entre un tercio y la mitad. Para AVIF los números son otros: alrededor de 60 ya da un resultado muy bueno.
Lo importante es no comprimir dos veces. Guardar un JPG al 80, abrirlo y volver a guardarlo al 80 no da 80: da 64, y se nota.
4. Cuándo se carga
loading="lazy" no reduce el peso total: reduce lo que hay que esperar para ver la primera pantalla, que es lo que la persona percibe y lo que mide el LCP.
Dos reglas que se contradicen y hay que respetar las dos:
A lo que no se ve al entrar, loading="lazy". Todo lo que está más abajo.
A la imagen principal, nunca. Si la imagen grande de arriba se carga de forma diferida, el LCP empeora en lugar de mejorar. Esa lleva loading="eager" y, si se puede, fetchpriority="high".
El error clásico es poner lazy en todas de una sola vez, incluida la de arriba. Empeora justamente la métrica que se quería mejorar.
El detalle que casi nadie pone: las medidas
Toda imagen necesita width y height en el HTML, aunque el CSS después la redimensione.
Sin eso, el navegador no sabe cuánto espacio reservar: pinta el texto, llega la imagen y todo salta hacia abajo. Eso es CLS, y es una de las tres métricas de Core Web Vitals.
Es un arreglo de dos atributos que mejora una métrica entera, y es de los pocos casos en que la relación entre esfuerzo y resultado es tan clara.
El texto alternativo no es opcional
Va aparte porque no tiene que ver con el peso, pero se decide en el mismo momento.
El alt es lo que lee alguien con un lector de pantalla y lo único que un buscador puede entender de la imagen. Tiene que decir qué muestra, no que hay una imagen.
Mal: alt="gráfico". Bien: alt="Los seis rastreadores de IA más frecuentes, con de quién es cada uno".
Una excepción legítima: cuando la imagen es decorativa y lo que dice ya está en el texto de al lado, el alt vacío es lo correcto. Repetir el nombre que está escrito dos centímetros más arriba no le sirve a nadie.
Qué lee un modelo de una imagen, y por qué un dato dibujado adentro no se puede citar, está en GEO multimodal.
Cómo comprobar en qué estás
Dos herramientas gratis y ningún costo:
PageSpeed Insights lista las imágenes con problema, una por una, y dice cuánto ahorraría cada arreglo. Empieza siempre por «servir imágenes con el tamaño adecuado», que es la decisión 1.
El panel de red del navegador, ordenando por tamaño. La imagen más pesada de tu portada suele ser una sorpresa.
Mide la velocidad de una página con datos de usuarios reales y con una simulación de laboratorio.
Para qué se usa
- Ver tus Core Web Vitals de campo, que son los que cuentan
- Encontrar qué está frenando la carga, con el dato de laboratorio
- Comparar una plantilla contra otra antes de cambiar nada
Los umbrales concretos y la diferencia entre lo que mide una prueba de laboratorio y lo que miden las visitas reales están en Core Web Vitals.
El orden para arreglarlo
- Achicá las que están fuera de tamaño. Es el 80 % del ahorro y no requiere cambiar nada del código.
- Pasá a AVIF con respaldo WebP. Si tu plataforma lo hace sola, ya está.
- Poné
widthyheighten todas. Dos atributos, una métrica. lazya todo menos a la de arriba.
Los tres primeros se hacen una vez y quedan. El cuarto es una regla para cuando publiques.
La guía oficial de Google sobre imágenes, que incluye los criterios de nombres de archivo y de texto alternativo, está en su documentación de imágenes.
Estado de esta entradaRevisada por Sebastián Cardozo el 26 de sept de 2026. Si detectás algo que dejó de estar vigente, o directamente un error, escribinos: se corrige y el cambio queda anotado acá abajo con su fecha.
Siguiente en el manual
