Cómo optimizar las imágenes de tu app web sin perder calidad

Para optimizar las imágenes de una app web, sirve cada una más o menos al tamaño en que se muestra, en un formato moderno como WebP o AVIF, con su ancho y alto declarados, cargando la imagen principal de inmediato y las demás solo cuando están por aparecer en pantalla. Haz lo mismo con las imágenes que suben tus usuarios: redimensiónalas una vez, al subirlas o con un servicio de imágenes, en vez de mandar la foto original a cada visitante. Con esos pocos cambios el peso de la página suele bajar muchísimo y las métricas de carga mejoran sin que se note pérdida de calidad.

En esta guía verás cómo detectar imágenes demasiado pesadas, qué formato usar en cada caso, los atributos de HTML que importan, qué hacer con lo que suben los usuarios y cómo comprobar el resultado.

¿Cómo sé si el problema son las imágenes?

Abre tu página en Chrome, luego las DevTools, la pestaña Network (Red), filtra por "Img" y recarga. Ordena por tamaño. Señales de alerta:

• Imágenes sueltas de varios cientos de kilobytes.
• Imágenes cuyo tamaño real (pasa el cursor sobre el archivo en el panel Elementos) es varias veces mayor que el espacio que ocupan en pantalla.
• Archivos PNG usados para fotografías.
• Decenas de imágenes cargando en una página donde solo se ven tres.

Lighthouse y PageSpeed Insights también marcan las imágenes sobredimensionadas y calculan cuánto ahorrarías. En apps hechas con IA el caso más común es una foto principal o de producto subida directo desde la cámara del teléfono, de miles de píxeles de ancho, mostrada en una tarjeta de 400 píxeles.

¿Qué formato de imagen uso?

Para fotografías, WebP o AVIF con una calidad de alrededor de 75 a 80 se ven iguales al original para casi cualquier persona. Para iconos, usa SVG en lugar de varios PNG de distintos tamaños.

¿Cómo escribo la etiqueta de imagen?

Una imagen bien armada en HTML o JSX se ve así:

<img
  src="/img/equipo-800.webp"
  srcset="/img/equipo-400.webp 400w, /img/equipo-800.webp 800w, /img/equipo-1600.webp 1600w"
  sizes="(max-width: 600px) 100vw, 600px"
  width="800" height="533"
  loading="lazy" decoding="async"
  alt="Dos personas revisan un plano impreso">

Qué hace cada parte:

• srcset y sizes dejan que el navegador elija el archivo más chico que se siga viendo nítido en esa pantalla, incluidas las pantallas de alta densidad de los teléfonos.
• width y height reservan el espacio antes de que llegue el archivo, para que el diseño no salte. Indican la proporción; con CSS la imagen puede seguir siendo adaptable.
• loading="lazy" retrasa las imágenes fuera de pantalla hasta que el usuario se acerca a ellas.
• alt describe la imagen para lectores de pantalla y buscadores. Déjalo vacío (alt="") en imágenes puramente decorativas.

La excepción: tu imagen principal

La imagen grande al inicio de la página suele ser el elemento Largest Contentful Paint, el momento que Google usa para medir la carga. Con esa imagen haz lo contrario: nunca la cargues en diferido, agrégale fetchpriority="high" y asegúrate de que esté en el HTML inicial, no inyectada después por JavaScript ni puesta como fondo en CSS. Nuestra guía de Core Web Vitals en tu app explica por qué.

¿Qué hago con las imágenes que suben mis usuarios?

Lo que suben los usuarios es lo que más pesa, porque no lo controlas. Un esquema razonable:

1. Redimensiona antes o justo después de subir. Achica la imagen en el navegador antes de enviarla (por ejemplo con un canvas, a 2000 píxeles en el lado largo) o procésala en el servidor.
2. Quita los metadatos. Las fotos de teléfono pueden traer datos EXIF, incluida la ubicación GPS donde se tomaron. Volver a codificar la imagen suele eliminarlos; comprueba que en tu caso pase, porque publicar sin querer la ubicación de la casa de un usuario es un problema de privacidad.
3. Guarda un original y sirve variantes. Genera una miniatura y un tamaño medio, o usa un servicio que redimensione bajo pedido y guarde el resultado en caché.
4. Limita lo que aceptas. Define un tamaño máximo y los tipos permitidos en el formulario, y vuelve a validarlos en el servidor.

Si guardas archivos en Supabase Storage, sus transformaciones de imagen (disponibles desde el plan Pro) permiten pedir una versión redimensionada con parámetros de ancho, alto y calidad, y entregan WebP automáticamente a los navegadores que lo soportan. Las imágenes transformadas cuentan contra una cuota mensual de imágenes de origen, así que revisa los límites actuales de tu plan. Si usas Next.js en Vercel, el componente next/image y la optimización de imágenes de Vercel resuelven el tamaño y el formato de forma parecida, también con límites de uso. Para ver cómo funcionan las subidas en una app de Lovable, mira subir archivos a Supabase Storage desde Lovable.

¿Dónde pongo las imágenes estáticas?

Las imágenes que vienen con tu app (logos, ilustraciones, fotos de marketing) deberían comprimirse una vez al compilar y servirse desde una CDN con cabeceras de caché largas. La mayoría de los hostings para apps de Vite y Next.js ya hacen lo de la CDN solos. Ponle a cada archivo procesado un hash en el nombre, o una versión en la ruta, para poder cachearlo mucho tiempo y aun así reemplazarlo.

¿Cómo compruebo que funcionó?

• Recarga con la pestaña Network abierta y compara el total transferido con el de antes.
• Limita la conexión a "Fast 4G" o "Slow 4G" en las DevTools y mira cómo se va llenando la página.
• Vuelve a correr Lighthouse y revisa las auditorías de imágenes y el tiempo de LCP.
• Mira las imágenes en un teléfono real y en un monitor grande. Si algo se ve borroso, sube un poco la calidad o agrega un tamaño mayor en srcset.

Respuestas rápidas

¿WebP o AVIF? Cualquiera de los dos mejora mucho frente a JPEG y PNG. AVIF suele pesar menos; WebP se codifica más rápido y es la opción más segura si tienes que elegir una.

¿La carga diferida perjudica el SEO? El loading="lazy" nativo está bien para imágenes por debajo de la primera pantalla. No lo uses en la imagen principal y no escondas imágenes detrás de eventos de scroll que los rastreadores nunca disparan.

¿Qué tamaño debe tener una imagen principal? Lo bastante ancha para la pantalla más grande que te importe a su tamaño de visualización, normalmente por debajo de 2000 píxeles, en varias versiones mediante srcset.

¿Lo puede hacer mi herramienta de IA? Puede agregar atributos y convertir archivos estáticos si se lo pides con precisión. El procesamiento de subidas y los servicios de imágenes suelen requerir trabajo directo en el código y en el almacenamiento.

¿Quieres que alguien lo ordene?

Optimizar imágenes es rápido de explicar y tedioso de aplicar en todas partes. Nuestros planes de mantenimiento de software incluyen este tipo de trabajo de rendimiento, y el desarrollo de software a medida cubre armar un flujo de subida y redimensionado bien hecho. Prueba la revisión gratuita de tu app para tener una vista desde afuera, o mándanos un mensaje. La guía de web.dev para optimizar el LCP profundiza en cómo cargar la imagen principal.