Entrega de WebP: POM Cache, generación de imágenes y responsabilidades de Apache

POM Cache no crea imágenes WebP y no reemplaza las URL de las imágenes dentro del HTML en caché. Una implementación de WebP en la misma carpeta funciona porque tres capas independientes acuerdan una misma convención.

Las tres responsabilidades

La única conexión de POM Cache es indirecta: una página HTML en caché puede contener la URL de la imagen original, igual que una página dinámica de WordPress.

Por qué el HTML puede conservar la URL original

Supongamos que la página contiene:

<img src="/wp-content/uploads/2026/07/dish.jpg" alt="Dish">

El navegador sigue solicitando dish.jpg. Apache puede inspeccionar la cabecera Accept de la solicitud:

Accept: image/avif,image/webp,image/*,*/*

Si la alternativa acordada existe, el servidor asigna internamente la solicitud al archivo WebP conservando la URL pública. Un navegador sin soporte para WebP recibe dish.jpg.

Esto evita generar una página HTML distinta para cada formato de imagen.

Elige una convención de nombre de archivo

Dos diseños habituales en la misma carpeta son:

dish.jpg
dish.jpg.webp

o:

dish.jpg
dish.webp

La primera convención conserva el nombre de archivo original completo y es la que utiliza el ejemplo de este capítulo. No combines ambas salvo que la regla defina una prioridad determinista.

El generador de imágenes, la condición de reescritura, el proceso de limpieza y la política de copias de seguridad deben utilizar el mismo contrato de nomenclatura.

Accept no es Accept-Encoding

La negociación del formato de imagen utiliza:

Vary: Accept

La compresión de HTML/CSS/JavaScript utiliza:

Vary: Accept-Encoding

Son dimensiones de solicitud diferentes. El soporte de Brotli no implica soporte de WebP, y una clave de caché que varíe solo en Accept-Encoding no puede almacenar de forma segura cuerpos JPEG/PNG y WebP bajo una misma URL de imagen.

Lo que el servidor debe garantizar

Para una solicitud de JPEG o PNG original:

1. confirmar que el navegador acepta explícitamente image/webp;
2. confirmar que el original existe;
3. confirmar que la alternativa de la misma carpeta existe;
4. reescribir internamente a ese archivo exacto;
5. enviar Content-Type: image/webp;
6. combinar Accept en Vary;
7. en caso contrario, servir el original sin cambios.

La regla no debe llamar a PHP, buscar en directorios no relacionados, generar imágenes ni devolver WebP simplemente porque se pueda adivinar un nombre de archivo.

Lo que el proceso de imágenes debe garantizar

Antes de activar la negociación, decide:

• qué formatos de origen reciben alternativas WebP;
• si se conservan la transparencia y la animación;
• cómo se selecciona la calidad;
• cómo actualizan sus alternativas los tamaños regenerados de WordPress;
• qué ocurre cuando el original se edita, se reemplaza o se elimina;
• cómo se detectan las conversiones fallidas o parciales.

Apache verifica la existencia, no la integridad de la imagen. Un archivo .webp dañado sigue existiendo y puede servirse.

Lo que el CDN debe garantizar

Si una URL de visualización puede devolver dos cuerpos, la política de edge debe incluir la distinción relevante de Accept o utilizar una característica equivalente de negociación de formato. Reenviar Vary: Accept desde el origen es útil, pero la política de caché del CDN sigue siendo la autoritativa.

Tras cambiar la regla o reemplazar una alternativa, invalida la ruta pública de la imagen original y toda variante de edge representada por esa ruta.

Empieza por Servir una alternativa WebP en la misma carpeta con Apache y, a continuación, valida la alternativa de la imagen original.