¿Cómo migrar todas las imágenes de una web HTML a formatos de nueva generación (WebP, AVIF)?

Hay algo casi tierno en una página HTML antigua cargando fotografías enormes, como un burro noble arrastrando un piano por una cuesta. Funciona, sí. Pero a qué precio. En una época en la que los usuarios abandonan una página si tarda demasiado y Google mide el rendimiento con una severidad de notario cansado, seguir sirviendo imágenes pesadas en JPEG o PNG sin estrategia es una forma muy educada de perder tráfico.

WebP y AVIF son formatos de imagen modernos diseñados para reducir el tamaño de los archivos manteniendo una calidad visual alta. Dicho sin incienso técnico: permiten que tu web cargue más rápido, consuma menos ancho de banda y mejore métricas como el LCP, uno de los indicadores clave de los Core Web Vitals. Pero migrar todas las imágenes de una web HTML no consiste en “convertir archivos y rezar”. La fe mueve montañas, pero no actualiza rutas relativas ni configura cabeceras HTTP.

Mapa rápido del proceso 🧭

1. Auditar todas las imágenes actuales.
2. Decidir qué formatos usar: WebP, AVIF o ambos.
3. Crear una copia de seguridad completa.
4. Convertir las imágenes con herramientas fiables.
5. Actualizar el HTML con <picture>, srcset o sustitución directa.
6. Configurar fallback para navegadores y casos especiales.
7. Optimizar caché, CDN, lazy loading y dimensiones.
8. Validar calidad visual, SEO, accesibilidad y rendimiento.
9. Automatizar el flujo para futuras imágenes.

Por qué migrar imágenes a WebP y AVIF no es un capricho

En muchos sitios web, las imágenes representan la mayor parte del peso total de una página. No es raro encontrar homepages donde el HTML pesa menos que una carta breve y, sin embargo, las imágenes pesan como una mudanza completa. La paradoja es deliciosa y cruel: optimizamos minúsculos fragmentos de JavaScript mientras una foto de cabecera, indiferente como una ballena dormida, ocupa 4 MB.

Los formatos modernos atacan exactamente ese problema. WebP, desarrollado por Google, ofrece compresión con pérdida y sin pérdida, transparencia y animación. En pruebas ampliamente citadas por Google, WebP con pérdida puede ser alrededor de un 25 % a 34 % más pequeño que JPEG a calidad comparable, mientras que WebP sin pérdida puede reducir el tamaño frente a PNG en torno a un 26 %, aunque los resultados reales dependen muchísimo del contenido.

AVIF, basado en el códec AV1, suele lograr compresiones todavía más agresivas, especialmente en fotografías, degradados y escenas complejas. Puede producir archivos más pequeños que WebP con una calidad visual excelente. La contrapartida —porque la tecnología también cobra peaje— es que la codificación AVIF suele ser más lenta y no siempre conviene para flujos de trabajo masivos sin planificación.

Idea central: no se trata de sustituir todo ciegamente. Se trata de servir la mejor imagen posible al navegador adecuado, en el tamaño adecuado, con el peso adecuado. Esa palabra, “adecuado”, parece aburrida. En rendimiento web es oro puro.

Antes de tocar nada: inventario, copia de seguridad y sentido común

La primera migración seria no ocurre en el servidor. Ocurre en una hoja de cálculo, en un listado, en un mapa humilde de lo que existe. Yo aprendí esto hace años con una web estática de un pequeño museo local: convertimos imágenes, limpiamos carpetas, celebramos demasiado pronto… y descubrimos que una visita virtual dependía de archivos JPEG llamados desde un JavaScript escrito por alguien que probablemente ya cultivaba tomates en otra provincia. La web no se rompió del todo, que es una forma elegante de decir que sí se rompió.

Antes de convertir, conviene localizar todas las imágenes:

• Imágenes referenciadas en etiquetas <img>.
• Fondos declarados en CSS con background-image.
• Imágenes cargadas desde JavaScript.
• Iconos, favicons, logos y sprites.
• Imágenes usadas en metadatos sociales: og:image, twitter:image.
• Archivos incluidos en feeds, sitemaps o datos estructurados.
• Imágenes duplicadas en carpetas antiguas, subdirectorios y backups públicos —sí, esos cementerios digitales tan discretos.

Comandos útiles para auditar una web HTML

Si trabajas en Linux, macOS o un servidor con herramientas Unix, puedes empezar con búsquedas simples:

find . -type f \( -iname "*.jpg" -o -iname "*.jpeg" -o -iname "*.png" -o -iname "*.gif" \)

Para localizar referencias dentro de HTML, CSS y JavaScript:

grep -RInE "\.(jpg|jpeg|png|gif|webp|avif)" . --include="*.html" --include="*.css" --include="*.js"

Y para obtener tamaños de archivo ordenados, algo bastante revelador:

find . -type f \( -iname "*.jpg" -o -iname "*.jpeg" -o -iname "*.png" \) -exec du -h {} + | sort -hr | head -50

Ese listado suele ser una escena de crimen: aparecen banners olvidados, capturas duplicadas, fotografías subidas directamente desde una cámara réflex y algún PNG gigantesco que alguien, en un arrebato de optimismo, llamó icono-final-final-bueno.png.

Copia de seguridad: el seguro contra el entusiasmo

Haz una copia completa antes de empezar:

• Archivos HTML, CSS, JS e imágenes.
• Configuraciones del servidor: .htaccess, Nginx, reglas de CDN.
• Sitemaps, robots.txt y assets sociales.
• Repositorio Git, si existe. Si no existe, quizá este sea el momento de admitir que la aventura necesita cinturón de seguridad.

tar -czf backup-web-antes-migracion-imagenes.tar.gz /ruta/de/tu/web

Si usas Git:

git checkout -b migracion-webp-avif
git add .
git commit -m "Backup antes de migrar imágenes a WebP y AVIF"

Elegir estrategia: WebP, AVIF o ambos

La estrategia más robusta para una web HTML es servir AVIF primero, WebP después y mantener el formato original como fallback. Es una pequeña monarquía de eficiencia: el formato más moderno toma la delantera, el más compatible le cubre la espalda, y el viejo JPEG queda como abuelo respetable en la esquina.

En HTML, esto se hace con la etiqueta <picture>:

<picture>
  <source srcset="/img/foto.avif" type="image/avif">
  <source srcset="/img/foto.webp" type="image/webp">
  <img src="/img/foto.jpg" alt="Descripción clara de la imagen" width="1200" height="800" loading="lazy">
</picture>

El navegador evaluará las fuentes en orden. Si entiende AVIF, usará AVIF. Si no, probará WebP. Si tampoco, cargará el src original. Elegante. Casi civilizado.

💡 Recomendación práctica: para proyectos profesionales, conserva los originales aunque no los sirvas por defecto. Te servirán para regenerar versiones futuras, cambiar calidades, crear tamaños responsive o corregir conversiones defectuosas.

Qué imágenes debes convertir y cuáles no

Convertir todo a WebP o AVIF sin pensar es como pintar una biblioteca con rodillo industrial: rápido, uniforme y ligeramente criminal. Hay casos en los que conviene conservar el formato original.

Herramientas profesionales para convertir imágenes

Existen herramientas visuales, librerías de línea de comandos y servicios externos. La elección depende del tamaño del sitio, el nivel de automatización y el control que necesites.

1. cwebp y avifenc: control directo desde terminal

cwebp forma parte de las herramientas oficiales de WebP. Para convertir un JPEG:

cwebp -q 82 imagen.jpg -o imagen.webp

Para PNG con transparencia:

cwebp -q 85 imagen.png -o imagen.webp

Para AVIF, una herramienta habitual es avifenc, incluida en libavif:

avifenc --min 25 --max 35 --speed 6 imagen.jpg imagen.avif

En AVIF, valores más bajos de cuantización suelen significar más calidad y más peso; además, la velocidad de codificación influye en tiempo y eficiencia. No hay un número mágico universal. Quien lo prometa vende humo con embalaje brillante.

2. ImageMagick: versátil, aunque conviene verificar soporte

ImageMagick puede convertir imágenes si fue compilado con soporte para WebP y AVIF:

magick imagen.jpg -quality 82 imagen.webp
magick imagen.jpg -quality 50 imagen.avif

Comprueba primero:

magick -list format | grep -Ei "WEBP|AVIF"

3. Sharp: ideal para automatización con Node.js

sharp es una de las librerías más usadas para procesamiento de imágenes en entornos Node.js. Es rápida, automatizable y apropiada para pipelines de build.

npm install sharp

const sharp = require("sharp");
const fs = require("fs");
const path = require("path");

const inputDir = "./img";
const outputDir = "./img-optimizada";

fs.mkdirSync(outputDir, { recursive: true });

const files = fs.readdirSync(inputDir).filter(file =>
  /\.(jpg|jpeg|png)$/i.test(file)
);

(async () => {
  for (const file of files) {
    const inputPath = path.join(inputDir, file);
    const name = path.parse(file).name;

    await sharp(inputPath)
      .webp({ quality: 82 })
      .toFile(path.join(outputDir, `${name}.webp`));

    await sharp(inputPath)
      .avif({ quality: 50, effort: 6 })
      .toFile(path.join(outputDir, `${name}.avif`));

    console.log(`Convertido: ${file}`);
  }
})();

4. Squoosh, TinyPNG, ShortPixel, Cloudinary y CDN inteligentes

Para lotes pequeños, herramientas como Squoosh pueden ser magníficas. Para proyectos grandes, servicios como Cloudinary, Imgix, Bunny Optimizer, Cloudflare Images o similares permiten transformación dinámica, redimensionado y negociación de formato según navegador. Son cómodos, sí. También introducen dependencia externa, coste recurrente y cierta sensación de estar alquilando la llave de tu propia despensa.

Conversión masiva desde terminal

Si tu web tiene cientos o miles de imágenes, necesitas un flujo repetible. La improvisación sirve para una sobremesa; para migraciones técnicas, mejor scripts.

Convertir todos los JPEG y PNG a WebP

find ./img -type f \( -iname "*.jpg" -o -iname "*.jpeg" -o -iname "*.png" \) | while read img; do
  output="${img%.*}.webp"
  cwebp -q 82 "$img" -o "$output"
done

Convertir todos los JPEG y PNG a AVIF

find ./img -type f \( -iname "*.jpg" -o -iname "*.jpeg" -o -iname "*.png" \) | while read img; do
  output="${img%.*}.avif"
  avifenc --min 25 --max 35 --speed 6 "$img" "$output"
done

Evitar reconvertir archivos ya procesados

find ./img -type f \( -iname "*.jpg" -o -iname "*.jpeg" -o -iname "*.png" \) | while read img; do
  webp="${img%.*}.webp"
  avif="${img%.*}.avif"

  if [ ! -f "$webp" ]; then
    cwebp -q 82 "$img" -o "$webp"
  fi

  if [ ! -f "$avif" ]; then
    avifenc --min 25 --max 35 --speed 6 "$img" "$avif"
  fi
done

⚠️ No borres los originales inmediatamente. Primero verifica visualmente, revisa rutas, prueba en navegadores reales y mide rendimiento. Borrar originales antes de validar es esa clase de valentía que luego se pronuncia “incidente”.

Actualizar el HTML: tres enfoques posibles

Aquí empieza la parte delicada. Convertir imágenes es mecánico; integrarlas bien exige criterio. Una web HTML puede usar rutas relativas, rutas absolutas, plantillas, includes, fragmentos repetidos, código viejo o una mezcla de todo eso, como un cajón de cables que nadie se atreve a ordenar.

Enfoque 1: sustitución directa del src

Cambiar esto:

<img src="/img/producto.jpg" alt="Producto artesanal de cerámica">

Por esto:

<img src="/img/producto.webp" alt="Producto artesanal de cerámica" width="800" height="600" loading="lazy">

Es simple, pero tiene una desventaja: si un navegador, bot, cliente de correo o sistema incrustado no soporta WebP, no hay alternativa. Hoy WebP tiene soporte muy amplio en navegadores modernos, pero en proyectos corporativos, institucionales o con audiencias imprevisibles conviene ser más prudente.

Enfoque 2: usar <picture> con AVIF, WebP y fallback

Es la opción más segura y profesional:

<picture>
  <source srcset="/img/producto.avif" type="image/avif">
  <source srcset="/img/producto.webp" type="image/webp">
  <img src="/img/producto.jpg" alt="Producto artesanal de cerámica" width="800" height="600" loading="lazy">
</picture>

Además, puedes combinarlo con imágenes responsive:

<picture>
  <source
    type="image/avif"
    srcset="/img/hero-480.avif 480w, /img/hero-960.avif 960w, /img/hero-1440.avif 1440w"
    sizes="(max-width: 768px) 100vw, 1440px">

  <source
    type="image/webp"
    srcset="/img/hero-480.webp 480w, /img/hero-960.webp 960w, /img/hero-1440.webp 1440w"
    sizes="(max-width: 768px) 100vw, 1440px">

  <img
    src="/img/hero-1440.jpg"
    srcset="/img/hero-480.jpg 480w, /img/hero-960.jpg 960w, /img/hero-1440.jpg 1440w"
    sizes="(max-width: 768px) 100vw, 1440px"
    alt="Vista principal del alojamiento rural al amanecer"
    width="1440"
    height="810"
    fetchpriority="high">
</picture>

Observa el detalle de fetchpriority="high". Puede ser útil para la imagen principal visible al cargar, especialmente si afecta al Largest Contentful Paint. No lo pongas en todas partes. Si todo es prioritario, nada lo es; vieja lección de oficina, aplicable también a los navegadores.

Enfoque 3: negociación automática desde servidor

Otra estrategia consiste en dejar el HTML apuntando a .jpg o .png y configurar el servidor para entregar WebP o AVIF si el navegador los acepta mediante la cabecera Accept. Es limpio para el HTML, pero requiere una configuración más delicada de caché y CDN.

En Apache, una aproximación con .htaccess podría ser:

<IfModule mod_rewrite.c>
  RewriteEngine On

  RewriteCond %{HTTP_ACCEPT} image/avif
  RewriteCond %{REQUEST_FILENAME}.avif -f
  RewriteRule ^(.+)\.(jpe?g|png)$ $1.$2.avif [T=image/avif,E=accept:1]

  RewriteCond %{HTTP_ACCEPT} image/webp
  RewriteCond %{REQUEST_FILENAME}.webp -f
  RewriteRule ^(.+)\.(jpe?g|png)$ $1.$2.webp [T=image/webp,E=accept:1]

  Header append Vary Accept env=accept
</IfModule>

Sin embargo, este ejemplo depende de cómo nombres los archivos. Si generas foto.jpg.webp, la regla cambia. Si generas foto.webp, cambia también. La configuración del servidor no perdona suposiciones: es un espejo, no una madre.

En Nginx, se suele usar map para detectar soporte:

map $http_accept $modern_image_suffix {
    default "";
    "~image/avif" ".avif";
    "~image/webp" ".webp";
}

server {
    location ~* ^(.+)\.(jpg|jpeg|png)$ {
        add_header Vary Accept;
        try_files $uri$modern_image_suffix $uri =404;
    }
}

⚠️ Cuidado con la caché: si sirves diferentes formatos desde la misma URL, asegúrate de enviar Vary: Accept y de que tu CDN respete esa cabecera. De lo contrario, podrías entregar AVIF a un navegador que no lo soporta. Muy moderno todo, hasta que aparece una imagen rota.

Imágenes en CSS: el rincón olvidado

Muchas migraciones fallan porque solo actualizan etiquetas <img>. Pero las imágenes decorativas suelen vivir en CSS:

.hero {
  background-image: url("/img/cabecera.jpg");
}

Para servir formatos modernos en CSS, puedes usar image-set():

.hero {
  background-image: image-set(
    url("/img/cabecera.avif") type("image/avif"),
    url("/img/cabecera.webp") type("image/webp"),
    url("/img/cabecera.jpg") type("image/jpeg")
  );
}

También puedes combinarlo con media queries para no enviar imágenes gigantes a móviles:

.hero {
  background-image: image-set(
    url("/img/cabecera-mobile.avif") type("image/avif"),
    url("/img/cabecera-mobile.webp") type("image/webp"),
    url("/img/cabecera-mobile.jpg") type("image/jpeg")
  );
}

@media (min-width: 900px) {
  .hero {
    background-image: image-set(
      url("/img/cabecera-desktop.avif") type("image/avif"),
      url("/img/cabecera-desktop.webp") type("image/webp"),
      url("/img/cabecera-desktop.jpg") type("image/jpeg")
    );
  }
}

La diferencia entre servir una imagen de 1800 píxeles a un móvil y servir una versión ajustada es la diferencia entre abrir una ventana y derribar la pared. Ambas cosas dejan entrar aire, pero una de ellas cuesta bastante menos.

Calidad de compresión: números orientativos que sí sirven

No existe una calidad universal. La imagen de un plato de comida, un retrato corporativo y una captura de software no responden igual a la compresión. Aun así, hay rangos razonables para empezar:

Mi método preferido es crear tres versiones de prueba por tipo de imagen y compararlas no solo en monitor grande, sino también en móvil. El móvil es cruel, pero honesto. Muestra artefactos como una lámpara de interrogatorio.

SEO técnico: no rompas lo que ya posiciona

Migrar imágenes también tiene implicaciones SEO. Google puede indexar WebP y otros formatos modernos, pero eso no significa que debas cambiar URLs sin pensar. Si tus imágenes reciben tráfico desde Google Imágenes o están enlazadas externamente, las rutas importan.

Buenas prácticas SEO al migrar imágenes

• Mantén atributos alt descriptivos. La compresión no sustituye la accesibilidad.
• No cambies nombres útiles por códigos opacos. mesa-roble-artesanal.webp dice más que IMG_8392.webp.
• Actualiza el sitemap de imágenes si lo usas.
• Revisa metadatos Open Graph. Algunas plataformas sociales pueden comportarse de forma desigual con formatos modernos; JPEG o PNG siguen siendo apuestas seguras para og:image.
• Evita errores 404. Si cambias URLs, crea redirecciones cuando sea necesario.
• Conserva dimensiones declaradas con width y height para reducir CLS.
• Usa nombres coherentes para versiones responsive: producto-480.webp, producto-960.webp, producto-1440.webp.

Si reemplazas directamente /img/foto.jpg por /img/foto.webp, Google tendrá que descubrir la nueva URL. No es grave, pero conviene preverlo. Si mantienes fallback con <picture>, el <img src> original sigue presente, lo cual puede ser útil para continuidad.

Rendimiento: WebP y AVIF son solo una parte de la historia

Una imagen moderna mal dimensionada sigue siendo una mala imagen. Más pequeña, quizá. Pero mala. Optimizar formato sin optimizar dimensiones es como poner neumáticos de competición a un carro oxidado: mejora algo, pero no cambia la naturaleza del problema.

Acciones imprescindibles junto con la migración

• Redimensiona imágenes. No sirvas 3000 px si se muestran a 600 px.
• Genera versiones responsive con srcset y sizes.
• Activa lazy loading en imágenes fuera del primer viewport: loading="lazy".
• Prioriza la imagen LCP con fetchpriority="high" cuando corresponda.
• Define width y height para evitar saltos visuales.
• Configura caché larga para assets versionados.
• Usa CDN si tienes audiencia geográficamente distribuida.
• Elimina imágenes no usadas, pero solo después de auditar dependencias.

Cabeceras de caché recomendadas

Para archivos versionados o con nombres únicos, puedes usar caché agresiva:

Cache-Control: public, max-age=31536000, immutable

Si sustituyes archivos manteniendo el mismo nombre, cuidado: los usuarios podrían ver versiones antiguas hasta que expire la caché. Lo profesional es versionar:

/img/producto.v2.webp
/img/producto.2025-optimizado.avif

O usar hashes generados por tu pipeline:

/assets/producto.a8f93c.webp

Seguridad y mantenimiento: el lado menos glamuroso, o sea, el importante

Las imágenes parecen inofensivas. Un paisaje, un logo, una foto de equipo. Pero cualquier sistema que procesa archivos debe tratarse con respeto. Las librerías de imagen han tenido vulnerabilidades históricas; los SVG pueden contener scripts; los metadatos EXIF pueden revelar ubicación GPS; los permisos mal configurados pueden exponer directorios completos.

Recomendaciones de seguridad

• Actualiza herramientas como ImageMagick, libwebp, libavif, sharp o dependencias del sistema.
• No proceses archivos no confiables sin validación, especialmente si usuarios suben imágenes.
• Elimina metadatos sensibles si no son necesarios.
• Sanitiza SVG antes de publicarlos.
• Evita permisos 777 en carpetas de imágenes.
• Bloquea listados de directorio si el servidor los muestra.
• Escanea archivos antiguos en sitios heredados.

Para eliminar metadatos con ImageMagick:

magick imagen.jpg -strip imagen-limpia.jpg

En conversiones con Sharp, por defecto no se conservan todos los metadatos salvo que se indique lo contrario, lo cual suele ser conveniente. Pero confirma tu flujo; la confianza ciega en herramientas automáticas es una forma muy moderna de tropezar con una piedra antigua.

Automatizar la actualización del HTML sin destruirlo

Si tienes diez páginas, puedes editar a mano. Si tienes mil, editar a mano es una penitencia medieval con teclado mecánico. Pero cuidado: sustituir rutas con expresiones regulares sobre HTML complejo puede generar daños sutiles.

Para una web estática sencilla, podrías usar un script que reemplace etiquetas <img> por estructuras <picture>. Pero lo más seguro es:

1. Trabajar en una rama Git.
2. Procesar solo patrones controlados.
3. Generar un informe de cambios.
4. Revisar diferencias con git diff.
5. Probar con un crawler local.

Una alternativa pragmática consiste en migrar primero las imágenes críticas: cabecera, productos, galerías, banners principales. Después, abordar el resto por carpetas. La perfección total en el primer intento suele ser enemiga de una mejora real esta semana.

Cómo validar que la migración funciona

La validación debe ser visual, técnica y analítica. No basta con que “se vea bien en mi navegador”, esa frase encantadora que ha inaugurado tantos desastres pequeños.

Checklist de pruebas 🧪

• ✅ Abrir páginas principales en Chrome, Firefox, Safari y Edge actualizados.
• ✅ Probar al menos un móvil iOS y uno Android si el proyecto lo justifica.
• ✅ Revisar DevTools > Network para confirmar que se sirven AVIF/WebP.
• ✅ Comprobar que no hay errores 404 en imágenes.
• ✅ Validar que las imágenes sociales siguen funcionando.
• ✅ Revisar que alt, width y height no se han perdido.
• ✅ Medir antes y después con Lighthouse, PageSpeed Insights o WebPageTest.
• ✅ Verificar Core Web Vitals, especialmente LCP y CLS.
• ✅ Revisar logs del servidor tras publicar.
• ✅ Pasar un crawler como Screaming Frog, Sitebulb o una alternativa CLI.

Comprobar formatos servidos en DevTools

En Chrome o Edge:

1. Abre DevTools.
2. Ve a la pestaña Network.
3. Filtra por Img.
4. Recarga la página sin caché.
5. Revisa la columna Type y el tamaño transferido.

Si ves AVIF en navegadores compatibles y WebP como segunda opción, vas por buen camino. Si ves JPEG gigantes cargándose con la solemnidad de un tren de vapor, toca volver al taller.

Errores frecuentes al migrar imágenes a WebP y AVIF

Plan profesional de migración paso a paso

Para que el proceso sea ordenado, puedes seguir este plan. No es espectacular. Precisamente por eso funciona.

Fase 1: Auditoría

• Crear inventario de imágenes.
• Identificar las más pesadas.
• Detectar rutas en HTML, CSS y JS.
• Separar imágenes críticas, decorativas, sociales y heredadas.

Fase 2: Preparación

• Hacer backup completo.
• Crear rama Git o entorno staging.
• Definir nomenclatura: imagen.webp, imagen.avif, versiones responsive, hashes.
• Elegir calidades por tipo de imagen.

Fase 3: Conversión

• Generar WebP para compatibilidad amplia.
• Generar AVIF para máxima eficiencia donde aporte valor.
• Redimensionar imágenes sobredimensionadas.
• Eliminar metadatos innecesarios.

Fase 4: Integración

• Actualizar etiquetas <img> a <picture> cuando convenga.
• Actualizar CSS con image-set().
• Revisar metadatos sociales.
• Configurar caché y cabeceras.

Fase 5: Validación

• Probar navegadores y dispositivos.
• Revisar errores 404.
• Comparar peso total antes y después.
• Medir LCP, CLS, Speed Index y tiempo de carga.

Fase 6: Publicación y seguimiento

• Publicar en horas de bajo tráfico si el sitio es crítico.
• Purgar caché de CDN con cuidado.
• Monitorizar logs y Search Console.
• Documentar el nuevo flujo para futuras imágenes.

Ejemplo de estructura de carpetas recomendada

En webs HTML pequeñas o medianas, una estructura clara ayuda a no perderse:

/img/
  /originales/
    producto.jpg
    cabecera.png

  /webp/
    producto.webp
    cabecera.webp

  /avif/
    producto.avif
    cabecera.avif

  /responsive/
    producto-480.webp
    producto-960.webp
    producto-1440.webp
    producto-480.avif
    producto-960.avif
    producto-1440.avif

Otra opción es mantener versiones juntas:

/img/producto.jpg
/img/producto.webp
/img/producto.avif
/img/producto-480.webp
/img/producto-480.avif

Lo importante no es el dogma, sino la consistencia. Una estructura mediocre pero coherente suele ser mejor que una estructura brillante aplicada solo los martes.

¿Y si la web HTML es muy antigua?

Las webs antiguas tienen una personalidad propia. A veces encantadora, a veces vengativa. Puede haber tablas de maquetación, rutas con mayúsculas mezcladas, espacios en nombres de archivo, acentos en URLs, imágenes llamadas desde scripts inline y páginas duplicadas con pequeñas variaciones. No juzguemos demasiado: todos hemos dejado alguna vez una carpeta llamada nuevo-definitivo-real.

En estos casos:

• Empieza por las páginas con más tráfico.
• No intentes automatizar lo que no entiendes todavía.
• Usa un crawler para descubrir rutas reales.
• Evita renombrados masivos sin redirecciones.
• Documenta excepciones.
• Haz despliegues pequeños y reversibles.

La migración puede ser también una oportunidad para limpiar deuda técnica: eliminar duplicados, mejorar atributos alt, añadir dimensiones, corregir nombres y ordenar carpetas. Es curioso: uno empieza queriendo aligerar imágenes y termina arqueologizando su propio sitio web, como quien levanta una alfombra y encuentra monedas, polvo y decisiones de 2014.

Cuándo no merece la pena usar AVIF en todas partes

AVIF es potente, pero no siempre imprescindible. Para miniaturas diminutas, iconos, imágenes simples o flujos donde el tiempo de generación importa mucho, WebP puede ofrecer el equilibrio ideal. AVIF brilla especialmente en fotografías grandes y recursos críticos donde cada kilobyte cuenta.

Además, la codificación AVIF puede ser lenta en servidores modestos. Si generas imágenes bajo demanda, debes evaluar CPU, caché y tiempos de respuesta. Servir una imagen ultracomprimida después de hacer esperar al usuario como si estuviera renovando un pasaporte no parece una victoria.

Métricas que deberías comparar antes y después 📊

Una migración profesional se demuestra con datos:

• Peso total de la página: especialmente bytes transferidos de imágenes.
• Número de solicitudes: no siempre debe aumentar innecesariamente.
• LCP: la imagen principal suele influir directamente.
• CLS: debe mantenerse bajo gracias a dimensiones definidas.
• Tiempo hasta primera carga visual.
• Consumo en móvil con red 4G simulada.
• Errores 404 de assets.
• Indexación de imágenes en Google Search Console.

Herramientas útiles:

• Google PageSpeed Insights.
• Lighthouse en Chrome DevTools.
• WebPageTest.
• GTmetrix.
• Screaming Frog SEO Spider.
• Chrome DevTools Coverage y Network.
• Logs del servidor o analítica de CDN.

Flujo recomendado para nuevas imágenes

Migrar una vez está bien. Evitar que el problema vuelva es mejor. La optimización de imágenes debe convertirse en rutina, no en ritual de emergencia cada dos años.

• 📥 Subir siempre una imagen original de calidad.
• ✂️ Redimensionar al tamaño máximo real necesario.
• 🧼 Eliminar metadatos innecesarios.
• 🖼️ Generar WebP y AVIF automáticamente.
• 📱 Crear variantes responsive.
• 🧾 Añadir alt, width, height y, si procede, loading="lazy".
• 🚀 Publicar con caché adecuada.
• 🔍 Revisar en staging antes de producción.

Si usas un generador estático como Eleventy, Astro, Hugo, Jekyll o Next.js exportado como HTML, integra la conversión en el proceso de build. Si la web es HTML artesanal, crea al menos un script reproducible. El futuro tú lo agradecerá; y el futuro tú, como sabemos, suele tener menos paciencia que el presente.

Una receta práctica para una migración equilibrada

Si tuviera que resumir una estrategia profesional, aplicable a la mayoría de webs HTML, sería esta:

1. Audita todo: imágenes en HTML, CSS, JS y metadatos.
2. Optimiza primero lo visible: hero images, banners, productos, galerías principales.
3. Genera WebP para todas las imágenes relevantes.
4. Genera AVIF para imágenes grandes o críticas.
5. Usa <picture> en contenido principal.
6. Usa image-set() para fondos CSS.
7. Mantén originales como fallback y archivo maestro.
8. Declara dimensiones para evitar CLS.
9. Mide antes y después, sin autoengaños.
10. Documenta el proceso para que no dependa de la memoria de nadie.

La migración a WebP y AVIF no es solo una operación de compresión. Es una forma de modernizar la relación entre tu web y quienes la visitan. Menos espera, menos datos consumidos, menos fricción. Frente al viejo internet pesado, brillante y algo despilfarrador, aparece una web más ligera, casi anfibia: capaz de adaptarse al navegador, a la pantalla, a la red.

Y ahí está la antítesis que conviene recordar: una imagen puede ser hermosa y eficiente; una web puede ser rica sin ser lenta; la técnica puede ser invisible y, precisamente por eso, memorable. Migrar bien no se nota como una fanfarria. Se nota como se nota una puerta bien engrasada: porque nadie piensa en ella al pasar.

Empieza por una copia de seguridad. Sigue con una auditoría honesta. Convierte con criterio. Sirve con fallback. Mide con herramientas serias. Y no olvides mirar las imágenes con ojos humanos, no solo con gráficos de rendimiento. Porque al final, incluso en la optimización más técnica, hay una pequeña promesa estética: que la web cargue rápido, sí, pero que al llegar no parezca que le han robado el alma para ahorrar 40 kilobytes. 🖼️⚡