Notas del equipo sobre el oficio, los formatos y las pequeñas decisiones detrás de un buen resultado.
El panorama de compatibilidad del AVIF en 2026
El soporte del AVIF en navegadores alcanzó cerca del 94,3 por ciento de los navegadores globales para 2026, pero el soporte de los navegadores no es la foto completa. Una gran parte del consumo de imágenes ocurre fuera de los navegadores. Clientes de correo, herramientas de diseño, gestores de contenido, canalizaciones de entrega y redes sociales que procesan al subir son los casos más habituales. En la mayoría de estos sistemas que no son navegadores, el soporte del AVIF va muy por detrás de la adopción en navegadores. Gmail, Outlook y la mayoría de los clientes de correo corporativos todavía procesan las imágenes por canalizaciones más antiguas que rechazan el AVIF. Adobe Creative Cloud añadió el soporte AVIF solo en las versiones de finales de 2024. Muchas configuraciones de WordPress con plugins de imagen antiguos aún bloquean el AVIF al subir. El WebP, en cambio, lleva años adoptado en casi todas estas plataformas. Convertir AVIF a WebP es el puente de compatibilidad para esta infraestructura que no son navegadores.
Por qué la conversión es rápida en ambos lados
La ventaja de velocidad de AVIF a WebP frente al sentido inverso viene de la arquitectura de los códecs. La lectura del AVIF la gestiona un descodificador nativo del navegador que funciona con aceleración por hardware en los dispositivos modernos. El guardado del WebP usa el motor WebP nativo del navegador, también acelerado por hardware en la mayoría de las plataformas. Ninguna de las dos operaciones necesita cargar un módulo pesado, que es el cuello de botella del guardado en AVIF. La parte para la salida AVIF es grande y necesita cerca de un segundo para inicializarse por sesión. AVIF a WebP se salta todo eso. La canalización descodifica y luego guarda por rutas nativas, y el recorrido completo de una foto de 2 megapíxeles termina bastante por debajo de un segundo en cualquier navegador moderno de escritorio o portátil. Esto hace que AVIF a WebP sirva para flujos interactivos donde el usuario espera una respuesta en menos de un segundo.
Cuánto cuesta realmente el reguardado
Convertir AVIF a WebP implica un solo paso de reguardado. El AVIF se había guardado en origen con cierto grado de compresión con pérdida. Descodificarlo devuelve valores de detalle que reflejan ese origen con pérdida. El WebP aplica luego su propia compresión a esos detalles con un ajuste casi sin pérdida calibrado para la calidad 85. Con ese ajuste, la salida mide cerca de 44 dB de PSNR en un contenido fotográfico típico. Para alguien que mira una foto a un tamaño normal, la diferencia entre el AVIF de origen y el WebP de salida no se ve. Para gráficos con texto muy fino a pequeños tamaños, iconos perfectos al detalle o bloques de color de bordes duros, el efecto acumulado de dos pasos con pérdida puede mostrar diferencias sutiles bajo una inspección cercana. Antes de comprometerte con la conversión de una biblioteca entera, prueba una muestra representativa al zoom completo en tus recursos más sensibles a la calidad.
El viaje del alpha de ida y vuelta en detalle
La transparencia en el AVIF se codifica en una capa separada, y el navegador la decodifica junto al contenido de color cuando lee el archivo. Cuando el navegador descodifica un AVIF, produce tanto un búfer de color como una capa de transparencia alpha. La conversión compone ambos a plena transparencia, preservando cada detalle parcialmente transparente. El WebP escribe luego un archivo con pérdida cuyo capa de transparencia se guarda con el algoritmo sin pérdida del WebP específico para el plano alpha. El resultado es que la capa de transparencia alpha en el WebP de salida se guarda sin pérdida respecto a los valores alpha descodificados del AVIF. Los degradados suaves y los bordes difuminados sobreviven. La única degradación del alpha presente es la que introdujo la codificación original del AVIF. Si el AVIF de origen tiene bordes alpha limpios, el WebP de salida también los tendrá, con la misma capa de transparencia lista para la composición sobre cualquier fondo.
Comparar la salida con las alternativas
Cuando necesitas hacer un AVIF compatible con un sistema que no lo lee, tienes tres opciones realistas: convertir a WebP, a PNG o a JPG. El JPG es la opción equivocada para cualquier recurso con transparencia, porque no tiene capa de transparencia y la aplana a un color sólido. El PNG produce el archivo más grande, normalmente de tres a diez veces el tamaño del AVIF, y es la opción correcta solo cuando necesitas un intermedio sin pérdida o el destino exige PNG en concreto. El WebP queda en medio: ofrece compatibilidad moderna universal, conserva la transparencia y produce un archivo normalmente entre un 20 y un 25 por ciento más grande que el AVIF en lugar de entre un 300 y un 1000 por ciento como el PNG. Para cualquier conversión de compatibilidad que no requiera una salida sin pérdida, el WebP es el intermedio correcto.
Una sola en el navegador, lotes en un servidor
Este par corre de dos maneras según el trabajo. Un AVIF solo se decodifica y se vuelve a guardar como WebP enteramente dentro de tu navegador por caminos nativos, así que para un archivo no hay subida ninguna, confirmado con cero solicitudes salientes tras cargar la página. Es el camino correcto para algo rápido y para trabajo de cliente confidencial, imágenes de producto propias o documentos que prefieres mantener en tu máquina. Convertir varios archivos a la vez se hace en nuestro servidor. Agrupar, comprimir y entregar un conjunto es la tarea que un servidor hace bien: los archivos suben, se codifican, se empaquetan y se devuelven como una descarga, que se borra en unas 2 horas, sin necesidad de cuenta y sin almacenamiento a largo plazo. En la práctica: una conversión sola nunca sale del dispositivo, y un lote se procesa en remoto pero se guarda solo por la breve ventana que tarda en descargarse.
