¿Imágenes rotas o carga irregular tras convertir activos a WebP o AVIF? Quien gestiona un WordPress en entornos gestionados o Multisite suele detectar errores al subir o mostrar imágenes, diferencias entre navegadores y caídas de velocidad que afectan SEO y conversión.
Problemas con WebP y formatos modernos: Si tu WordPress falla con WebP o formatos modernos, primero identifica compatibilidad de navegador, MIME y cabeceras del servidor; después aplica fallback con o srcset, ajusta .htaccess/nginx y configura CDN. Sigue el playbook técnico para diagnóstico rápido, despliegue seguro en Multisite y validación con tests HTTP.
Resumen del proceso y pasos rápidos
En 30–90 minutos se consigue diagnóstico claro y una solución temporal en HTML. Luego se despliega la corrección en servidor y CDN para producción.
- Diagnóstico HTTP y navegador: probar con curl y DevTools.
- Ajustar MIME y reescrituras en Apache/nginx.
- Forzar Vary y Cache-Control en servidor y CDN.
- Añadir fallback con y srcset en plantillas.
- Pre-generar WebP/AVIF en CI o usar edge conversion.
- Probar en navegadores reales y purgar cachés.
Paso 1: diagnóstico HTTP y navegador
La idea central: confirmar si el servidor entrega el formato correcto y si el CDN o proxy altera las cabeceras. Comprueba Content-Type, Vary y respuestas con y sin Accept.
Pruebas con curl
Usa curl para simular navegadores que piden WebP y para comparar respuestas. Prueba ambos comandos:
curl -I -H "Accept: image/webp,image/*" https://tu-dominio.com/wp-content/uploads/imagen.jpg
curl -I https://tu-dominio.com/wp-content/uploads/imagen.jpg
Mira las cabeceras Content-Type, Vary y Cache-Control. Si Content-Type no es image/webp cuando se solicita, la negociación falla.
Abre Chrome DevTools en Network y filtra por imágenes. Observa la columna "Type" y la respuesta real del servidor. Revisa también el tamaño descargado y la ruta final.
Logs y errores comunes
Consulta los logs de acceso y error del servidor y del CDN. Busca 404 para rutas .webp, 403 por permisos y 5xx por timeouts. El error más frecuente en este punto es la reescritura del plugin de caché que remapea rutas sin crear las WebP.
Configurar servidor, CDN y edge para servir WebP/AVIF
La idea central: añadir MIME y reglas de reescritura en el servidor que sirvan WebP/AVIF cuando existan, y asegurar que el CDN/edge no elimine la cabecera Vary (Accept) ni cambie o pierda Content-Type o metadata (Content-Type, Cache-Control). Configura la negociación en el edge si el CDN lo soporta, o bien preserva las cabeceras originales y los tipos MIME en el origen.
Servidor
- Apache (ejemplo .htaccess de WordPress): añade el MIME y reescrituras sencillas, y preserva Vary: Accept.
AddType image/webp .webp
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTP_ACCEPT} image/webp
RewriteCond %{REQUEST_FILENAME}.webp -f
RewriteRule (.+) $1.webp [T=image/webp]
</IfModule>
<IfModule mod_headers.c>
Header append Vary Accept env=!dont-vary
</IfModule>
Si el hosting no permite editar .htaccess, pasa al bloque de nginx o pide soporte.
- Nginx (configurar types y usar try_files con sufijo WebP):
types {
webp image/webp;
}
location ~* ^/wp-content/.+/.(png|jpe?g)$ {
add_header Vary "Accept" always;
set $webp_suffix "";
if ($http_accept ~* "image/webp") {
set $webp_suffix ".webp";
}
try_files $uri$webp_suffix $uri =404;
}
(El bloque define la asociación extensión→MIME correctamente y fuerza la cabecera Vary de forma explícita.)
No copies esto sin probar; pequeños hosts gestionados requieren ajustes.
CDN y edge
-
Principio general: el CDN no debe eliminar Vary ni modificar Content-Type. Si el CDN realiza conversión/optimización, configúralo para que respete Vary y la metadata del origen, o despliega la negociación en el edge (Workers, funciones edge) y deja los objetos almacenados con el Content-Type correcto.
-
Cloudflare
- Activa "Polish" o usa Workers para negociación de contenido. Si usas Workers, conserva explícitamente Vary y Content-Type al reenviar o al responder.
- Ejemplo simple de Worker (versión reducida) que reescribe a .webp según Accept. Asegúrate de que la respuesta preserve Vary y Content-Type:
addEventListener('fetch', event => {
event.respondWith(handle(event.request))
})
async function handle(req) {
const accept = req.headers.get('accept') || ''
const url = new URL(req.url)
if (accept.includes('image/webp') && url.pathname.match(//.(png|jpe?g)$/)) {
url.pathname = url.pathname + '.webp'
}
// Preserva las cabeceras originales al obtener del origen/edge
return fetch(url.toString(), { headers: req.headers })
}
- AWS S3 + CloudFront
- Al subir a S3, fija metadata Content-Type (por ejemplo image/webp) y Cache-Control (max-age, public) para que el edge lo almacene correctamente.
-
Para negociación en el edge usa Lambda@Edge que lea Accept y reescriba la ruta a .webp o .avif si existe (o haga un redirect interno). Asegúrate de que CloudFront respete Vary/Cache-Control y que la cache key tenga en cuenta headers relevantes si haces variaciones por Accept.
-
Cloudinary y servicios similares
- Usa delivery por parámetros (transformaciones) o por Accept-header si el proveedor lo soporta. Cloudinary y otros pueden servir WebP/AVIF automáticamente mediante transformaciones y cache; revisa la configuración para que no eliminen Vary ni cambien Content-Type.
Prácticas y advertencias
- Siempre preservar la cabecera Vary: Accept y el Content-Type correcto. Muchos problemas vienen de CDNs o proxies que eliminan o ignoran Vary, o de objetos en S3 sin Content-Type correcto.
- En entornos con CloudFront/S3: garantizar que los objetos en S3 tengan metadata Content-Type y Cache-Control adecuada; para negociación en edge despliega Lambda@Edge que examine Accept y reescriba o redirija a .webp/.avif según exista.
- No asumir que un snippet funcionará igual en todos los hosts: prueba en staging. Hosts gestionados o paneles de control pueden necesitar ajustes específicos.
- No copies sin probar: comportamientos de cache y headers varían entre servidores y CDNs; comprueba que las respuestas almacenadas en el CDN incluyen las cabeceras correctas y que los usuarios reciben el formato esperado.
Fallback HTML, accesibilidad y SEO
La idea central: ofrecer fallback en HTML evita dependencias del servidor o CDN y protege accesibilidad y SEO. Implementa <picture> y srcset con alt claros.
Ejemplo práctico con
Esta estructura asegura que navegadores sin soporte usan JPG/PNG. También mejora SEO porque los robots ven el img final.
Lazy loading y WCAG
No elimines alt por ahorrar bytes. Si usas lazy loading asegúrate de que noscript muestre la imagen para usuarios sin JavaScript. Robots como Googlebot necesitan acceder a las imágenes para indexarlas.
El fallo más común no está en WordPress sino en la capa servidor/CDN: cuando falta `Content-Type: image/webp` o `Vary: Accept` la negociación se rompe y el navegador recibe la versión incorrecta o una 404.
Para imágenes responsivas conviene combinar con srcset y tamaños (sizes) para ofrecer variantes por resolución y DPR: por ejemplo, con seguido de un y un . Esta estructura permite que navegadores con soporte usen AVIF o WebP en la resolución adecuada y que otros caigan al JPG/PNG; además reduce transferencia si se combinan con Cache-Control y una negociación de contenido correcta (Vary: Accept).
Al medir con DevTools y curl se observa claramente la reducción de bytes cuando el navegador solicita la variante adecuada, y el uso de srcset evita servir imágenes sobredimensionadas en dispositivos móviles.
La idea central: WebP tiene compatibilidad muy amplia desde hace tiempo; AVIF crece rápido pero exige más CPU al convertir. Mide antes de desplegar en masa.
Estado real de soporte
En la actualidad, más del 95% de los navegadores soportan WebP. AVIF supera el 85% de soporte en navegadores de escritorio. Google y Mozilla publican guías sobre imágenes y rendimiento que confirman estas tendencias. Consultas de compatibilidad
Esto funciona bien en teoría, pero en la práctica AVIF puede multiplicar el tiempo de conversión por 2–4 veces en máquinas de bajo CPU.
Matriz comparativa
| Formato |
Compatibilidad (2024) |
Compresión vs JPG |
CPU conversión |
Uso recomendado |
| WebP |
>95% |
20–40% mejor |
Baja |
Assets generales |
| AVIF |
~85–90% |
30–60% mejor |
Media–Alta |
Hero images, fotos críticas |
| JPEG/PNG |
100% |
Base |
N/A |
Fallback y compatibilidad total |
Benchmark real rápido
Prueba 3–5 imágenes representativas con cwebp y avifenc. Mide tamaño y tiempo de CPU. Un ejemplo típico en 2024: AVIF reduce peso medio un 30% frente a WebP, pero la conversión consume 2–3 veces más CPU en máquinas comunes.
Implementaciones en WordPress
La idea central: muchas instalaciones dependen de GD o Imagick; si estas bibliotecas no soportan WebP/AVIF la conversión falla. Revisa soporte a nivel PHP.
Soporte en PHP: GD vs imagick
Comprueba phpinfo() para ver si GD o Imagick declaran soporte para WebP/AVIF. Si no aparece, la librería del sistema falta o está desactualizada.
Plugins recomendados y límites
ShortPixel, EWWW y Imagify pueden generar WebP/AVIF. Si el plugin no crea archivos en Multisite o en hosting gestionado, el problema suele ser permisos o reescrituras del servidor.
Un caso habitual: un sitio con Multisite migrado a hosting gestionado → los plugins crean WebP, pero el CDN sirve JPG porque Vary se perdió al aplicar reglas de cache. Resultado: imágenes rotas hasta ajustar reglas.
Solución cuando GD/Imagick falla
Si no puedes actualizar librerías en el servidor, pre-genera las versiones en CI y sube los archivos ya convertidos al bucket S3 o al propio servidor.
En WordPress Multisite los problemas habituales vienen por dos frentes: rutas y almacenamiento compartido. Si la red usa almacenamiento en disco local en varios nodos, las versiones .webp/.avif generadas en un servidor no estarán presentes en otro, por lo que conviene usar un bucket S3/Cloud Storage central o un plugin que suba versiones convertidas al almacenamiento de objetos. Además, revisar permisos de uploads (owner/group) y la configuración de objetos públicos en el bucket evita 403 al servir .webp; en Multisite hay que comprobar que los plugins de optimización y plugins de caché estén activados de forma compatible en la red y que no haya reescrituras que solo actúen en el sitio principal.
Para entornos hosteados donde no se pueden instalar librerías GD/Imagick, el preprocesado en CI y la subida de archivos ya convertidos al storage del sitio es la práctica más fiable.
Automatización de pipeline y CI
La idea central: pre-generar versiones WebP/AVIF durante el build evita carga en runtime y asegura consistencia entre entornos. Usa GitHub Actions o GitLab CI.
Flujo recomendado
- En CI extraer imágenes de
assets/ o del media library exportado.
- Ejecutar
cwebp y avifenc para generar versiones.
- Subir al storage de producción (S3, CDN o uploads).
Ventajas y costes
Pre-generar reduce CPU en el servidor y mejora caché. On-the-fly reduce almacenamiento pero aumenta CPU y latencia.
Errores que arruinan el resultado
La idea central: asumir que convertir archivos basta es la causa principal de fallos en producción. Revisa reescrituras, Vary, caché y CDN.
Errores habituales
- No añadir
AddType image/webp .webp o types en nginx.
- CDN que elimina
Vary y mantiene versión antigua en cache.
- Plugins que reescriben rutas sin generar archivos WebP.
Advertencias específicas
Esto no funciona si no se puede editar servidor o CDN; en ese caso la alternativa es pre-generar imágenes en CI y usar HTML con
, o coordinar con el host gestionado para activar soporte.Cuándo no aplicar esta estrategia y alternativas
La idea central: si el público usa navegadores corporativos muy antiguos o el hosting impide cambios, no merece la pena convertir en runtime. Opta por fallback y pre-generación.
Casos donde no aplicar
- Navegadores corporativos sin posibilidad de actualización.
- Hosting que no permite editar cabeceras ni instalar librerías.
- Coste CPU de conversión mayor que el ahorro en ancho de banda.
Alternativas prácticas
- Mantener JPG/PNG y usar compresión optimizada.
- Pre-generar WebP en un entorno externo y servir como archivos estáticos.
En entornos donde no se puede tocar servidor, la solución más segura es el <picture> con archivos pre-generados.
Para un diagnóstico urgente y aplicar los snippets en producción, quien lo necesite puede solicitar al proveedor de hosting o a un equipo técnico la revisión con las pruebas HTTP y un plan de corrección.
Preguntas frecuentes
¿Por qué no se muestran WebP en mi WordPress?
Normalmente se debe a cabeceras HTTP incorrectas, MIME no configurado o reglas de caché que rompen la negociación. Comprueba Content-Type, Vary y si el archivo .webp existe en la ruta.
Revisa logs y prueba con curl y DevTools. Si hay CDN, purga caché y repite la prueba con y sin Accept header.
¿Cómo habilito WebP sin tocar el servidor?
Se puede pre-generar WebP en CI y subirlos al bucket o usar un plugin que almacene las versiones convertidas. Esto evita tocar .htaccess o nginx.
Si el hosting ofrece soporte, pide que activen MIME y revisen reescrituras; algunos hosts gestionados aplican cambios por ticket.
¿Qué plugin recomendarías para conversiones?
ShortPixel y EWWW funcionan bien en muchos casos y permiten AVIF opcional. Verifica que el plugin cree archivos físicos y que tenga soporte Multisite.
Configura el plugin para que genere WebP/AVIF y añade fallback con <picture> si el plugin no lo inserta automáticamente.
¿Cómo compruebo que el CDN respeta Vary y Cache-Control?
Haz curl -I contra la URL a través del CDN y observa Vary y Cache-Control. Si faltan, configura reglas en el CDN para añadirlos o usa Workers/Lambda@Edge.
Si el CDN borra Vary, la negociación de formatos fallará y algunos usuarios verán imágenes rotas.
¿AVIF siempre es mejor que WebP?
AVIF suele ofrecer mejor compresión que WebP pero requiere más CPU para convertir. Elige AVIF para imágenes críticas si la infraestructura puede asumir la conversión.
Mide en 3–5 imágenes del sitio y compara tamaño y tiempo de conversión antes de decidir desplegar AVIF masivamente.
¿Cómo afecta esto al SEO y a la accesibilidad?
Google valora la velocidad y la correcta indexación de imágenes; si las imágenes están rotas, el SEO empeora. Asegura alt y que robots acceden a las imágenes.
Cumple WCAG usando alt y noscript si aplicas lazy loading. Revisa también el tratamiento de imágenes por terceros por RGPD/DSA.
Pasos accionables y recursos
La idea central: primero diagnosticar con curl y DevTools, luego arreglar servidor/CDN y finalmente garantizar fallback HTML y pruebas en producción. Ejecuta el checklist y automatiza la conversión en CI para estabilidad.
Comprueba esto de inmediato: usa `curl -I` con y sin `Accept: image/webp`; si `Vary` no aparece o `Content-Type` no refleja `.webp`, el CDN o servidor están bloqueando la negociación.
Recursos y herramientas: curl, Chrome DevTools, Lighthouse, WebPageTest, Squoosh, cwebp, avifenc, ShortPixel, EWWW, Cloudinary y Cloudflare.
Infografía del flujo:
1. Diagnóstico (curl / DevTools)
2. Servidor: MIME y reescrituras
3. CDN: preservar Vary y tipos
4. Fallback HTML con <picture>
5. Test final: navegadores reales y purga caché
