El Precio Oculto del Zero-Config en Vercel: 50ms de Cold Start Que Te Van a Costar Clientes

La Promesa del "Zero-Config" es una Mentira Cómoda

No te culpo. Has visto el anuncio: haz push a git, Vercel detecta el framework, desplegado en 30 segundos.

*Parece magia. Y como toda magia, esconde un truco que pagarás después. *

El 90% de los proyectos que llegan a producción en Vercel tienen un problema común: el equipo que los desplegó no entiende qué está pasando entre el push y la respuesta del usuario.

Y cuando algo falla — un cold start de 200ms en hora punta, una Edge Function que tarda más que un Node.js servidor, un límite del free tier que tumba tu web un viernes por la noche — no saben dónde mirar.

*El "zero-config" no es una feature. Es una abstracción que esconde deuda técnica. *

Yo mismo caí. Mis primeros deploys en Vercel fueron "push and pray". Subía el código, veía el check verde, y asumía que todo iba bien. Hasta que un cliente me llamó un sábado porque su web de gestorías cargaba en 8 segundos.

El culpable: una Edge Function con cold start que se ejecutaba en cada petición porque no había configurado ISR ni caching.

Los 3 Engaños que el Dashboard de Vercel No Te Muestra

1. El Cold Start No es Instantáneo — Es 50-200ms de Muerte Lenta

Vercel anuncia "serverless instant". La documentación de Edge Functions promete rendimiento global distribuido.

Los benchmarks de la comunidad dicen otra cosa.

*Las Edge Functions de Vercel tienen cold starts de 50 a 200ms en la primera invocación. *

❌ Lo que Vercel te hace creer: "Las Edge Functions se ejecutan al instante, como un proceso Node.js persistente."

✅ La realidad: Un proceso Node.js persistente responde en <10ms. Una Edge Function en frío puede tardar 20 veces más.

¿Cuándo importa esto?

Una API pública que recibe tráfico esporádico: cada petición puede tener cold start. Si un usuario llega desde Google, espera 200ms antes de ver el primer byte. Adiós Core Web Vitals.
Un webhook que se ejecuta cada hora: frío siempre. Tu "serverless instant" es en realidad "serverless eventual".
Tráfico en bursts: después de un periodo de inactividad, el primer usuario paga el arranque.

El truco está en que Vercel mantiene las funciones calientes si hay tráfico constante. Pero "constante" no significa lo que crees. Una función que recibe una petición cada 5 minutos puede enfriarse entre llamadas.

*La abstracción te oculta que el cold start existe. Y lo que no ves, no lo optimizas. *

2. Las APIs Propietarias Son un Lock-In Silencioso

Aquí está el problema más peligroso. No es obvio. No duele hasta que intentas irte.

Vercel ha construido un ecosistema de APIs que solo funcionan dentro de Vercel:

Ese fichero tiene 3 dependencias directas del ecosistema Vercel: @vercel/og, @vercel/analytics, @vercel/blob.

*Si mañana decides migrar a Cloudflare, AWS, o Fly.io, ese fichero entero hay que reescribirlo. *

No es código portable. Es código hipotecado.

`@vercel/og`: No hay alternativa directa fuera de Vercel. Satori (la librería subyacente) existe, pero la integración automática con JSX y fuentes no.
`@vercel/analytics`: Web Vitals y page views atados al dashboard de Vercel. Si migras, pierdes todo el histórico.
`@vercel/blob`: Almacenamiento de ficheros. Funciona, pero migrar a S3 o R2 requiere cambiar APIs y URLs.

Y el caso más grave: ISR (Incremental Static Regeneration).

ISR es la killer feature de Next.js en Vercel. Te permite revalidar páginas estáticas sin redeploy. Es elegante. Es rápido. *Y no funciona igual en ningún otro host. *

En Vercel, ISR es gestionado por su Edge Network. En AWS o Cloudflare tienes que implementar tu propia lógica de revalidación con Lambda@Edge, CloudFront Functions, o un worker personalizado.

No es imposible. Pero requiere entender lo que Vercel abstrae.

3. El Free Tier Es una Trampa de Crecimiento

Vercel tiene un free tier generoso. 100 GB de ancho de banda, 6000 minutos de build al mes, 1 ejecución concurrente de serverless functions.

*El problema no es lo que incluye. Es lo que calla. *

Tu proyecto crece. El tráfico aumenta. Un día, sin aviso, llegas al límite de ancho de banda. La web deja de servir contenido. No es un error 500. Es un error 402 — Payload Too Large o directamente un bloqueo.
La ejecución concurrente única significa que si dos usuarios hacen una petición a una serverless function al mismo tiempo, una espera. En hora punta, eso se traduce en timeouts.
Los 6000 minutos de build suenan a mucho hasta que haces CI/CD con preview deployments. Cada push a cada branch dispara un build. 10 developers, 5 branches activas, 3 deploys al día. Adiós al límite.

Y el upgrade a Pro no es barato. Pero no voy a hablar de dinero aquí. Lo relevante es que la arquitectura de tu proyecto no debería cambiar porque cambies de tier.

*Si tu proyecto funciona en el free tier pero se rompe al escalar, es porque tu arquitectura depende de lo que Vercel te regala, no de lo que has construido. *

El Framework de 5 Pasos para Auditar tu Dependencia Real de Vercel

Aquí está lo que necesitas. No es teoría. Es el checklist que uso en cada proyecto que despliego.

Lo llamo *El Marco de Despliegue Consciente *.

Paso 1: Inventaria tus APIs Propietarias

Abre tu proyecto. Busca en todo el código @vercel/, vercel.json, y cualquier import de next/server que use NextRequest en lugar de Request nativo.

Si encuentras más de 3 imports de @vercel/*, tienes lock-in sintomático. No es terminal, pero necesitas planificar la migración a alternativas portables.

Paso 2: Mide tus Cold Starts Reales

No confíes en lo que promete el dashboard. Mide tú mismo.

Corre este middleware durante 24 horas en producción. Si ves cold starts por encima de 100ms en más del 20% de las peticiones, tienes un problema de arquitectura.

Paso 3: Decide Qué Va en Edge y Qué en Node.js

La regla es simple:

Edge Functions: Ideal para redirecciones, rewrites, A/B testing, geolocalización, auth checks ligeros. Operaciones que no necesitan acceso a sistemas de ficheros, bases de datos pesadas, o APIs síncronas.
Node.js (Serverless Functions): Para APIs con lógica compleja, acceso a bases de datos, procesamiento de ficheros, integraciones con librerías pesadas.

❌ Error común: Meter toda la lógica en Edge Functions porque "son más rápidas". No lo son si tienen cold start cada vez.

✅ Acierto: Usar Edge Functions solo para routing y transformaciones ligeras. El peso pesado en Node.js con warm persistent.

Paso 4: Configura ISR con Cabeza Fría

ISR es la feature más pegajosa de Next.js en Vercel. *Pero no la uses sin entender el modelo de revalidación. *

La revalidación on-demand es más eficiente que el time-based revalidate. Solo regeneras cuando hay contenido nuevo. No desperdicias ejecuciones.

Paso 5: Diseña una Estrategia de Salida

Este es el paso que nadie hace. Y el que más duele cuando toca migrar.

*Antes de desplegar la primera línea en Vercel, define cómo saldrías de Vercel. *

Este patrón de adapter te permite cambiar de backend de almacenamiento sin cambiar la lógica de negocio. Un día de trabajo en lugar de una reescritura de dos meses.

No Abandones Vercel. Pero Entiéndelo.

No te estoy diciendo que dejes Vercel. Yo mismo lo uso. Despliego proyectos personales y de clientes en Vercel cada semana.

*El problema no es usar Vercel. El problema es usarlo sin entenderlo. *

El "zero-config" es genial para:

Un MVP que quieres validar en 24 horas
Un proyecto personal con tráfico bajo
Una landing page estática con un par de formularios

No es genial para:

Una API que sirve a miles de usuarios concurrentes
Un proyecto que planeas migrar a otro host en el futuro
Una aplicación con dependencias de almacenamiento o procesamiento pesado

La próxima vez que veas el check verde de Vercel, no celebres el deploy.

*Pregúntate: ¿he construido un proyecto que funciona en Vercel, o un proyecto que solo funciona en Vercel? *

La diferencia entre una y otra respuesta determina si tienes un producto o una dependencia.