De qué va esto
Las imágenes suelen ser lo más pesado de una página web. En la mayoría de sitios suponen alrededor del 60% de los bytes que descarga un visitante. Si eliges bien el formato, las páginas van más rápidas, la factura de hosting baja y tu LCP (Largest Contentful Paint) mejora. Si eliges mal, pasa lo contrario.
Esta es una guía corta para elegir entre JPG, PNG, WebP y AVIF. Sin drama. Solo para qué sirve cada uno, cuánto pesan y cómo servirlos.
Elección de formato de un vistazo
| Formato | Con pérdida | Transparencia | Mejor para | Soporte de navegador |
|---|---|---|---|---|
| JPG | Sí | No | Fotografías | Universal |
| PNG | No | Sí | Logos, capturas | Universal |
| WebP | Ambos | Sí | Reemplazo general | Todos los navegadores modernos |
| AVIF | Ambos | Sí | Archivos más pequeños | Todos los navegadores modernos (2026) |
| SVG | No (vectorial) | Sí | Iconos, diagramas | Universal |
Los cuatro formatos en cristiano
JPG (o JPEG) existe desde 1992. Es con pérdida (lossy), es decir, descarta datos que probablemente no vas a notar a cambio de archivos más pequeños. No soporta transparencia. Va muy bien para fotografías y mal para logos, capturas de pantalla y cualquier cosa con bordes nítidos o texto.
PNG es sin pérdida (lossless). Cada píxel se conserva exactamente. Soporta transparencia. La pega es el peso: un PNG de una fotografía puede ser cinco o diez veces más grande que la misma imagen en JPG. Úsalo para logos, iconos, capturas, diagramas y cualquier cosa donde se notarían los artefactos de compresión.
WebP lo creó Google hacia 2010 y hoy lo soporta cualquier navegador que la gente use de verdad. Puede ser con pérdida (más pequeño que JPG a la misma calidad) o sin pérdida (más pequeño que PNG). Soporta transparencia en ambos modos. Piénsalo como un reemplazo más eficiente tanto de JPG como de PNG.
AVIF es más nuevo. Está basado en el códec de vídeo AV1 y produce los archivos más pequeños de los cuatro. Soporta transparencia, animación y HDR. Tarda más en codificar en el servidor y decodifica un poco más lento que WebP en el navegador, pero en 2026 el soporte es sólido (Chrome, Edge, Firefox, Safari y Opera lo manejan).
Pesos reales
Los números ayudan. Esto es lo que pesa aproximadamente una foto hero de 1920x1080 en cada formato con ajustes de calidad razonables:
- JPG, calidad 80: unos 250 KB
- WebP, calidad 80: unos 150 KB
- AVIF, calidad 60: unos 100 KB
Para un logo o captura con fondo transparente:
- PNG: unos 80 KB
- WebP sin pérdida: unos 55 KB
- AVIF sin pérdida: unos 45 KB
Los números exactos dependen de la imagen. Un cielo azul comprime mucho mejor que una foto de un bosque. Pero el orden se mantiene: AVIF es el más ligero, luego WebP, luego JPG o PNG.
La regla simple para elegir
No hace falta un diagrama de flujo. La regla es:
- Fotos y arte complejo: JPG, WebP con pérdida o AVIF. Si puedes servir formatos modernos, hazlo.
- Logos, iconos, capturas, diagramas: PNG, WebP sin pérdida o AVIF sin pérdida.
- Vectoriales (logos, iconos, ilustraciones): SVG. Escala a cualquier tamaño y suele ser el más pequeño de todos.
- Animación: WebP o AVIF en lugar de GIF. El GIF es enorme y se limita a 256 colores.
JPG no está muerto. Sigue funcionando en todas partes y es válido por compatibilidad. Pero si puedes servir AVIF o WebP con JPG como fallback, ahorras un 30 a 50% de ancho de banda en páginas con muchas imágenes. Eso suma.
Servir varios formatos con picture
El elemento picture permite al navegador elegir el mejor formato que entiende. Listas candidatos del mejor al peor y terminas con un img normal como respaldo universal:
<picture>
<source srcset="hero.avif" type="image/avif">
<source srcset="hero.webp" type="image/webp">
<img src="hero.jpg"
alt="Descripción de la imagen"
width="1920"
height="1080"
fetchpriority="high"
decoding="async">
</picture>Lo que pasa aquí:
- El navegador recorre la lista de source de arriba abajo y usa el primero que entiende.
- El img dentro de picture es el respaldo final. Su src es lo que se carga si ningún source coincide.
- Los atributos width y height evitan saltos de layout (CLS) mientras la imagen carga. Ponlos con las dimensiones reales de la imagen.
- decoding=“async” deja que el navegador decodifique la imagen fuera del hilo principal.
- fetchpriority=“high” lo vemos a continuación.
fetchpriority y tu imagen hero
Por defecto, los navegadores descargan las imágenes con menos prioridad que los scripts y las hojas de estilo. Además, esperan a tener el layout más o menos resuelto antes de decidir qué imágenes importan. Eso está bien para imágenes por debajo del pliegue, pero ralentiza tu imagen hero, que normalmente es el elemento LCP.
La pista fetchpriority=“high” le dice al navegador: esta es importante, empieza a descargarla ya. Úsala en:
- La imagen hero de la parte superior de la página.
- Cualquier imagen que sepas que es el elemento LCP.
No la pongas en todas las imágenes. Si todo es de prioridad alta, nada lo es.
<img src="hero.jpg"
alt="..."
width="1920"
height="1080"
fetchpriority="high">En nuestras pruebas suele recortar entre 200 y 600 ms del LCP en conexiones lentas. No es rendimiento gratis, pero casi.
Imágenes responsivas con srcset
Si tu diseño muestra la hero a 1920 px en escritorio y a 720 px en móvil, no envíes el archivo de 1920 px al teléfono. Usa srcset y sizes:
<picture>
<source
type="image/avif"
srcset="hero-720.avif 720w, hero-1280.avif 1280w, hero-1920.avif 1920w"
sizes="(max-width: 768px) 100vw, 80vw">
<source
type="image/webp"
srcset="hero-720.webp 720w, hero-1280.webp 1280w, hero-1920.webp 1920w"
sizes="(max-width: 768px) 100vw, 80vw">
<img src="hero-1280.jpg"
alt="..."
width="1920"
height="1080"
fetchpriority="high">
</picture>El navegador elige un candidato según el viewport y la densidad de píxeles del dispositivo. Un teléfono recibe el archivo de 720. Un portátil retina recibe el de 1920. Nadie descarga más de lo que necesita.
Consejos prácticos que suman
- Pon siempre width y height en cada img. Reserva el espacio y evita que la página salte mientras cargan las imágenes. Tu CLS lo agradecerá.
- Carga diferida (lazy) para imágenes bajo el pliegue con loading=“lazy”. No la apliques a la hero, eso la retrasa.
- Genera AVIF y WebP en el build, no al vuelo. Herramientas como sharp (Node), Squoosh (navegador) o tu CDN de imágenes lo resuelven. La mayoría de generadores estáticos tienen un plugin. Para lotes puntuales, el redimensionador de imágenes procesa un archivo desde el navegador.
- Quita los metadatos de las fotos antes de publicarlas. Los datos EXIF pueden ocupar cientos de KB y rara vez le sirven al lector.
- Escribe alt text de verdad en cada imagen. La guía de SEO de imágenes y accesibilidad cubre qué escribir y qué saltarse.
- Usa SVG para iconos y logos cuando puedas. Es texto, escala bien y a menudo pesa menos de 1 KB.
Cuando WebP se vuelve incómodo
WebP es genial en la web y torpe fuera de ella. Si arrastras un WebP a versiones antiguas de Photoshop, se queja. Si lo mandas por WhatsApp Desktop, a veces no lo acepta. Si coges imágenes de la web para una presentación o un documento, te vas a topar con esto.
Para eso construimos Save Image As Type. Es una pequeña extensión de navegador que te deja guardar cualquier imagen como JPG, PNG o WebP, sea cual sea el formato que envió el servidor. Útil cuando necesitas un formato que tus otras herramientas sí lean.
La versión corta
- Para fotos, sirve AVIF con respaldo WebP y respaldo JPG. El elemento picture se encarga de elegir.
- Para logos y capturas, usa SVG cuando puedas, si no PNG o WebP sin pérdida.
- Pon width y height en cada imagen. Usa fetchpriority=“high” en la hero. Usa srcset para tamaños responsivos.
- JPG está bien por compatibilidad. AVIF y WebP solo te ahorran ancho de banda.
Eso es casi todo lo que necesitas saber. El resto es cuestión de herramientas.