Qué cambia en el Routing Middleware de Vercel
Vercel incorporó la opción skipMiddlewareRequestBody, un nuevo ajuste de configuración que permite no enviar el body de las peticiones del cliente al Routing Middleware. El objetivo explícito que cita el changelog oficial de Vercel es doble: reducir el consumo de Fast Origin Transfer en las invocaciones de middleware y mejorar el Time to First Byte (TTFB), sobre todo en peticiones con bodies grandes.
En términos simples: cada vez que un request llega a tu deploy en Vercel, el routing middleware corre antes que tu lógica de negocio. Hasta ahora, ese middleware recibía también el body completo de la petición aunque no lo necesitara. Con esta opción, puedes pedirle a Vercel que no reenvíe ese body al middleware, ahorrando ancho de banda entre el edge y tu función.
Por qué importa para el rendimiento y la factura
El Routing Middleware de Vercel corre en el edge antes de que la request llegue a tu Vercel Function o a tu destino de rewrite. Según el changelog, las Vercel Functions y los rewrite targets siguen recibiendo el body completo, así que solo se evita el envío al middleware, no a tu código de aplicación.
¿Y esto cómo se aplica en tu negocio?
En CAR, dueños de empresa de Latinoamérica y España usan la tecnología para ser más rentables. Empiezas con una ruta de 7 días y terminas con un sistema funcionando en tu negocio.
👥 Probar 7 díasEsto tiene dos efectos prácticos que un founder debe entender:
- TTFB: al no tener que transferir el body al middleware, la primera respuesta puede salir antes. El propio changelog señala que el beneficio es especialmente notable en peticiones con bodies grandes (por ejemplo, uploads, formularios pesados, llamadas a webhooks con JSON grande).
- Fast Origin Transfer: Vercel factura el tráfico de Fast Origin Transfer asociado a las invocaciones de middleware. Skipear el body reduce ese consumo y, por tanto, el costo en proyectos con mucho tráfico.
El ajuste arranca en false y los proyectos existentes no cambian su comportamiento a menos que lo actives de forma explícita. Es una optimización opcional, no un breaking change.
Cómo activarlo en tu proyecto
Vercel documenta dos formas de habilitarlo, según uses el archivo JSON o TypeScript de configuración.
En vercel.json:
{
"$schema": "https://openapi.vercel.sh/vercel.json",
"skipMiddlewareRequestBody": true
}
En vercel.ts (requiere tener @vercel/config instalado):
import type { VercelConfig } from '@vercel/config/v1';
export const config: VercelConfig = {
skipMiddlewareRequestBody: true,
};
Importante: tras modificar la configuración, hay que redesplegar el proyecto para que el cambio surta efecto. No basta con redeploys incrementales de funciones: la opción vive a nivel de proyecto.
Cuándo SÍ conviene activarlo (y cuándo NO)
El changelog lo deja muy claro: activa esta opción solo si tu Routing Middleware no lee el body de la request. Si tu middleware hace request.json(), request.formData(), request.text() o cualquier operación que consuma el body, dejarlo en true romperá esa lógica porque el body nunca llegará.
Casos típicos en los que SÍ puedes activarlo:
- Middleware que solo evalúa headers, cookies, geolocalización o path para decidir rewrites, redirects o headers de respuesta.
- Auth checks que se basan en JWT en cookies o en el header Authorization (no en el body).
- Middleware de A/B testing o de feature flags que solo mira headers y query params.
- Rate limiting básico por IP, país o user agent.
Casos en los que NO debes activarlo:
- Middleware que valida, transforma o lee el body (por ejemplo, sanitizar payloads antes de llegar al handler).
- Webhooks donde la verificación de firma o el parseo ocurre en el middleware.
- Cualquier lógica que dependa de leer
request.bodydirectamente enmiddleware.ts.
La regla mental: si dudas, déjalo en false. La mejora de TTFB y de Fast Origin Transfer es bienvenida, pero romper un middleware que sí consume el body es un bug silencioso que solo verás en producción.
¿Qué significa esto para tu startup?
Para la mayoría de founders, este tipo de optimización vive en la capa invisible del stack: nadie se queja del TTFB hasta que se vuelve un problema, y la factura de Fast Origin Transfer crece sin que nadie la mire hasta que duele. La nueva opción de Vercel te da un knob explícito para atacar ambos frentes sin reescribir lógica.
Acciones concretas que puedes tomar esta semana:
- Audita tu
middleware.ts: abre el archivo y busca cualquier llamada arequest.json(),request.formData(),request.text()o lectura derequest.body. Si no hay ninguna, eres candidato a activarskipMiddlewareRequestBody: truey medir el antes y después. - Mide TTFB antes y después: usa Vercel Analytics o tu APM favorito (Datadog, Sentry, OpenTelemetry) para comparar el TTFB en rutas con middleware. Hazlo primero en staging y solo después en producción. El changelog no publica un número concreto de mejora, así que la única forma de saber cuánto te sirve es medirlo en tu propio tráfico.
- Revisa tu factura de Fast Origin Transfer: si tu proyecto tiene mucho tráfico y bodies grandes, la reducción de transferencia al middleware puede ser visible en la consola de Vercel. No hay cifra pública de ahorro típico, así que el proxy correcto es comparar el consumo de Fast Origin Transfer antes y después del cambio.
Un detalle de timing que importa: como el cambio requiere redeploy, coordínalo con tu ventana de despliegue habitual. Activarlo en un viernes a las 6pm y descubrir el lunes que tu middleware leía el body es una forma perfectamente evitable de empezar la semana.
Fuentes
- Skip sending request bodies to Routing Middleware – Vercel Changelog (fuente original)
¿Y esto cómo se aplica en tu negocio?
En CAR, dueños de empresa de Latinoamérica y España usan la tecnología para ser más rentables. Empiezas con una ruta de 7 días y terminas con un sistema funcionando en tu negocio.
👥 Probar 7 días














