Servir imágenes óptimas con negociación de contenido - Cabeceras Accept e integración con CDN

Qué es la negociación de contenido - Selección de formatos óptimos vía HTTP

La Negociación de Contenido (Content Negotiation) es una funcionalidad estándar del protocolo HTTP donde cliente y servidor negocian el formato de respuesta óptimo. Para la distribución de imágenes, el navegador comunica los formatos de imagen soportados al servidor, que responde con el formato más eficiente disponible.

Cómo funciona:

• El navegador envía Accept: image/avif,image/webp,image/png,image/* en las cabeceras de solicitud
• El servidor analiza la cabecera Accept y verifica el soporte de formatos en orden de prioridad
• Devuelve AVIF si es soportado, WebP si solo WebP es soportado, o JPEG/PNG como respaldo
• Incluye la cabecera Vary: Accept en la respuesta para asegurar la corrección del caché

Ventajas: A diferencia de la ramificación con el elemento <picture> de HTML, los formatos pueden cambiarse sin modificar URLs. Las etiquetas <img src="photo.jpg"> existentes permanecen sin cambios mientras se sirve WebP o AVIF a navegadores compatibles, sin requerir modificaciones de HTML.

Ejemplos de cabecera Accept por navegador:

• Chrome 100+: image/avif,image/webp,image/apng,image/*,*/*;q=0.8
• Firefox 93+: image/avif,image/webp,*/*
• Safari 16+: image/webp,image/png,image/*;q=0.8,*/*;q=0.5

Safari añadió soporte WebP en iOS 16 / macOS Ventura (2023), y soporte AVIF desde Safari 16.4 en adelante.

Implementación del lado del servidor - Ejemplos de configuración Nginx y Apache

Aquí se muestra cómo implementar la negociación de contenido en servidores web, con ejemplos de configuración para Nginx y Apache.

Configuración de Nginx:

map $http_accept $img_suffix {
default "";
"~image/avif" ".avif";
"~image/webp" ".webp";
}

server {
location ~* ^(.+)\.(jpe?g|png)$ {
set $base $1;
set $ext $2;
add_header Vary Accept;
try_files $base$img_suffix.$ext $uri =404;
}
}

Esta configuración devuelve la versión .avif si image/avif está en la cabecera Accept, la versión .webp si image/webp está presente, y recurre al JPEG/PNG original si el archivo alternativo no existe.

Configuración de Apache (.htaccess):

RewriteEngine On
RewriteCond %{HTTP_ACCEPT} image/avif
RewriteCond %{REQUEST_FILENAME}.avif -f
RewriteRule ^(.+)\.(jpe?g|png)$ $1.$2.avif [T=image/avif,L]

RewriteCond %{HTTP_ACCEPT} image/webp
RewriteCond %{REQUEST_FILENAME}.webp -f
RewriteRule ^(.+)\.(jpe?g|png)$ $1.$2.webp [T=image/webp,L]

Header append Vary Accept

Nota crítica: Siempre incluye la cabecera Vary: Accept. Sin ella, los CDN o proxies pueden cachear la versión AVIF y servirla a navegadores que solo soportan WebP, causando fallos de visualización.

Negociación de contenido a nivel de CDN - Configuración de CloudFront y Cloudflare

Al usar un CDN, implementar la negociación de contenido a nivel de CDN es lo más eficiente. Realizar la detección de formato en servidores de borde minimiza las solicitudes al origen.

Configuración de CloudFront:

• Política de caché: Crear una política personalizada que incluya la cabecera Accept en la clave de caché. Sin embargo, los valores de la cabecera Accept varían ligeramente entre navegadores, potencialmente reduciendo las tasas de acierto de caché
• Lambda@Edge: Normalizar la cabecera Accept en un trigger de Viewer Request, consolidando en 3 patrones: image/avif, image/webp, other. Esto mejora significativamente las tasas de acierto de caché
• CloudFront Functions: Más ligero y rápido que Lambda@Edge. Ideal para análisis de cabecera Accept y reescritura de URI de solicitud

Implementación de CloudFront Functions:

function handler(event) {
var request = event.request;
var accept = request.headers.accept ? request.headers.accept.value : '';
var uri = request.uri;
if (uri.match(/\.(jpe?g|png)$/i)) {
if (accept.includes('image/avif')) {
request.uri = uri + '.avif';
} else if (accept.includes('image/webp')) {
request.uri = uri + '.webp';
}
}
return request;
}

Configuración de Cloudflare: Habilitar la función Polish de Cloudflare realiza conversión automática a WebP en el borde. El plan Pro y superiores también ofrecen conversión AVIF. También se puede implementar lógica personalizada mediante Transform Rules.

Gestión correcta de la cabecera Vary - Prevención de accidentes de caché

La cabecera Vary es un elemento crítico que asegura el comportamiento correcto del caché para la negociación de contenido. Una configuración incorrecta puede causar incidentes graves donde se sirven formatos incorrectos desde el caché.

Rol de la cabecera Vary: Vary: Accept indica a los cachés que "esta respuesta varía según el valor de la cabecera Accept". Los CDN y proxies usan esta información para mantener entradas de caché separadas para cada valor de cabecera Accept.

Patrones comunes de accidentes:

• Sin Vary: El CDN cachea la respuesta AVIF de la primera solicitud (Chrome) y sirve AVIF a la siguiente solicitud (Safari) también, causando que las imágenes no se muestren en Safari
• Vary: *: No cachear si cualquier cabecera de solicitud difiere. Efectivamente deshabilita el caché por completo, anulando los beneficios del CDN
• Vary: Accept-Encoding, Accept: Correcto pero puede crear demasiadas variaciones de caché, reduciendo las tasas de acierto

Normalización de cabecera Accept: Dado que los valores de la cabecera Accept difieren ligeramente entre navegadores (presencia de valores de calidad, diferencias de orden), usarlos directamente como claves de caché crea cachés separados para navegadores que soportan el mismo formato. Normalizar las cabeceras Accept en el borde del CDN a 3 valores (avif, webp, default) maximiza las tasas de acierto de caché.

Método de prueba: Usa curl -H "Accept: image/webp" -I https://example.com/photo.jpg para verificar que las cabeceras de respuesta devuelvan Content-Type: image/webp y Vary: Accept. Realiza múltiples solicitudes con diferentes cabeceras Accept para confirmar que se devuelven los formatos correctos.

Comparación con el elemento picture - Enfoques del lado del cliente vs servidor

El cambio de formato de imagen puede hacerse mediante el elemento <picture> de HTML (lado del cliente) o negociación de contenido (lado del servidor). Comprender las características de cada enfoque permite una selección apropiada.

Elemento picture (lado del cliente):

<picture>
<source srcset="photo.avif" type="image/avif">
<source srcset="photo.webp" type="image/webp">
<img src="photo.jpg" alt="Foto">
</picture>

Comparación:

• Cambios HTML: El elemento picture requiere modificar todo el HTML de la página. La negociación de contenido no necesita cambios HTML
• Estructura de URL: El elemento picture usa URLs diferentes por formato. La negociación de contenido usa una sola URL
• Eficiencia de caché: El elemento picture tiene cachés independientes por formato. La negociación de contenido gestiona mediante cabecera Vary
• SEO: El elemento picture permite que cada URL sea indexada independientemente. La negociación de contenido gestiona bajo 1 URL
• Depuración: El elemento picture se verifica fácilmente en DevTools del navegador. La negociación de contenido requiere inspección de cabeceras

Uso recomendado:

• Proyectos nuevos: Elemento <picture> recomendado. Comportamiento explícito y predecible
• Mejora de proyectos existentes: Negociación de contenido recomendada. Desplegable sin cambios HTML
• CMS / UGC: Negociación de contenido recomendada. No se puede modificar el HTML de imágenes subidas por usuarios

Web 配信技術の書籍は Amazon でも入手できます

Resolución de problemas y monitoreo - Operaciones en producción

La negociación de contenido funciona de forma transparente cuando está correctamente configurada, pero pueden surgir problemas por errores de configuración o cambios en el comportamiento del CDN. Aquí presentamos técnicas de monitoreo y resolución de problemas para entornos de producción.

Problemas comunes y soluciones:

• Imágenes que no se muestran: Error en la lógica de análisis de cabecera Accept que devuelve formatos no soportados. Simula la cabecera Accept de cada navegador con curl para verificar
• Baja tasa de acierto de caché: Normalización insuficiente de cabecera Accept. Verifica las tasas de acierto por Vary en las estadísticas de caché del CDN
• AVIF no se sirve: El archivo no existe o falta la configuración del tipo MIME. Verifica que image/avif esté registrado en los tipos MIME del servidor web
• Aumento del tamaño de archivo: Casos raros donde WebP/AVIF es más grande que el JPEG original. Añade lógica para comparar tamaños durante la conversión y usar el más pequeño

Implementación de monitoreo:

• Agrega la distribución de Content-Type de los logs de acceso del CDN para rastrear las proporciones de distribución AVIF/WebP
• Mide los tiempos de carga de imágenes por formato usando Real User Monitoring (RUM)
• Prueba automáticamente la correcta visualización de imágenes en los principales navegadores periódicamente (Playwright / Puppeteer)

Fiabilidad del respaldo: El requisito más crítico de la negociación de contenido es recurrir de forma fiable a las imágenes originales (JPEG/PNG) cuando no hay formato soportado disponible. Siempre prueba que las rutas de respaldo permanezcan intactas al añadir nuevos formatos. Como caso límite, verifica respuestas correctas a solicitudes con cabeceras Accept vacías (algunos bots y proxies).