Las Edge Functions llevaban años vendiéndose como la pieza que acercaba la lógica de una web al usuario, sin pasar por un servidor central. En julio de 2026 Vercel, una de las plataformas que más las promocionó, les puso la etiqueta de obsoletas y empezó a recomendar otra cosa. No significa que el edge computing se acabe: Cloudflare y AWS siguen invirtiendo en él. Significa que, si tu equipo técnico tiene que decidir dónde correr redirecciones, pruebas A/B o personalización geográfica, el mapa de opciones cambió este año y conviene mirarlo antes de migrar nada.
Vercel dejó de recomendar sus Edge Functions en julio de 2026 y empuja a sus clientes hacia funciones Node.js con Fluid Compute. Cloudflare Workers, en cambio, sigue activo: el plan gratuito da 100.000 peticiones al día y el de pago, desde 5 dólares al mes, incluye 10 millones de peticiones y 30 millones de milisegundos de CPU.
Qué cambia con el adiós a las Edge Functions de Vercel
El cambio no es cosmético. Antes, cualquier equipo que desplegara en Vercel podía declarar una función como edge y conseguir que corriera en el perímetro de la red, cerca del visitante, con arranque casi instantáneo. Desde julio de 2026 la documentación oficial lo desaconseja de forma explícita para proyectos nuevos y remite a las funciones con runtime Node.js, que ahora incorporan Fluid Compute: escalado automático de la concurrencia y soporte completo de la API de Node, incluido el acceso a paquetes npm nativos que el runtime edge nunca soportó bien.
Una función edge es un fragmento de código que se ejecuta en los nodos de un CDN, repartidos por decenas de ciudades, en lugar de en un único servidor central: la petición se resuelve en el punto más cercano al visitante.
El middleware de enrutamiento no desaparece
La propia documentación de Vercel aclara que el llamado routing middleware —el código que decide redirecciones o cabeceras antes de que la petición llegue a la función— sigue usando el runtime edge por defecto, y eso está soportado y es esperado, no un descuido. La retirada afecta solo a las funciones edge independientes: las que un desarrollador escribe a propósito para lógica de negocio, como calcular un precio según el país o decidir qué variante de una landing mostrar. Si tu web usa un plugin o un middleware de framework para esas tareas, no hay nada que migrar todavía; si tiene funciones edge propias escritas a mano, sí.
Cloudflare Workers no sigue el mismo camino
Cloudflare no ha tocado la propuesta de Workers, su plataforma de funciones edge, y la sigue vendiendo como pieza central de su red. El plan gratuito permite 100.000 peticiones al día con hasta 10 milisegundos de CPU por invocación, suficiente para una redirección, una cabecera de seguridad o una comprobación de autenticación. En el momento en que una web necesita más volumen o funciones con más lógica, pasa al plan de pago: 5 dólares al mes mínimo, con 10 millones de peticiones y 30 millones de milisegundos de CPU incluidos. La diferencia con el modelo que abandona Vercel es clara: aquí la función edge sigue siendo el producto, no un extra en desuso.
El coste cambia de peticiones a tiempo de CPU
El matiz que se le escapa a muchos equipos es que Cloudflare no cobra solo por petición: cobra también por el tiempo de CPU que consume cada función, y ahí es donde se dispara la factura de una función mal escrita. Superado el plan de 5 dólares, cada millón de peticiones adicionales cuesta 0,30 dólares y cada millón de milisegundos de CPU adicionales, 0,02 dólares. Una función que solo lee una cabecera y redirige gasta un par de milisegundos; una que llama a una API externa o manipula un documento JSON entero puede gastar cien veces más. Es el mismo patrón que ya vimos con los minutos de computación en GitHub Actions: lo gratuito tiene fondo, y el CI/CD también se dispara cuando se agotan los minutos gratis. El ahorro real no está en elegir la plataforma más barata sobre el papel, sino en medir cuánto tarda la función que de verdad vas a desplegar.
¿Te ayudamos con esto?
Cuéntanos tu caso
Si esto te afecta, escríbenos en dos líneas y te respondemos por email con una valoración concreta.
AWS ofrece dos velocidades de función edge
AWS nunca llamó a esto Edge Functions, pero lleva más años que nadie ofreciendo lo mismo bajo dos nombres distintos: CloudFront Functions y Lambda@Edge. La primera es deliberadamente limitada —pensada para reescribir una cabecera o decidir una redirección en microsegundos— y la segunda permite ejecutar una función completa, con llamadas a otros servicios, aunque tarde más en arrancar. La diferencia de precio es proporcional a la diferencia de potencia: según la propia documentación de Lambda, Lambda@Edge cobra 0,60 dólares por cada millón de peticiones más el tiempo de ejecución, sin ningún tramo gratuito; CloudFront Functions no llega ni a un sexto de ese precio por invocación y además incluye 2 millones gratis al mes.
Cuándo conviene Lambda@Edge y cuándo CloudFront Functions
El propio ejemplo que publica AWS lo deja claro: 10 millones de ejecuciones de 10 milisegundos cada una cuestan 6,63 dólares en Lambda@Edge —6 dólares de peticiones y 63 centavos de cómputo— frente a una factura muchísimo menor en CloudFront Functions para la misma reescritura simple de cabeceras. La regla práctica es esta: si la función solo toca lo que ya trae la petición —idioma del navegador, cookie de sesión, país detectado por IP— CloudFront Functions basta y sale barato. Si necesita firmar un token, consultar un secreto en otro servicio o llamar a una API externa antes de responder, hace falta Lambda@Edge, con su límite de hasta 5 minutos de ejecución en el borde de la red.
Elegir Edge Functions según el caso de uso
La pregunta que de verdad importa no es qué plataforma gana, sino qué tareas de tu web merecen correr en el borde de la red en lugar de en el servidor de siempre. Una tienda de moda puede usar una función edge para decidir el idioma y la divisa antes de que cargue la página, o para repartir el tráfico en una prueba A/B de su portada —el mismo objetivo que persiguen los feature flags sin necesidad de un redeploy, aplicado antes de que la petición llegue al servidor—. Una empresa de software B2B puede usarla para proteger una ruta privada sin montar un servidor de autenticación aparte, y una cadena de clínicas con sedes en Barcelona, para servir la página de la sede más cercana sin duplicar contenido. En los tres casos la función hace una cosa pequeña y la hace rápido; el error habitual es llevarle lógica de negocio completa, que necesita las garantías de un servidor normal y que un equipo de consultoría de sistemas sabe separar a tiempo.
- Sí aporta valor: redirecciones por idioma o país, cabeceras de seguridad, reparto de tráfico en una prueba A/B, bloqueo de bots conocidos antes de que lleguen al servidor.
- No aporta valor: lógica de precios o stock que depende de una base de datos transaccional, envío de email o generación de un PDF, cualquier proceso que tarde más de unos pocos milisegundos.
- Zona gris: personalización con datos del CRM, que funciona si el dato se cachea en el borde y se vuelve lento si hay que consultarlo en cada petición.
Preguntas frecuentes sobre las funciones edge
¿Debo migrar ya las Edge Functions que tengo en Vercel?
No con urgencia. Vercel sigue ejecutando el código existente: lo que ha cambiado es la recomendación para proyectos nuevos. Si tu función edge actual funciona bien, puedes dejarla y planificar el paso a Node.js con Fluid Compute en el próximo rediseño, en vez de forzar una migración de urgencia que no pide nadie.
¿Cloudflare Workers sustituye a mi servidor actual?
No del todo. Sustituye la parte de lógica ligera y repetitiva —redirecciones, cabeceras, comprobaciones rápidas— que hoy quizá resuelve tu servidor con más retardo del necesario. El resto de tu aplicación, la base de datos y los procesos largos siguen necesitando un servidor o una plataforma de backend convencional detrás.
¿Qué sectores usan más funciones edge?
El ecommerce y el SaaS B2B son los que más las usan, porque resuelven rápido lo que más les cuesta: idioma, divisa, país y control de acceso. En sectores con web mayoritariamente informativa, como el industrial o el de servicios profesionales, el ahorro real suele ser menor y conviene priorizar primero la velocidad de carga básica.
¿Cuánto cuesta mantener una función edge en producción?
Para una web de tamaño medio, con el tráfico dentro del plan gratuito de Cloudflare o de CloudFront Functions, el coste real es cero. Se empieza a pagar cuando se superan los cientos de miles de peticiones diarias o cuando la función hace algo más pesado que leer una cabecera, y entonces conviene medir antes de elegir plataforma.
Fuente: Vercel — Documentación de Edge Functions (deprecated)
