Vercel deja de cachear respuestas con Vary: Cookie

¿Qué cambió exactamente en Vercel CDN?

Vercel anunció que su CDN ya no almacena en caché las respuestas del origin cuyo header Vary incluya Cookie. El cambio aparece documentado en el changelog oficial y afecta a cualquier proyecto desplegado en Vercel que estuviera usando esa combinación.

El header Vary le indica al caché qué encabezados de la petición pueden cambiar la respuesta. Es decir, le avisa al CDN: «si cambia este header, necesito una versión distinta del recurso». Cuando se incluye Cookie en Vary, el caché debe crear una entrada por cada combinación distinta de cookies que reciba. Como las cookies suelen contener identificadores de sesión, tokens o datos personalizados del visitante, en la práctica eso genera una explosión de variantes casi imposible de reutilizar.

A partir del cambio, esas respuestas se siguen entregando normalmente al usuario, pero ya no se guardan en el edge para futuras peticiones. El header x-vercel-cache aparecerá como MISS y los Runtime Logs de Vercel mostrarán el motivo vary_key_denied:cookie. El resto de valores de Vary que admite Vercel no se ven afectados.

👥 ¿Quieres ir más allá de la noticia?

En nuestra comunidad discutimos las tendencias, compartimos oportunidades y nos ayudamos entre emprendedores. Sin humo, solo acción.

👥 Unirme a la comunidad

¿Por qué Vercel tomó esta decisión?

El problema de fondo es la fragmentación del caché. Cuando un sitio varía por Cookie, cada usuario termina con su propia versión del recurso: el CDN llena su almacenamiento con miles de copias casi idénticas y el cache hit ratio se desploma. La consecuencia directa es más carga sobre el origin, mayor latencia y, paradójicamente, peor experiencia para el usuario final.

No es una decisión aislada. Otros CDN importantes aplican lógicas similares para evitar esta misma trampa:

Cloudflare, según su documentación oficial, no considera los valores de Vary en las decisiones de caché por defecto. Solo los respeta cuando se configura explícitamente a través de Cache Rules o cuando el header es vary: accept-encoding.
Azure Front Door, según su documentación oficial, ni siquiera reenvía el header Vary al origin cuando el caché está activado.

El movimiento de Vercel va en la misma dirección: forzar a los desarrolladores a tomar una decisión consciente entre caché compartido o respuesta personalizada, en lugar de gastar almacenamiento en variantes inútiles.

Cómo saber si tu sitio está afectado

Vercel habilitó dos formas de detección:

Header de respuesta x-vercel-cache: si la URL que esperabas cacheada devuelve MISS cuando antes devolvía HIT, este cambio es probablemente el culpable.
Runtime Logs: dentro del panel de Vercel, los logs muestran vary_key_denied:cookie como razón del fallo de caché. La propia documentación de Vercel describe esta clave como una de las posibles causas de denegación.

Una auditoría rápida consiste en revisar las respuestas del origin en las rutas de mayor tráfico (landing pages, páginas de producto, listados) y comprobar si el Vary que devuelve tu backend arrastra Cookie por herencia del framework o de una configuración legacy.

Dos caminos para arreglarlo

El propio changelog de Vercel propone dos soluciones, y la elección depende de si tu respuesta realmente depende de la cookie del visitante:

1. Si la respuesta es la misma para todos los usuarios (o no te importa personalizarla para el caché compartido): elimina Cookie del header Vary en esa ruta. Con esto, la CDN puede cachear la respuesta siempre que cumpla el resto de requisitos (un Cache-Control adecuado, contenido cacheable, etc.). Es la opción recomendada para landings, blogs, páginas de marketing, documentación y catálogos públicos.

2. Si la respuesta sí depende de cookies (dashboards personalizados, contenido autenticado): deja Cookie en Vary pero añade Cache-Control: private. Esta directiva indica que la respuesta es para un único usuario y que no debe almacenarse en cachés compartidos como el de un CDN, aunque sí puede vivir en el caché del navegador del propio visitante. Es el comportamiento esperado para rutas autenticadas o con datos sensibles.

En ambos casos conviene revisar el Vary que devuelve el origin, no solo el que crees estar enviando. Frameworks como Next.js, Express, NestJS o frameworks PHP aplican Vary por defecto en ciertas configuraciones, y ese es, en muchos casos, el origen del problema.

¿Qué significa esto para tu startup?

Para la mayoría de equipos que despliegan en Vercel, este cambio es una oportunidad de mejorar el cache hit ratio sin reescribir la aplicación, simplemente ajustando los headers correctos. Las acciones concretas que puedes tomar esta semana:

Audita las 10 rutas con más tráfico de tu sitio. Revisa el Vary que devuelve cada una y la cabecera x-vercel-cache correspondiente. Cualquier ruta con Vary: Cookie y tráfico anónimo está perdiendo caché hoy mismo.
Separa explícitamente rutas públicas de privadas. Las landings, documentación y páginas de producto deberían servir con Vary limpio y Cache-Control adecuado. Las rutas autenticadas, con Cache-Control: private. La mezcla es lo que mete al CDN en problemas.
Mide el cache hit ratio antes y después. Vercel expone métricas en su panel. Si tras el ajuste el ratio sube del rango habitual al 85% o más, el impacto se nota en latencia y en factura de origin.
Revisa frameworks y middlewares por defecto. Si usas Next.js, Nextra, Astro o similares, verifica que ningún middleware esté añadiendo Vary: Cookie automáticamente. La regresión más común después de un deploy es un middleware nuevo que toca headers sin que nadie lo note.

Si tu equipo no tiene claro qué headers está enviando su backend, vale la pena invertir una tarde en mapearlo: el ROI de un caché bien configurado en Vercel se nota en métricas de Core Web Vitals, en tiempo de respuesta y, sobre todo, en los costes cuando una campaña de marketing multiplica el tráfico de golpe.