Configurar WebP y AVIF
Primero mirar qué puede tu servidor
En el apartado «Imágenes» está la tarjeta «Capacidades de este servidor». No muestra lo que pone sobre el papel, sino lo que se ha medido en el PHP en marcha: biblioteca de imágenes GD con su versión, leer JPEG, leer PNG, leer WebP, escribir WebP, escribir AVIF. Se pregunta por partida doble — la función tiene que existir y el formato tiene que aparecer en imagetypes(). Eso importa, porque algunos proveedores de alojamiento compilan GD sin WebP o sin AVIF: imagewebp() existe entonces y solo falla al llamarla.
Si falta un formato, el interruptor correspondiente sigue visible, pero está apagado y lleva el motivo. Para WebP dice: GD tiene que estar compilado con libwebp. Para AVIF: PHP 8.1 o posterior con libavif. Ambas cosas son cosa de tu proveedor de alojamiento. Dar un rodeo por la llamada AJAX no sirve — el servidor rechaza expresamente activar un formato no disponible.
La línea «Imagick» es pura información. Este módulo no usa Imagick; si ahí pone «no disponible», no te falta nada.
Activar y fijar las tres cifras
Hay tres interruptores y tres campos numéricos. «Generar WebP» y «Generar AVIF» están apagados de fábrica; «Entregar mediante <picture>» está encendido. La separación es intencionada: puedes dejar primero que se creen los archivos y activar la entrega más tarde. Y al revés: si apagas la entrega, los archivos se siguen creando, pero a los visitantes les llega el marcado sin cambios.
La calidad de WebP está en 82 y la de AVIF en 50. Ambos campos aceptan valores de 30 a 100; todo lo que esté por encima o por debajo se recorta a ese rango. Los valores por defecto distintos no son un descuido: AVIF mide de otra forma que JPEG, y ahí 50 se ve ya muy limpio. Por encima de 90, en WebP el archivo crece más rápido que la mejora visible.
El límite máximo en megapíxeles está en 40 y acepta valores de 4 a 400. Protege frente al límite de memoria: una foto de 6000 × 4000 ocupa al descodificarse unos 96 MB, independientemente de lo grande que sea su archivo. Además, antes de cada descodificación Kakapo calcula contra la memoria que queda realmente libre y se salta la imagen en lugar de dejar que la subida muera en el límite.
Si cambias uno de los tres interruptores, se descarta la cache de páginas guardada. La calidad y el límite de megapíxeles la dejan intacta — solo actúan en la siguiente subida y no vuelven incorrecta ninguna página ya guardada.
Qué ocurre al subir un archivo
La conversión se ejecuta al final de la subida, en cuanto WordPress ha generado todos los tamaños de imagen. Se procesan el archivo de los metadatos y cada tamaño generado — no el original que guarda el núcleo, que de todos modos nunca se entrega.
Cada versión derivada se guarda como archivo acompañante junto a su original y lleva el nombre completo de este más la extensión: de bild.jpg sale bild.jpg.webp, no bild.webp. El motivo: en la misma carpeta pueden convivir bild.jpg y bild.png; si solo se sustituyera la extensión, una versión derivada machacaría a la otra. Si en el destino ya hay algo, no se toca.
Primero se escribe en un archivo auxiliar que lleva en el nombre el número de proceso y un valor aleatorio. Solo cuando, al medirlo, resulta más pequeño que el original, pasa a su sitio mediante rename. Si es mayor o igual de grande, se borra y se queda el original. Por eso una pasada interrumpida nunca deja atrás una versión derivada demasiado grande.
La subida tiene un presupuesto de tiempo de 12 segundos. Generar AVIF es varias veces más lento que WebP, y seis tamaños por dos formatos se topan si no con el tiempo de ejecución del servidor web — quien lleva el sitio vería una subida interrumpida. Lo que ya no cabe lo recoge una pasada posterior única: se programa 30 segundos más tarde y dispone entonces de 90 segundos. Tanto lo hecho como lo omitido se anota en el adjunto, para que el mismo intento no se repita en cada nueva generación.
En los JPEG se aplica después la rotación EXIF, porque WebP y AVIF salidos de GD no arrastran ese dato. Con originales PNG, Kakapo prueba WebP primero sin pérdidas — logotipos, gráficos y capturas de pantalla suelen quedar así más pequeños sin que los bordes se deshilachen. La transparencia se conserva en ambos formatos de destino.
Cómo se entrega
Kakapo envuelve el <img> en un <picture> y antepone fuentes AVIF y WebP, primero AVIF — el navegador toma la primera fuente que entiende. El <picture> recibe display:contents para que en las disposiciones flex y grid de tu tema no meta una caja adicional en la composición.
Elegido a propósito frente a la alternativa vía .htaccess: la negociación de contenido necesita reglas de Apache, en nginx no funciona en absoluto y choca con las memorias intermedias de las CDN, que no varían la cabecera Accept. Con <picture> decide el navegador, sin una sola línea de configuración del servidor.
Se actúa sobre los contenidos de las entradas y las imágenes destacadas, con prioridad 22 — después del Lazy-Load (20) y antes de la reescritura para la CDN (25), para que las fuentes recién creadas pasen también por la CDN. Los bloques <picture> ya existentes quedan intactos, igual que las imágenes de hosts ajenos y todo lo que esté fuera de la carpeta de subidas.
Merece la pena conocer una regla: un formato solo se ofrece si la versión más grande del srcset existe como versión derivada. Si falta una mediana o una pequeña, el navegador recurre a la siguiente más grande — unos kilobytes más, pero nunca una imagen borrosa. Si faltara la más grande, una pantalla ancha ya no podría llegar a la resolución completa; justo ese caso queda descartado.
Si no se crea nada: leer los motivos
La tarjeta «Archivos generados & ahorro real» muestra, por formato, el número de archivos, la suma de los originales, la suma de las versiones derivadas y la diferencia. Cada cifra procede de comparar dos tamaños de archivo reales en el momento de la generación — nada está estimado ni extrapolado. «Originales» es aquí solo la suma de los archivos para los que se ha creado una versión derivada, no todo tu fondo de medios.
Debajo aparece lo que no se ha convertido, con su motivo. Los más importantes:
«El resultado era mayor que el original» — no es ningún error. Con miniaturas muy pequeñas eso pasa a menudo con AVIF; el original se mantiene y los demás tamaños reciben igualmente su versión derivada.
«No escribible» — comprueba los permisos de la carpeta de subidas. Es el único motivo que realmente te reclama a ti.
«En el destino ya había un archivo» — no se ha sobrescrito. Casi siempre procede de la pasada por lotes sobre el material existente y es ya exactamente lo que aquí debía crearse.
«No cabía en la memoria» — sube el límite de megapíxeles o el límite de memoria de PHP.
«No legible» — archivo defectuoso, JPEG en CMYK o una variante exótica. «No es JPEG/PNG/WebP» — los GIF animados y los PDF no se tocan a propósito.
Si la tarjeta está vacía, activa WebP y sube una imagen. A las imágenes que ya están en la biblioteca de medios no llegas por ahí, sino mediante la pasada por lotes, más abajo en esta misma página.