Edge vs Serverless en Vercel: El Error de Arquitectura Que Nadie Te Advierte (Hasta Que Es Tarde)
Había algo que no cuadraba.
Tenía una API Route en Next.js que debería ser rápida. Era simple — solo autenticaba un token y devolvía un JSON. Pero cada vez que la llamaba en frío, la respuesta tardaba más de lo que esperaba.
Revisé el código tres veces. Nada raro. Revisé Supabase. Todo bien. Y entonces caí: nunca había pensado en qué tipo de función estaba usando.
En Vercel, cada función que despliegas puede ser una cosa u otra. Y la diferencia no es cosmética.
Primero, el contexto que nadie explica bien
Cuando despliegas una función en Vercel, tienes dos runtimes disponibles:
Edge Functions → Corren en V8 isolates (el mismo motor de JavaScript de Chrome). Arrancan en menos de 50ms en frío. Son ligeras, rápidas y se ejecutan cerca del usuario en la red perimetral global de Vercel.
Serverless Functions → Corren en un entorno Node.js completo. Tienen acceso a todo el ecosistema de Node: fs, crypto, librerías nativas, SDKs que no son compatibles con Edge. Pero el arranque en frío es más pesado.
La confusión típica es asumir que todo debería ser Edge porque “es más rápido”. Spoiler: no siempre.
La diferencia real: qué puedes hacer en cada una
Edge Functions
Estas funciones son perfectas cuando:
- Necesitas respuesta ultra-rápida (middleware, auth checks, redirects)
- La lógica no depende de librerías Node.js nativas
- El payload de respuesta es pequeño
- Quieres aprovechar la red perimetral para acercar la respuesta al usuario
Serverless Functions
Estas son las adecuadas cuando:
- Usas SDKs que requieren Node.js (Stripe SDK completo, librerías de PDF, procesamiento de imágenes)
- Tienes operaciones de I/O intensas con bases de datos
- Necesitas streams de datos complejos
- Construyes endpoints de agentes IA con el AI SDK de Vercel
El error que cometí (y que vas a cometer tú también)
Mi API Route de autenticación estaba como Serverless por defecto. Era simple, sin dependencias pesadas, y la estaba penalizando con arranques en frío de Node.js cuando podría haber tenido arranques en menos de 50ms con Edge.
El cambio fue una sola línea:
Y al revés también aplica: tuve otro endpoint que intenté forzar como Edge por inercia, pero usaba el SDK de Resend con configuraciones que no son compatibles con el runtime de Edge. El resultado: errores en producción que no reproducía en local.
La regla práctica que uso ahora
Antes de escribir una función, me hago estas preguntas en orden:
1. ¿Necesita alguna librería con código nativo de Node.js?
Sí → Serverless obligatoriamente.
2. ¿Es un punto de entrada que se llama con frecuencia y necesita respuesta inmediata?
Sí → Edge candidato.
3. ¿Maneja un workload pesado de IA con streams largos?
Serverless + Fluid Compute (Vercel solo cobra cuando la CPU está activa, no durante esperas de I/O).
4. ¿Es middleware, rewrite, redirect o autenticación de token?
Edge sin dudarlo.
Un apunte sobre Fluid Compute en 2026
Esto cambia el cálculo para workloads de IA. Fluid Compute cobra únicamente cuando la CPU está trabajando activamente, no mientras espera respuesta de una API externa o una base de datos.
Dicho de otra forma: si tu Serverless Function está el 80% del tiempo esperando que OpenAI o Anthropic responda, solo pagas por el 20% donde tu código realmente ejecuta. Eso hace que los endpoints de agentes IA sean significativamente más rentables de lo que eran con el modelo de cobro anterior.
Cómo auditar lo que tienes ahora mismo
Si ya tienes un proyecto en Vercel, aquí está el proceso rápido:
- Abre el panel de Functions en tu proyecto de Vercel
- Filtra por duración media de ejecución
- Las funciones con alta duración y lógica simple → candidatas a migrar a Edge
- Las funciones con dependencias complejas que fallan en Edge → muévelas explícitamente a
runtime = 'nodejs'
Usa Speed Insights de Vercel para medir el impacto real después de cada cambio. No te fíes de benchmarks genéricos: mide tus rutas específicas.
El takeaway
Edge vs Serverless no es una decisión religiosa. Es una decisión técnica que depende de tus dependencias y tu patrón de uso.
La mayoría de los desarrolladores en 2026 siguen usando Serverless por defecto para todo porque es el comportamiento predeterminado. Y para muchos casos está bien. Pero si tienes endpoints de alta frecuencia con lógica simple, estás dejando latencia (y rendimiento) sobre la mesa.
Empeza por auditar tus tres rutas más llamadas. Aplica el filtro de preguntas de arriba. Y migra con una sola línea la que más se beneficie de Edge.
Luego activa las alertas de presupuesto en Vercel y el modo Attack Challenge para protegerte de picos inesperados. No dejes que una noche de tráfico anómalo te arruine el mes.
Seguimos construyendo.
