JPG ya quedó atrás. Por qué en Reveled todo es WebP

Las imágenes son, en la mayoría de webs, el activo que más pesa y más tarda en cargar. Y en la mayoría de proyectos que llegan a Reveled como rescate, el problema no es el hosting ni el código — son imágenes de 4MB sacadas de un móvil que nadie optimizó antes de subirlas.

JPG tuvo su momento. Ya pasó. WebP comprime entre un 25% y un 35% mejor que JPEG para fotos, y entre un 25% y un 45% mejor que PNG para gráficos con transparencia. El soporte de navegadores es universal. No hay razón para seguir subiendo JPGs en 2026.

En Reveled, todo es WebP. Sin excepciones.

WebP como estándar — y AVIF en el horizonte

WebP es el formato que usamos en todos los proyectos. Es rápido de generar, los navegadores lo soportan sin ningún problema y la diferencia de peso respecto a JPG es inmediata y visible en las métricas.

AVIF es la siguiente generación — comprime un 40-50% mejor que WebP manteniendo la misma calidad. Chrome, Firefox, Safari y Edge ya lo soportan. Lo tenemos en el radar para proyectos nuevos, pero WebP sigue siendo la base sólida de cualquier proyecto hoy.

Un detalle que tiene su gracia: si abres una imagen WebP en una pestaña nueva y la intentas descargar, el navegador te la ofrece en JPG. El formato original sigue ahí por debajo, listo para quien lo necesite. Un guiño a la compatibilidad sin sacrificar nada.

La herramienta que usamos: Compresto

Para conversión y optimización rápida, Compresto es la app que más usamos. Interfaz limpia, resultados muy buenos, soporta WebP directamente y el flujo es tan rápido que no hay excusa para subir una imagen sin optimizar. Para imágenes puntuales que llegan de un cliente o para preparar assets antes de que entren al proyecto, es lo más cómodo.

Cada vez usamos más la terminal para flujos en masa — más adelante en este post están los comandos —, pero Compresto sigue siendo la opción más rápida para casos puntuales.

Para comparación visual antes/después con control total de calidad, Squoosh de Google es una buena alternativa: corre en el navegador, no sube nada a ningún servidor, y permite ver exactamente cómo queda cada nivel de compresión.

Conversión por terminal para flujos de trabajo en masa

Cuando hay que procesar una carpeta entera — imágenes de un portafolio, fotos de un proyecto de cliente, assets de una web completa — la terminal es más rápida que cualquier herramienta visual.

Para WebP:

brew install webp
# Una imagen
cwebp -q 85 imagen.jpg -o imagen.webp
# Carpeta entera
for f in *.jpg; do cwebp -q 85 "$f" -o "${f%.jpg}.webp"; done

Para AVIF:

brew install libavif
# Una imagen
avifenc --min 20 --max 35 imagen.jpg imagen.avif
# Carpeta entera
for f in *.jpg; do avifenc --min 20 --max 35 "$f" "${f%.jpg}.avif"; done

El parámetro -q 85 en WebP y --min 20 --max 35 en AVIF son los valores que usamos para fotos de portafolio. Para thumbnails o imágenes de fondo donde el detalle importa menos, se puede bajar sin que se note.

El tamaño importa antes que el formato

Un AVIF de 4000px sigue siendo una imagen de 4000px. El formato no resuelve el problema de las dimensiones. Antes de convertir, redimensiona:

• Hero full-width: máximo 1920px de ancho
• Imagen de blog o card: máximo 800-1000px de ancho
• Thumbnail: máximo 400px de ancho

Un AVIF bien dimensionado con calidad correcta puede pesar 30-60KB. El mismo archivo sin optimizar, varios megas. Esa diferencia se ve directamente en el tiempo de carga y en el Core Web Vitals.

En proyectos Astro — automático

Astro resuelve esto de serie. El componente <Image> de astro:assets convierte a WebP (o AVIF si se configura) en build time cuando importas la imagen desde src/assets/:

---
import { Image } from 'astro:assets';
import portada from '@/assets/foto.jpg';
---

<Image src={portada} alt="Descripción" width={800} height={600} />

El output es un <img> con la imagen convertida, dimensiones correctas y el formato optimizado. Sin configuración extra. Importante: las imágenes tienen que vivir en src/assets/, no en public/. Las que van en public/ Astro no las toca.

En proyectos Next.js — también automático

El componente <Image> de Next.js hace lo mismo con más opciones. Convierte automáticamente a WebP o AVIF según el soporte del navegador, y además gestiona los tamaños responsivos:

import Image from 'next/image';
import portada from '@/assets/foto.jpg';

<Image
  src={portada}
  alt="Descripción"
  width={800}
  height={600}
  priority={false}
/>

El parámetro priority={true} es el equivalente a loading="eager" — úsalo en imágenes above the fold para no penalizar el LCP.

En proyectos WordPress

WordPress convierte automáticamente a WebP desde la versión 5.8 si el servidor tiene soporte para GD o Imagick. Para verificar, sube cualquier imagen JPG y comprueba si aparece la versión .webp en /wp-content/uploads/.

Si no aparece, el plugin gratuito Converter for Media hace la conversión retroactiva de toda la biblioteca de medios y añade soporte para AVIF.

El error que hunde el LCP: lazy loading en la imagen hero

Esto lo hemos visto en muchos proyectos: ponen loading="lazy" en todas las imágenes porque “es buena práctica”, incluida la imagen principal del hero. Resultado: el navegador no carga la imagen hasta que el usuario llega a ella, el LCP se dispara y Lighthouse castiga.

La regla es simple:

• Imágenes above the fold (hero, cabecera, portada del post) → loading="eager" o sin atributo (es el default)
• Todo lo demás → loading="lazy"

En Astro, el componente <Image> pone lazy por defecto. Hay que añadir loading="eager" explícitamente en las imágenes críticas.

Lo que pasa con los clientes

El flujo habitual: el cliente entrega las imágenes de su negocio. Fotos de móvil, alguna de cámara, capturas de pantalla. Todo sin optimizar, todo en JPG o PNG, todo pesando entre 3 y 12MB por imagen.

Parte del proceso de Reveled es normalizar ese material antes de que entre al proyecto: dimensionar, convertir y comprimir. No es opcional. Una web rápida no existe si los assets no están preparados. Y esa conversación con el cliente, explicando por qué importa, es parte del trabajo.

Imágenes generadas con IA: el flujo para que salgan bien

Hay un caso de uso que cada vez aparece más: generar la imagen con IA y publicarla directamente. Midjourney, Ideogram, DALL-E desde ChatGPT — todas estas herramientas entregan el resultado en PNG o JPG, a una resolución que ellas deciden, y con unas dimensiones que rara vez coinciden con las que necesita el proyecto.

El problema no es el formato. Es que nadie hace el paso intermedio.

Una cover de blog necesita 1200×675px en ratio 16:9. Una OG image para redes sociales necesita 1200×630px. Una imagen generada por IA llega típicamente a 1024×1024, 1536×1024 o cualquier otra dimensión según el modelo. Si la subes tal cual, el componente <Image> de Astro la redimensiona en build time, pero lo hace desde unas proporciones incorrectas — el recorte queda mal, el sujeto principal puede quedar cortado.

El flujo correcto son dos comandos. Primero ffmpeg para redimensionar y recortar a las dimensiones exactas, después cwebp para convertir:

# Redimensionar y recortar a 1200×675 (cover de blog)
ffmpeg -i imagen-generada.png \
  -vf "scale=1200:675:force_original_aspect_ratio=increase,crop=1200:675" \
  -y /tmp/imagen-temp.png

# Convertir a WebP con calidad 85
cwebp -q 85 /tmp/imagen-temp.png -o cover-final.webp

El flag force_original_aspect_ratio=increase escala la imagen hacia arriba antes de recortar, de forma que nunca quede relleno vacío en los bordes. El crop posterior corta exactamente al centro. Para la OG image cambia 1200:675 por 1200:630 y el resultado sirve para los dos usos.

El mismo flujo aplica si trabajas en proyectos con Astro — las covers del blog de Reveled se preparan exactamente así antes de entrar a src/assets/blog-images/.

Después de desplegar, abre las DevTools del navegador → pestaña Network → filtra por “Img” y verifica que los recursos aparecen como webp o avif. Si usas Cloudflare, activa “Polish” en Speed → Optimization para conversión automática en CDN, incluso para los assets que no pasaron por el flujo de build.

Para proyectos que quieras mejorar en rendimiento — imágenes incluidas — en consultoría hacemos ese diagnóstico. Escríbenos si lo necesitas.