Cómo optimizar las imágenes de tu web: tamaño, formato y carga
Optimizar las imágenes de una web consiste en entregar cada foto con las dimensiones, el formato y la calidad que necesita, y cargarla cuando corresponde. Reducir el peso ayuda, pero una imagen pequeña también puede llegar tarde si la página retrasa su descarga.
El objetivo es conservar el detalle que permite entender una foto, leer una captura o valorar un producto sin enviar archivos innecesarios. Una buena compresión que borra ese detalle deja de ser una buena solución.
En el Desayuno SEO anterior vimos cómo escribir el texto alternativo. Hoy toca otra parte del trabajo: preparar el archivo y comprobar qué recibe realmente el navegador.
¿Qué significa optimizar una imagen para la web?
Significa ajustar tres cosas diferentes: el archivo, su presentación y su carga. Google recomienda combinar calidad visual, velocidad y técnicas de imágenes responsive, en lugar de tratar la optimización como un simple cambio de extensión.
Conviene distinguir estas medidas:
- Dimensiones del archivo: cuántos píxeles de ancho y alto contiene.
- Tamaño mostrado: qué espacio ocupa dentro del diseño, medido en píxeles CSS.
- Peso del archivo: cuántos bytes necesita transferir.
Una foto puede ocupar una columna estrecha y conservar miles de píxeles en el archivo descargado. Hacerla pequeña con CSS cambia su apariencia, pero no convierte por sí solo el original en un archivo más ligero.
Tampoco una extensión moderna resuelve todo. Una imagen WebP excesivamente grande sigue pudiendo enviar más información de la necesaria. Primero hay que entender dónde se utiliza y después preparar sus versiones.
¿Qué tamaño necesita cada imagen?
El tamaño depende del espacio donde se muestra y de la densidad de la pantalla. No existe un ancho único válido para todas las imágenes de una web. MDN explica que las pantallas con mayor densidad pueden necesitar más píxeles de imagen para conservar el detalle en el mismo espacio visual.
Un ejemplo hipotético: una foto se muestra a 400 píxeles CSS de ancho. Una pantalla con densidad 2 puede aprovechar una versión de unos 800 píxeles de ancho. Esa cuenta sirve para entender la relación; no obliga a enviar siempre la versión de 800 ni sustituye a comprobar qué elige el navegador.
Empieza por localizar los usos reales de la imagen: portada, tarjeta de listado, fotografía de producto o apoyo dentro del artículo. Si una misma foto aparece en varios espacios, prepara varios tamaños a partir del original, no varias copias con nombres distintos pero las mismas dimensiones.
Conserva el original fuera de la publicación para poder generar otras versiones. Ampliar una imagen pequeña no recupera el detalle que no tenía. Recortar para móvil también es una decisión editorial: la cara, el producto o la parte importante deben seguir dentro del encuadre.
Añade las dimensiones width y height correspondientes a la proporción de la imagen. No impiden hacerla adaptable con CSS. Ayudan al navegador a reservar espacio antes de que llegue el archivo, como explica web.dev sobre dimensiones y cambios de diseño.
El espacio reservado importa aunque la foto esté comprimida. Si el texto se desplaza cuando aparece la imagen, el problema no se arregla bajando otros diez kilobytes. Esa estabilidad forma parte de lo que revisamos en la guía de Core Web Vitals.
¿Cómo eliges entre JPEG, PNG, WebP y AVIF?
Elige comparando el contenido que necesitas conservar, el peso obtenido y la compatibilidad de tu publicación. Google admite JPEG, PNG, WebP y AVIF, entre otros formatos, para imágenes incluidas mediante elementos de imagen compatibles. No hay que convertir todo a un único formato por costumbre.
JPEG es una opción habitual para fotografías y utiliza compresión con pérdida. Puede funcionar como alternativa cuando necesitas compatibilidad con sistemas que no procesan otros formatos. No conserva transparencia.
PNG permite compresión sin pérdida y transparencia. Puede encajar en capturas o imágenes donde las letras y los bordes deben permanecer precisos. Eso no significa que siempre sea la opción más ligera para ese contenido.
WebP admite compresión con pérdida y sin pérdida, además de transparencia. Es un candidato útil para muchas fotografías y apoyos web, pero conviene comparar el resultado de la exportación, no dar por ganado el ahorro antes de abrir el archivo.
AVIF también permite compresión con pérdida y sin pérdida. Puede producir archivos pequeños con buena calidad; el resultado depende de la imagen y de la configuración. Revisa que tu gestor, generador de miniaturas y destinatarios lo admitan antes de sustituir los archivos existentes.
La guía de formatos de MDN detalla estas diferencias. Para iconos y dibujos vectoriales, SVG es otra categoría: no tiene sentido convertir automáticamente un logotipo vectorial en una foto para seguir una regla de exportación.
Si necesitas varias alternativas, el elemento picture permite ofrecer formatos y dejar una imagen de respaldo. El formato elegido debe corresponder al contenido real del archivo. Renombrar foto.jpg como foto.webp no convierte una imagen.
¿Cómo comprimes una imagen manteniendo calidad útil?
Comprimir consiste en reducir el archivo conservando lo que necesita transmitir. La compresión sin pérdida mantiene la información de la imagen; la compresión con pérdida descarta parte para conseguir otro equilibrio entre peso y calidad. web.dev explica ambas y recomienda comprobar el resultado, especialmente en letras y bordes contrastados.
La expresión "sin perder calidad" necesita contexto. Si usas compresión con pérdida, puede haber cambios aunque no se aprecien al tamaño de publicación. Lo importante es no confundir una diferencia imperceptible con la desaparición de un detalle que el lector necesita.
Un orden de trabajo sencillo:
- Parte del original y decide el encuadre.
- Genera las dimensiones adecuadas para sus usos.
- Exporta dos o tres candidatos de formato y calidad.
- Compara peso y apariencia al tamaño de publicación.
- Revisa también letras, texturas y detalles del producto.
- Guarda el candidato que conserva la información con menos carga innecesaria.
Las herramientas de compresión no comparten una escala universal de calidad. Un valor 80 no garantiza el mismo aspecto ni el mismo tamaño en dos formatos o programas. Tampoco hace falta buscar el archivo más pequeño a cualquier precio: una captura ilegible ya no cumple su función.
Se puede trabajar con un editor, con un optimizador o con el sistema de imágenes del propio gestor. La documentación de rendimiento de imágenes de web.dev cita Squoosh e ImageOptim entre las opciones. Si la web genera variantes automáticamente, comprueba lo que publica; no presupongas que usar una herramienta equivale a tenerla bien configurada.
No hay un máximo universal de kilobytes que convierta una imagen en correcta. Una miniatura y una fotografía ampliable de producto tienen necesidades distintas. Pon el límite de trabajo después de mirar el diseño, la calidad necesaria y el conjunto de recursos que descarga la página.
¿Cómo entregas una versión adecuada a cada pantalla?
Ofreciendo alternativas reales y describiendo el espacio que van a ocupar. srcset enumera archivos candidatos; con descriptores de ancho, sizes informa del ancho mostrado previsto según las condiciones del diseño. El navegador utiliza esa información para elegir, como detalla la guía de imágenes responsive de MDN.
Los candidatos deben existir y sus anchos declarados deben ser correctos. Si anuncias una versión de 480 píxeles y sirves el mismo original de 2400, el nombre del archivo no evita la descarga grande.
sizes tampoco es una forma de cambiar el diseño. Explica el espacio esperado para ayudar a elegir el archivo. Si una tarjeta ocupa media columna en escritorio, describirla como si llenara toda la pantalla puede provocar una elección demasiado grande.
Para que Google pueda descubrir la imagen, mantén una URL utilizable en el atributo src del elemento img. Search Central recomienda ese respaldo también cuando utilizas picture o srcset. Una imagen importante escondida únicamente como fondo CSS no tiene el mismo tratamiento: Google indica que no indexa imágenes CSS.
La comprobación es práctica: abre la misma página con una ventana estrecha y otra amplia y mira qué archivo solicita. No basta con ver que la foto se encoge. Eso solo demuestra que el diseño adapta el tamaño mostrado.
¿Qué imágenes debes cargar al principio y cuáles después?
Las imágenes visibles al entrar deben estar disponibles sin un retraso artificial. Las que quedan más abajo pueden utilizar carga diferida. La distinción no es "portada contra interior", sino qué se ve inicialmente y qué papel tiene cada imagen en esa página.
El atributo loading="lazy" permite retrasar imágenes fuera de la vista inicial hasta que se aproximan a ella. web.dev recomienda no aplicarlo a las imágenes visibles al cargar, especialmente si una de ellas es el elemento LCP, el contenido principal de mayor tamaño que se pinta en pantalla.
Una imagen de portada no es necesariamente el LCP de todas las páginas. Puede serlo un bloque de texto u otro elemento. Compruébalo antes de tocar prioridades. Si la imagen sí es el LCP, la guía de optimización de LCP recomienda que pueda descubrirse pronto y que no se cargue de forma diferida.
fetchpriority="high" puede indicar que una imagen importante merece prioridad. No significa que todas deban llevarlo. Dar la misma prioridad alta a muchas imágenes elimina la utilidad de distinguir la principal.
Quitar lazy y subir la prioridad tampoco compensan cualquier problema. La imagen puede esperar a que se ejecute JavaScript, competir con otros recursos o tardar en mostrarse después de descargarse. El diagnóstico debe separar cuándo empieza a pedirse, cuánto tarda en llegar y cuándo se dibuja.
¿Cómo compruebas el resultado en PageSpeed y el navegador?
Compara la misma página y unas condiciones equivalentes antes y después. Mira el archivo elegido, los bytes transferidos, el inicio de la petición y la calidad que ve la persona. La nota global no explica por sí sola si has solucionado el problema de esa imagen.
En las herramientas del navegador, el panel de red permite localizar las peticiones de imagen. Una prueba con caché vacía ayuda a comprobar la primera descarga. Después revisa también el uso normal con caché: son situaciones distintas, no resultados intercambiables.
En PageSpeed Insights distingue datos de laboratorio y datos de usuarios reales. web.dev explica que los primeros ayudan a investigar una carga concreta y los segundos muestran la experiencia recogida en condiciones reales. Un cambio recién publicado no transforma de inmediato el historial de usuarios.
Antes de dar el trabajo por terminado, revisa:
- La versión móvil no solicita un original innecesariamente grande.
- La imagen principal aparece sin carga diferida improcedente.
- Las imágenes inferiores no compiten todas desde el principio sin necesidad.
- El espacio está reservado y el texto no salta al llegar la foto.
- Las capturas siguen siendo legibles y el producto conserva sus detalles.
- Las URLs de las imágenes responden y el marcado permite descubrirlas.
Si el resultado sigue siendo lento, no conviertas la imagen en culpable automática. El servidor, las fuentes, los estilos o JavaScript pueden estar condicionando la carga. Una auditoría SEO debe localizar el cuello de botella antes de recomendar más compresión.
¿Qué dudas suelen quedar al optimizar imágenes?
¿Poner una foto en WebP mejora su posición en Google?
Cambiar el formato puede reducir el peso si la exportación es adecuada. No garantiza posiciones. Google combina requisitos técnicos, contexto y calidad de la página en sus recomendaciones para imágenes.
¿El texto alternativo reduce el peso de la imagen?
No. Describe su contenido o función según el contexto. Es un trabajo distinto de preparar el archivo, explicado en la guía de texto alternativo.
¿Debo activar lazy loading en todas las imágenes?
No. Reserva la carga diferida para las que están fuera de la vista inicial. Retrasar una imagen LCP añade una espera que web.dev recomienda evitar.
¿Puedo borrar el original después de comprimir?
Conviene conservar una copia de trabajo fuera de la publicación. Si más adelante necesitas otro encuadre o tamaño, volver a partir del original evita depender de una versión que ya perdió detalle. Es una precaución de edición, no un requisito de Google.
Para acabar el café
Elige las dimensiones, compara formatos, ajusta la compresión y decide cuándo cargar cada imagen. Después comprueba el archivo que recibe el navegador. Ese orden evita confundir una foto pequeña en pantalla con una descarga pequeña.
La mejor versión no es la que gana una competición de kilobytes. Es la que conserva lo necesario para entender la página y llega en el momento adecuado.
Última revisión de fuentes: 6 de noviembre de 2026.
