Imágenes WebP/AVIF en WordPress no se muestran: causas y configuración correcta

Guía rápida de diagnóstico

Si tienes cinco minutos antes de que alguien declare un “incidente mayor”, haz esto en orden. El objetivo es encontrar rápidamente el cuello de botella: ¿el navegador rechaza los bytes, el servidor devuelve cabeceras incorrectas o un CDN almacena la variante equivocada?

Primero: confirma qué está recibiendo el navegador

1. Abre DevTools → Network → haz clic en la petición de imagen que falla.
2. Revisa Status (200/304/403/404/500), Content-Type, Content-Length y cualquier error como “CORB”, “MIME type mismatch” o “Failed to decode image”.
3. Mira el cuerpo en Response: ¿es realmente una imagen, o HTML (como una página 403, página de inicio de sesión o un bloqueo WAF)?

Segundo: reproduce con curl desde un punto limpio

1. Obtén la URL con cabeceras: confirma Content-Type: image/webp o image/avif, no text/html.
2. Prueba con y sin cabeceras Accept para detectar negociación de contenido rota.
3. Compara la respuesta del borde del CDN con la respuesta del origen.

Tercero: verifica claves de caché y lógica de variantes

1. ¿El CDN varía la caché según Accept? Si no, una petición desafortunada puede envenenar la caché (servir WebP a un cliente que no lo soporta, o viceversa).
2. ¿Un plugin de WordPress reescribe URLs a .webp/.avif sin asegurarse de que los archivos existan?
3. ¿El servidor envía el Content-Type incorrecto para .webp/.avif?

Cuarto: sólo entonces toca WordPress

1. Inspecciona el HTML generado: src, srcset, orden de picture/source.
2. Revisa plugins que hacen conversión, lazy-load, offload a CDN y caché/minificación. Desactiva uno a la vez.
3. Verifica que los archivos existan donde WordPress cree que están (wp-content/uploads o almacenamiento offload).

Qué falla realmente cuando WebP/AVIF no se muestran

Los navegadores son tolerantes con muchas cosas. La decodificación de imágenes no es una de ellas. Cuando una imagen “no se muestra”, suele pertenecer a una de cuatro categorías:

• Bytes incorrectos: La URL termina en .webp pero devuelve bytes JPEG (o HTML). Algunos navegadores intentan, la mayoría se niegan.
• Cabeceras incorrectas: Bytes correctos, Content-Type errado (como text/plain) provoca comportamiento estricto o rompe intermediarios.
• Variante equivocada: El CDN cachea AVIF y lo sirve a un cliente que sólo soporta WebP/JPEG, porque la clave de caché ignoró Accept.
• HTML equivocado: Tu marcado apunta directamente a .avif sin fallback, o el plugin arruinó el srcset.

También está la “quinta categoría”: tienes un WAF o protección de hotlink que bloquea peticiones sin Referer, y ahora tu plugin de optimización está solicitando imágenes de una manera que activa la regla. A los productos de seguridad les encanta ser “útiles” así.

Una cita que vale la pena pegar en una nota adhesiva, porque aplica a todos estos fallos: “La esperanza no es una estrategia.” — Vernon Sanders, citado en círculos de operaciones (idea parafraseada). No vas a adivinar la solución; vas a observar y confirmar.

Hechos e historia corta que te ayudan a depurar

Esto no es trivia para un quiz de bar. Explican por qué tu stack se comporta como lo hace.

1. WebP salió de Google en 2010 como un formato derivado de VP8; las lagunas iniciales en soporte crearon años de supuestos “funciona en Chrome”.
2. AVIF se basa en AV1 (el códec de vídeo). Las imágenes fijas heredan la eficiencia y la complejidad de AV1, lo que importa para CPU y tiempo de conversión.
3. El soporte de WebP en Safari llegó tarde (Safari 14). Muchas instalaciones antiguas de WordPress aún tienen atajos “si Safari entonces JPEG” como minas antipersona.
4. El soporte de AVIF es más reciente y fragmentado; algunos navegadores lo soportan, algunos dispositivos tienen decodificadores parciales o con errores, y algunos entornos corporativos congelan versiones de navegador.
5. Servir formatos modernos suele hacerse por negociación de contenido usando la cabecera Accept, lo que se rompe de forma espectacular si las cachés no varían correctamente.
6. WordPress históricamente restringió tipos MIME de subida; las versiones modernas soportan WebP, pero las librerías del servidor (GD/Imagick) podrían no hacerlo.
7. Los CDN pueden “ayudar” convirtiendo imágenes automáticamente, pero eso puede entrar en conflicto con plugins de WordPress que hacen lo mismo, llevando a doble optimización o variantes equivocadas.
8. AVIF puede ser más pequeño que WebP, pero más lento de codificar. Los equipos suelen descubrirlo durante un despliegue. El mal timing también es un formato.
9. Muchísimos incidentes de imágenes rotas son en realidad errores HTML servidos con estado 200; el navegador recupera “una imagen” y obtiene una página de login.

Broma #1: WebP no es “a prueba de web”. Si lo fuera, no estaríamos aquí, y yo estaría escribiendo sobre algo relajante, como BGP.

Modos de fallo: navegador, servidor, CDN, WordPress

1) Fallo en el navegador: error de decodificación o formato no soportado

Si codificas directamente .avif en <img src> sin fallback, un navegador sin AVIF no degradará de forma educada. Mostrará nada. El patrón correcto es <picture> con entradas <source type> ordenadas y finalmente un <img> como fallback.

Otro fallo del lado del navegador: archivos corruptos. Ocurre cuando la conversión se interrumpe, o cuando un plugin escribió salida parcial y aun así actualizó los metadatos.

2) Fallo en el servidor: tipos MIME erróneos, módulos faltantes, reescrituras malas

Servir WebP/AVIF no es difícil, pero es fácil equivocarse de forma que parece correcto a simple vista.

• MIME faltante: El servidor devuelve application/octet-stream o text/plain. Algunos navegadores aún renderizan; algunos intermediarios no.
• Reglas de reescritura demasiado inteligentes: Reescribes .jpg a .webp incondicionalmente. Si el .webp no existe, devuelves 404 en todo el sitio.
• Manejador de ficheros estáticos vs PHP: Un bloque de ubicación mal configurado envía .webp a través de PHP (lento) o lo bloquea por reglas de seguridad.

3) Fallo en el CDN: envenenamiento de caché por desajuste de variante

Este es el grande. Tu origen hace lo correcto: si Accept incluye image/avif, sirve AVIF; si no, WebP; si no, JPEG. Luego tu CDN cachea la primera respuesta que ve bajo una clave solo por URL. El siguiente cliente recibe el AVIF cacheado aunque no soporte AVIF. Boom: imágenes rotas, pero solo para algunos usuarios, y solo a veces. Perfecto para arruinar tardes.

4) Fallo en WordPress: plugins que reescriben URLs y metadatos

WordPress no hace por sí mismo negociación completa de contenido para formatos modernos. La mayoría de sitios dependen de un plugin o una función del CDN. Los plugins varían mucho en calidad. Puntos comunes de fallo:

• Generan .webp/.avif pero no actualizan srcset correctamente.
• Actualizan referencias en la BD pero no regeneran miniaturas.
• No respetan medios offload (almacenamiento compatible con S3) y generan rutas locales que jamás existirán.
• Entrar en conflicto con plugins de caché/minify que reescriben el HTML después.

Tareas prácticas (comandos, salidas, decisiones)

A continuación hay comprobaciones reales que puedes ejecutar. Cada una incluye: un comando, la salida que importa y qué decisión tomar a continuación. Ejecútalas desde una shell del servidor (o tu portátil para comprobaciones con curl). No “cambies cosas para ver si mejora”. Observa primero.

Tarea 1: Confirma que la URL que falla devuelve una imagen real (no HTML)

cr0x@server:~$ curl -sS -D - -o /tmp/img.bin "https://example.com/wp-content/uploads/2025/11/hero.avif" | sed -n '1,12p'
HTTP/2 200
date: Sat, 27 Dec 2025 10:12:01 GMT
content-type: image/avif
content-length: 48231
cache-control: public, max-age=31536000
etag: "a1b2c3"

Qué significa: El estado es 200 y content-type coincide con AVIF. Buena señal.

Decisión: Si content-type es text/html o el fichero es pequeño (por ejemplo 1–5 KB), abre el cuerpo: probablemente estés recibiendo una página de error, bloqueo WAF o una cadena de redirecciones.

Tarea 2: Identifica el tipo de archivo por sus magic bytes (no confíes en extensiones)

cr0x@server:~$ file -b /tmp/img.bin
ISO Media, AVIF Image

Qué significa: Los bytes son realmente AVIF.

Decisión: Si dice “HTML document” o “JPEG image data”, tienes confusión entre reescrituras/CDN/origen. Arregla eso antes de tocar WordPress.

Tarea 3: Comprueba qué pasa para clientes sin soporte AVIF/WebP

cr0x@server:~$ curl -sS -D - -o /dev/null -H "Accept: image/png,image/*;q=0.8,*/*;q=0.5" "https://example.com/wp-content/uploads/2025/11/hero"
HTTP/2 200
content-type: image/jpeg
vary: Accept

Qué significa: El servidor negocia y devuelve JPEG, y envía Vary: Accept. Eso es lo que deseas.

Decisión: Si no hay Vary: Accept, tu CDN puede cachear la variante equivocada a menos que lo configures explícitamente. Añade Vary y asegúrate de que el CDN lo respete (o usa URLs separadas por formato).

Tarea 4: Compara cabeceras entre el borde del CDN y el origen

cr0x@server:~$ curl -sS -D - -o /dev/null -H "Accept: image/avif,image/webp,*/*" "https://example.com/wp-content/uploads/2025/11/hero.jpg" | egrep -i 'content-type|vary|cache-control|cf-cache-status|x-cache|age'
content-type: image/avif
vary: Accept
cache-control: public, max-age=31536000
age: 8421
x-cache: HIT

Qué significa: El CDN está sirviendo AVIF desde caché (HIT), y Vary está presente.

Decisión: Si la respuesta de borde difiere del origen (content-type equivocado, vary faltante), purga el CDN y arregla la clave de caché / manejo de vary. No sigas purgando como estilo de vida.

Tarea 5: Valida que nginx conoce los tipos MIME de WebP/AVIF

cr0x@server:~$ nginx -T 2>/dev/null | sed -n '/types {/,/}/p' | egrep -n 'image/webp|image/avif' || echo "missing"
missing

Qué significa: La configuración de nginx no define WebP/AVIF en su mapeo de types.

Decisión: Añade tipos MIME en el lugar correcto (a menudo /etc/nginx/mime.types o un archivo incluido), recarga nginx y vuelve a probar las cabeceras.

Tarea 6: Confirma que Apache sirve tipos MIME correctos

cr0x@server:~$ apachectl -M 2>/dev/null | egrep 'mime|headers'
 mime_module (shared)
 headers_module (shared)

Qué significa: Apache tiene los módulos necesarios para reglas AddType y Header.

Decisión: Si mime_module falta, Apache puede servir tipos desconocidos incorrectamente. Actívalo y define AddType image/webp .webp y AddType image/avif .avif.

Tarea 7: Comprueba si el servidor está comprimendo imágenes por error

cr0x@server:~$ curl -sS -D - -o /dev/null -H "Accept: image/avif" "https://example.com/wp-content/uploads/2025/11/hero.avif" | egrep -i 'content-encoding|content-type'
content-type: image/avif

Qué significa: No hay Content-Encoding: gzip (bien). Comprimir formatos ya comprimidos es inútil y a veces dañino con intermediarios defectuosos.

Decisión: Si ves content-encoding: gzip para imágenes, corrige las reglas de compresión para excluir image/* (especialmente WebP/AVIF).

Tarea 8: Confirma que el archivo existe en disco (sanidad del origen)

cr0x@server:~$ sudo ls -lh /var/www/html/wp-content/uploads/2025/11/hero.avif
-rw-r--r-- 1 www-data www-data 48K Nov 20 09:14 /var/www/html/wp-content/uploads/2025/11/hero.avif

Qué significa: El origen tiene el archivo, los permisos parecen normales.

Decisión: Si falta, el plugin nunca lo generó, o externalizaste medios y olvidaste que el sistema de archivos del origen no es la fuente de verdad.

Tarea 9: Detecta conversiones parciales/corrompidas con ffmpeg o avifdec

cr0x@server:~$ ffmpeg -v error -i /var/www/html/wp-content/uploads/2025/11/hero.avif -f null - 2>&1 | head

Qué significa: No hay salida indica que ffmpeg pudo parsear y decodificar sin errores.

Decisión: Si ves errores de decodificación, regenera ese activo e investiga la cadena de herramientas del conversor (CPU/memoria/timeouts).

Tarea 10: Verifica que WordPress cree que los metadatos del adjunto son coherentes

cr0x@server:~$ wp post meta get 123 _wp_attachment_metadata --format=json | head -c 220; echo
{"width":2400,"height":1600,"file":"2025/11/hero.jpg","sizes":{"thumbnail":{"file":"hero-150x150.jpg","width":150,"height":150,"mime-type":"image/jpeg"}...

Qué significa: Los metadatos de WordPress hacen referencia al JPEG original y a sus tamaños derivados. Muchos plugins almacenan WebP/AVIF por separado.

Decisión: Si los metadatos apuntan a .webp/.avif pero los archivos no existen (o viceversa), tienes una descoordinación. Regenera miniaturas y vuelve a ejecutar la optimización masiva del plugin con ajustes correctos.

Tarea 11: Inspecciona el HTML renderizado para picture, srcset y su orden

cr0x@server:~$ curl -sS "https://example.com/" | sed -n '1,220p' | egrep -n '
119:  
120:  
121:  
122:

Qué significa: Esto es correcto: AVIF primero, WebP segundo, JPEG fallback al final.

Decisión: Si ves <img src="...avif"> sin fallback, arregla el tema/plugin. Si type es incorrecto o falta, algunos navegadores no seleccionarán la fuente.

Tarea 12: Detecta “bloqueado por WAF/protección hotlink” que finge ser imágenes

cr0x@server:~$ curl -sS -D - -o - "https://example.com/wp-content/uploads/2025/11/hero.webp" | sed -n '1,25p'
HTTP/2 403
content-type: text/html; charset=UTF-8
server: nginx
...
<html><head><title>Access denied</title></head>...

Qué significa: 403 con cuerpo HTML. El navegador pidió una imagen y recibió una página de denegación.

Decisión: Ajusta reglas WAF, protección hotlink o lógica de URL firmadas para que las peticiones legítimas de imágenes estén permitidas. También asegúrate de que tu optimizador no esté solicitando imágenes con cabeceras extrañas que activen los bloqueos.

Tarea 13: Verifica que CDN/origen devuelvan Content-Length correcto y soporten requests por rangos

cr0x@server:~$ curl -sS -D - -o /dev/null -H "Range: bytes=0-1023" "https://example.com/wp-content/uploads/2025/11/hero.webp" | egrep -i 'http/|content-type|content-range|accept-ranges'
HTTP/2 206
content-type: image/webp
accept-ranges: bytes
content-range: bytes 0-1023/61244

Qué significa: Las peticiones por rango funcionan. Esto importa para algunos clientes, intermediarios y comportamiento de rendimiento.

Decisión: Si los rangos fallan y tu CDN los espera, puedes tener cargas parciales o comportamiento extraño en clientes. Arregla el manejo de ficheros estáticos y la configuración de proxy del servidor.

Tarea 14: Confirma soporte de conversión en librerías PHP (GD/Imagick)

cr0x@server:~$ php -r 'echo "GD: ".(function_exists("gd_info")?gd_info()["GD Version"]:"missing").PHP_EOL;'
GD: bundled (2.1.0 compatible)

cr0x@server:~$ php -r 'print_r(function_exists("gd_info")?gd_info():["gd"=>"missing"]);' | egrep -i 'WebP Support|AVIF Support|JPEG Support'
WebP Support => 1
AVIF Support => 0
JPEG Support => 1

Qué significa: GD puede escribir WebP pero no AVIF. Muchos plugins de WordPress hacen fallback silencioso o generan solo algunos formatos.

Decisión: Si necesitas AVIF, usa un conversor que lo soporte (a menudo via Imagick con libheif, o herramientas externas), o delega la conversión al CDN y mantén el origen como JPEG/PNG/WebP.

Tarea 15: Revisa soporte de codecs en Imagick

cr0x@server:~$ php -r 'echo extension_loaded("imagick")?"imagick loaded\n":"imagick missing\n";'
imagick loaded

cr0x@server:~$ php -r '$i=new Imagick(); print_r($i->queryFormats());' | egrep -E 'WEBP|AVIF|HEIC' | head
AVIF
WEBP

Qué significa: Imagick soporta AVIF y WebP en este host. Es razón para celebrarlo en voz baja.

Decisión: Si AVIF falta, puedes instalar/compilar Imagick con soporte libheif, o dejar de prometer AVIF desde el origen y usar WebP + fallback JPEG.

Tarea 16: Busca reglas de reescritura que fuerzan .webp incluso cuando faltan

cr0x@server:~$ sudo nginx -T 2>/dev/null | egrep -n 'try_files|\.webp|Accept'
214:    if ($http_accept ~* "webp") {
215:        rewrite ^(.+)\.(jpe?g|png)$ $1.webp last;
216:    }

Qué significa: Esta reescritura es incondicional. Si hero.webp no existe, obtendrás 404.

Decisión: Sustituye reescrituras por lógica try_files que compruebe existencia y haga fallback con seguridad.

Configuración correcta: sensata, aburrida, fiable

Quieres formatos modernos sin drama. Aquí está la configuración que sobrevive al tráfico, CDNs y actualizaciones de plugins.

Principio 1: Prefiere <picture> sobre reescritura de URLs

Si puedes controlar la generación del marcado (a nivel de tema o con un plugin bien hecho), usa:

• <source type="image/avif"> primero
• <source type="image/webp"> segundo
• <img src="...jpg/png"> como fallback

Esto evita la complejidad de claves de caché porque los formatos diferentes pueden tener URLs distintas. No es tan “ingenioso”, y ese es el punto.

Principio 2: Si haces negociación de contenido, trata la caché como característica de primera clase

La negociación de contenido significa misma URL, bytes diferentes. Eso sólo funciona cuando:

• El origen envía Vary: Accept
• El CDN cachea por separado según Accept (o configuras claves de caché separadas)
• Tienes una estrategia de purga cuando cambias ajustes de conversión

Sin esto, la negociación se convierte en “lotería de imágenes aleatoria”.

Principio 3: No exijas AVIF si no puedes producirlo de forma fiable

AVIF es excelente. También es un poco diva en entornos de servidor: necesitas las librerías adecuadas y la conversión es intensiva en CPU. Si no puedes garantizar finalización de la conversión y cabeceras correctas, usa WebP primero y trata AVIF como opcional.

Configuración del servidor: nginx (mínimo, correcto)

Asegúrate de que nginx conozca los tipos MIME. En tu mime.types o bloque http:

cr0x@server:~$ sudo sed -n '1,120p' /etc/nginx/mime.types | tail -n 12
    image/webp                           webp;
    image/avif                           avif;

Si debes mapear JPEG/PNG a WebP cuando esté disponible, hazlo con try_files, no con reescritura incondicional. Patrón de ejemplo (conceptual; adapta con cuidado a tus rutas):

cr0x@server:~$ sudo nginx -T 2>/dev/null | sed -n '180,260p'
location ~* \.(png|jpe?g)$ {
    add_header Vary Accept;
    set $webp_suffix "";
    if ($http_accept ~* "image/webp") {
        set $webp_suffix ".webp";
    }
    try_files $uri$webp_suffix $uri =404;
}

Por qué funciona: Sólo sirve .webp si existe. De lo contrario sirve el original. No hay tormentas de 404.

Configuración del servidor: Apache (mínimo, correcto)

Define tipos MIME y asegúrate de que el módulo de cabeceras esté disponible. En una configuración de Apache o .htaccess (si está permitido):

cr0x@server:~$ sudo apachectl -t -D DUMP_INCLUDES 2>/dev/null | head
Included configuration files:
  (/etc/apache2/apache2.conf)
  (/etc/apache2/conf-enabled/*.conf)
  (/etc/apache2/sites-enabled/000-default.conf)

Luego añade tipos (donde proceda):

cr0x@server:~$ sudo sed -n '1,60p' /etc/apache2/mods-enabled/mime.conf | tail -n 10
AddType image/webp .webp
AddType image/avif .avif

Configuración de WordPress: decide quién se encarga de la conversión

Tienes tres modelos de propiedad viables. Elige uno y comprométete. Mezclarlos crea errores fantasmas.

1. Plugin se encarga de la conversión, origen sirve formatos modernos estáticos: Lo más común. Funciona si tu servidor tiene las librerías y gestionas invalidación de caché.
2. CDN se encarga de la conversión: Origen almacena JPEG/PNG, CDN sirve WebP/AVIF a clientes capaces. Menos carga en tus servidores, menos problemas de librerías. Requiere disciplina en la configuración del CDN.
3. La canalización de build se encarga de la conversión: Conviertes las imágenes antes de subir/desplegar. Ideal para sitios de marca y flujos controlados, menos para contenido generado por usuarios.

Elige una estrategia de fallback y pruébala como si la producción dependiera de ello (porque sí)

Comportamiento mínimo aceptable:

• Cualquier cliente recibe una imagen (JPEG/PNG en el peor de los casos).
• Ningún plugin debe reemplazar la única URL por una URL AVIF sin fallback.
• La conversión fallida no debe romper páginas existentes (sirve el formato antiguo mientras se procesa el nuevo).

Broma #2: Lo único “sin pérdidas” en la optimización de imágenes es tu paciencia cuando la clave de caché ignora Accept.

Errores comunes (síntomas → causa raíz → solución)

1) Síntoma: Imágenes rotas sólo en Safari o dispositivos antiguos

Causa raíz: Estás sirviendo AVIF (o WebP) sin fallback, o el CDN cacheó AVIF y lo sirve a todos.

Solución: Usa <picture> con fallback JPEG, o asegura Vary: Accept y que la clave de caché del CDN varíe por Accept. Purga después de los cambios.

2) Síntoma: DevTools muestra 200 OK pero la imagen está en blanco

Causa raíz: El cuerpo de la respuesta no es una imagen (página de denegación HTML, bloqueo WAF, o “soft 404”) servida con 200 o 403.

Solución: Recupera con curl e inspecciona Content-Type y los magic bytes. Arregla reglas WAF/hotlink; asegura que rutas estáticas eviten autenticación y desafíos de seguridad.

3) Síntoma: Algunos usuarios ven imágenes, otros ven iconos rotos; purgar cachés “arregla” temporalmente

Causa raíz: Envenenamiento de caché del CDN por falta de vary/clave de caché correcta. La primera petición gana.

Solución: Configura el CDN para variar por Accept (o usa URLs separadas por formato). Asegura que el origen envíe Vary: Accept. Purga las rutas afectadas.

4) Síntoma: 404 para URLs .webp tras activar un plugin de optimización

Causa raíz: El plugin reescribió URLs a .webp pero no generó esos archivos (o falló a mitad de lote).

Solución: Desactiva la reescritura de URLs, ejecuta la generación masiva, confirma filesystem/offload targets, luego reactiva. Añade un try_files seguro si insistes en reescrituras.

5) Síntoma: Las imágenes se descargan en lugar de mostrarse

Causa raíz: Content-Type incorrecto, a veces application/octet-stream.

Solución: Añade tipos MIME correctos en nginx/Apache. Vuelve a probar cabeceras. Algunos CDN también necesitan mapeo explícito de tipos.

6) Síntoma: Las miniaturas están rotas pero las imágenes originales cargan

Causa raíz: No se convirtieron/regeneraron los tamaños derivados; srcset apunta a variantes inexistentes.

Solución: Regenera miniaturas; vuelve a ejecutar el conversor para todos los tamaños; verifica metadatos para una muestra de adjuntos.

7) Síntoma: Picos de CPU al activar AVIF; páginas se agotan

Causa raíz: La conversión se ejecuta bajo demanda durante las peticiones, o trabajos por lotes consumen la host. La codificación AVIF es costosa.

Solución: Haz la conversión offline/por lotes con límites; usa workers en cola; o deja que el CDN haga la conversión. Pon topes estrictos al número de codificaciones concurrentes.

8) Síntoma: Sólo el admin ve imágenes correctas; usuarios anon no

Causa raíz: La caché varía por cookies/auth, o el plugin de optimización omite conversión para usuarios logueados, o el CDN sirve variantes diferentes.

Solución: Compara respuestas con/sin cookies. Arregla reglas de caché y asegura que la misma URL resuelva al activo correcto para tráfico anónimo.

Listas de verificación / plan paso a paso

Paso a paso: llegar a una línea base correcta (sin heroísmos)

1. Elige propiedad: plugin, CDN o pipeline de build. No ejecutes dos conversores a la vez.
2. Establece HTML de fallback: prefiere <picture> con fallback JPEG/PNG.
3. Corrige tipos MIME: asegura image/webp y image/avif correctos en origen y CDN.
4. Confirma que los bytes coincidan con las cabeceras: file sobre contenido descargado; no páginas de error HTML.
5. Corrige variación de caché: si negocias por Accept, debes usar Vary: Accept y que el CDN varíe la clave de caché.
6. Regenera derivados: las miniaturas y tamaños responsive son donde se esconden fallos silenciosos.
7. Prueba la carga del flujo de conversión: las codificaciones AVIF pueden saturar CPU. Planifica a dónde va el calor.
8. Configura monitorización: sigue tasas 404/403 en .webp/.avif, y mismatches de Content-Type si puedes.

Checklist de lanzamiento para habilitar AVIF/WebP en producción

• Al menos tres perfiles de navegador probados: capaz de AVIF, sólo WebP, y ninguno (prueba forzada de cabecera Accept).
• Clave de caché del CDN verificada para comportamiento de variantes, o uso de URLs separadas por formato.
• El origen devuelve tipos MIME correctos y no gzippea imágenes.
• Los trabajos de conversión están fuera de la ruta de la petición o estrictamente limitados.
• Plan de rollback: desactivar reescrituras/negociación sin romper URLs de imágenes.

Cuando algo está roto: checklist de contención

• Detén la hemorragia: desactiva reescrituras de URL que fuerzan .avif/.webp si los archivos no están garantizados.
• Purga cachés del CDN sólo para rutas afectadas (no purgues todo a menos que te guste provocar outages).
• Vuelve al markup con fallback JPEG/PNG si tu tema/plugin lo soporta.
• Confirma que las respuestas 200 son imágenes reales (no HTML).

Tres micro-historias corporativas desde el campo

Micro-historia 1: El incidente causado por una suposición equivocada

Un sitio de comercio mediano quiso “imágenes modernas por todas partes”. El plan sonaba limpio: habilitar conversión AVIF en el plugin de optimización, activar reescrituras nginx para que .jpg pase a .avif en navegadores compatibles, y dejar que el CDN hiciera lo suyo.

Alguien supuso que el CDN variaba la caché por Accept. No lo hizo, al menos no para esa regla de caché. La primera petición tras el deploy vino de un cliente Chrome que anunciaba soporte AVIF. El CDN cacheó la respuesta AVIF bajo la URL JPEG.

La siguiente ola de tráfico incluyó navegadores embebidos en apps móviles y dispositivos antiguos. Solicitaron la misma URL JPEG, recibieron bytes AVIF y no pudieron decodificar. El dashboard de incidentes mostró “fallos de carga de imágenes” pero la salud del origen estaba en verde. Porque claro que lo estaba.

La solución no fue mágica: configurar la variación de caché correctamente (o dejar de negociar en la misma URL), purgar los objetos envenenados y añadir una prueba que haga curl a un conjunto representativo de URLs de imagen con distintas cabeceras Accept antes de cada despliegue. La lección no fue “no uses AVIF”. Fue “no externalices tus suposiciones a una caché”.

Micro-historia 2: La optimización que salió mal

Una plataforma interna de comunicaciones había crecido lo suficiente como para que el almacenamiento de medios fuera una partida real del presupuesto. Alguien propuso AVIF agresivo para todo, con conversión bajo demanda: cuando un usuario ve una página por primera vez, el servidor convierte variantes AVIF faltantes y las cachea. “Repartiría el trabajo”.

Lo repartió. Lamentablemente, lo repartió sobre la capa web en horas punta. La librería de conversión consumía mucha CPU. Las peticiones se encolaron. Los workers PHP quedaron bloqueados esperando conversiones y escrituras en disco. La latencia subió, luego los timeouts, luego la capa de caché empezó a reintentar upstream, lo cual nunca es una historia de amor.

Peor aún, algunas conversiones se interrumpieron. Se escribieron archivos parciales, pero la actualización de metadatos tuvo éxito. Algunos usuarios recibieron AVIF corruptos servidos con un Content-Type correcto. Esos son los fallos más molestos porque se ven “bien” hasta que realmente decodificas los bytes.

El rollback fue simple: detener la conversión bajo demanda, moverla a una cola controlada con límites de concurrencia y servir WebP/JPEG hasta que las variantes estén listas. El ahorro de disco volvió, pero ahora el sistema dejó de intentar incendiarse para ahorrar unos kilobytes.

Micro-historia 3: La práctica aburrida que salvó el día

Una editorial gestionaba varias propiedades WordPress detrás del mismo CDN. Tenían una regla que sonaba dolorosamente poco sexy: cada nuevo tipo de activo recibe una “prueba de contrato de cabeceras” en CI. Verifica códigos de estado, Content-Type, Cache-Control y comportamiento de variantes con distintas cabeceras Accept.

Cuando añadieron WebP y luego AVIF, no simplemente activaron el toggle del plugin y rezaron. Desplegaron a un dominio de staging que usaba la misma configuración de CDN que producción. El job de CI recuperó un conjunto canónico de imágenes a través del CDN y directamente del origen, comparó cabeceras y falló el build si divergían.

En el primer ensayo AVIF, la prueba falló: el CDN había eliminado Vary: Accept en una regla de caché basada en ruta. Nadie lo notó en pruebas manuales porque sus navegadores eran modernos. La prueba lo notó, porque forzó una cabecera Accept que excluía AVIF y esperaba un fallback JPEG.

Arreglaron la regla del CDN antes de que los usuarios lo vieran. Nada explotó. Nadie fue alertado. Eso es lo que compra lo “aburrido”: sueño y credibilidad.

Preguntas frecuentes

1) ¿Debería servir AVIF, WebP o ambos?

Ambos, si puedes hacerlo de forma fiable. AVIF primero para clientes compatibles, WebP segundo, fallback JPEG/PNG al final. Si tu servidor no puede codificar AVIF de forma fiable, sirve WebP + JPEG y deja AVIF opcional (lado CDN es una solución común).

2) ¿Por qué obtengo 200 OK pero la imagen aún no se muestra?

Porque “200” no es una promesa de que los bytes sean una imagen. Revisa Content-Type e inspecciona el cuerpo. Una página de login 200 servida en una URL de imagen seguirá siendo una imagen rota.

3) ¿Necesito añadir tipos MIME para WebP y AVIF?

Sí. Muchos servidores no lo adivinan correctamente. Quieres image/webp y image/avif. Tipos MIME equivocados pueden causar descargas, renderizado bloqueado o comportamiento extraño en CDNs.

4) ¿Puedo confiar solo en un plugin de WordPress?

Puedes, pero verifica toda la canalización: soporte de herramientas de conversión (GD/Imagick), regeneración de miniaturas y cómo el plugin reescribe HTML/URLs. Los plugins suelen funcionar perfectamente hasta que añades un CDN, offload de medios u otro plugin “útil”.

5) ¿Cuál es la forma más segura de implementar formatos modernos en WordPress?

Usa marcado <picture> y URLs distintas por formato. Evita la complejidad de variación de caché. Si necesitas negociación, trata Vary: Accept y claves de caché como requisitos no negociables.

6) Mi CDN dice que soporta WebP/AVIF automáticamente. ¿Por qué las imágenes están rotas?

Porque “soporta” puede significar “puede convertir”, no “variará la caché correctamente para tus reglas”. Confirma el comportamiento de la clave de caché, confirma Vary: Accept y verifica si tu origen ya hace la conversión: doble conversión y confusión de variantes son comunes.

7) ¿Por qué sólo fallan las miniaturas?

Porque las miniaturas son archivos separados. Tu original puede haber sido convertido, pero los tamaños derivados usados por srcset no se generaron o se generaron en otra ubicación (especialmente con medios offload).

8) ¿AVIF siempre es más pequeño que WebP?

A menudo, pero no siempre. El contenido importa. AVIF puede ser excelente para fotos, pero puede ser más lento de codificar y a veces no merece la pena para pequeños assets de UI. Mide; no asumas.

9) ¿Por qué al habilitar AVIF sube la CPU y se ralentiza el sitio?

Porque la codificación es costosa. Si las conversiones ocurren durante la petición, has puesto una carga de códec de vídeo en tu capa web. Mueve la conversión a trabajos en background, limita la concurrencia o externaliza la conversión al CDN.

10) ¿Necesito purgar cachés después de habilitar WebP/AVIF?

Normalmente sí—especialmente si cambiaste reescrituras de URL, reglas de negociación o comportamiento del CDN. De lo contrario podrías servir variantes obsoletas o mantener un objeto de caché envenenado vivo más tiempo del que te apetece.

Próximos pasos que puedes hacer hoy

Si las imágenes WebP/AVIF no se muestran, no empieces por reinstalar plugins. Comienza confirmando qué bytes se están sirviendo, con qué cabeceras y quién los cachea.

1. Elige una URL de imagen rota y ejecuta las comprobaciones curl + file. Confirma: estado, Content-Type y magic bytes concuerdan.
2. Si usas negociación de contenido, verifica Vary: Accept y comportamiento de la clave de caché del CDN. Si no puedes garantizarlo, cambia a <picture> con URLs separadas por formato.
3. Confirma tipos MIME de servidor para .webp y .avif. Arréglalos en origen; no confíes en “el CDN lo solucionará”.
4. Audiota tus plugins de WordPress: un conversor, un reescritor HTML, un plugin de caché (o al menos, uno que esté al mando). Todo lo demás es una competición de quién rompe el marcado al final.
5. Regenera miniaturas y valida srcset para algunas muestras representativas de adjuntos.

Los formatos modernos merecen la pena. Sólo no los implementes como un truco de magia. Hazlo como un operador: comportamiento observable, fallbacks seguros y cachés configuradas—no deseadas.