Conserva la imagen original como alternativa segura

La negociación de WebP debe ser aditiva. El JPEG o PNG sigue siendo la alternativa canónica para navegadores, bots, feeds, clientes de correo electrónico, rastreadores sociales y cualquier solicitud cuya política de edge no admita WebP de forma segura.

No elimines la original después de crear su alternativa.

Cuatro resultados que debes comprobar

Solicitud del navegador Archivo WebP Cuerpo esperado
Accept incluye image/webp Existe WebP
Accept excluye WebP Existe JPEG/PNG original
Accept incluye WebP Falta JPEG/PNG original
Sin cabecera Accept útil Existe JPEG/PNG original

La URL pública sigue siendo la URL de la imagen original en cada fila.

Prueba una alternativa inexistente

Elige una imagen original para la que no exista ningún archivo hermano .webp.

  1. Solicítala con Accept: image/webp.
  2. Confirma que el estado, las dimensiones y el cuerpo siguen siendo los de la original.
  3. Confirma que Content-Type coincide con la extensión de la original.
  4. Confirma que Apache no devuelve un 404 para la ruta WebP supuesta.

La condición de existencia es el mecanismo de alternativa. No debe redirigir al navegador a un nombre de archivo inexistente.

Prueba un cliente incompatible

Solicita un par que sí tenga una alternativa WebP, pero omite WebP de Accept.

Resultado esperado:

  • se sirven los bytes originales;
  • Content-Type sigue siendo image/jpeg o image/png;
  • la respuesta sigue siendo visualmente correcta;
  • el edge no reutiliza un cuerpo WebP anterior.

Prueba tanto a través del origen como de la CDN. Una alternativa correcta de Apache puede verse anulada por una caché de edge que ignore Accept.

Conserva el comportamiento de la imagen original

Comprueba las características de la imagen que pueden perderse durante la conversión:

  • transparencia del PNG;
  • perfiles de color incrustados;
  • orientación EXIF;
  • animación;
  • iconos muy pequeños en los que WebP puede no ser más pequeño;
  • recortes generados por WordPress y tamaños responsivos.

La reescritura no puede determinar si la alternativa es semánticamente equivalente. Esa es responsabilidad del proceso de imágenes.

Ciclo de vida de reemplazo y eliminación

Cuando WordPress reemplaza una imagen:

  1. regenera cada archivo hermano WebP esperado;
  2. verifica la hora de modificación y el contenido de la alternativa;
  3. elimina las alternativas obsoletas que ya no tienen original;
  4. invalida la ruta pública de la imagen en la CDN;
  5. vuelve a comprobar tanto las solicitudes compatibles como las de alternativa.

Si solo cambia la original mientras permanece una .webp más antigua, los navegadores compatibles pueden ver un contenido distinto al de los clientes incompatibles.

Prueba de aceptación de la clave de caché

Ejecuta las solicitudes en ambos órdenes:

  1. Accept solo con la original y, después, Accept WebP;
  2. Accept WebP y, después, Accept solo con la original.

Repite cuando el edge esté en caliente. La salida correcta no debe depender de qué formato llenó primero la CDN.

Inspecciona:

  • Content-Type;
  • Vary;
  • evidencia de acierto/fallo del edge;
  • tamaño de la respuesta;
  • formato de imagen decodificado;
  • dimensiones visibles y transparencia.

Revierte sin romper las imágenes

Para desactivar la integración:

  1. elimina o desactiva la regla de negociación mediante el proceso de despliegue del servidor;
  2. valida y recarga Apache;
  3. invalida las rutas públicas de imagen afectadas;
  4. confirma que todos los clientes reciben los archivos originales;
  5. deja los archivos hermanos WebP en su lugar hasta que se demuestre que la reversión funciona.

Dado que el HTML en caché sigue haciendo referencia a la URL original, normalmente no se requiere una regeneración del HTML de POM Cache únicamente para detener la negociación WebP en la misma URL.