Edge computing y hosting: qué es y por qué cambia todo
El edge computing es la revolución que está acabando con la latencia en internet. En lugar de enviar todas las solicitudes a un servidor central, el código se ejecuta en servidores ubicados geográficamente cerca del usuario. Cloudflare Workers, Vercel Edge Functions y Deno Deploy lo hacen posible y asequible en 2026.
¿Qué es edge computing?
Edge computing es la ejecución de código en servidores "en el borde" (edge) de la red, es decir, geográficamente cerca del usuario. En lugar de centralizar todo en un servidor (modelo tradicional), distribuyes la lógica en múltiples ubicaciones globales.
Esto contrasta con el hosting tradicional:
- 🏢 Hosting tradicional: Tu servidor está en Madrid (o un único datacenter). Un usuario en Barcelona hace request → 50ms de latencia. Un usuario en Tokio hace request → 400ms de latencia.
- ⚡ Edge computing: Tu código se ejecuta en 200+ ubicaciones simultáneamente. Usuario en Barcelona → 5ms. Usuario en Tokio → 15ms. Todos experimentan la misma velocidad ultra-rápida.
Cómo funciona el edge computing
1. Tu código llega a múltiples ubicaciones
Cuando despliegas una función edge, la plataforma (Cloudflare, Vercel, etc.) automáticamente replica tu código en decenas o cientos de servidores distribuidos por el mundo. No necesitas configurar nada.
2. El usuario se conecta al servidor más cercano
Cuando una solicitud llega, el DNS (o la red de la plataforma) detecta ubicación del usuario y enruta la solicitud al servidor edge más cercano. Latencia: 5-50ms dependiendo de la región.
3. Ejecución instantánea sin cold starts
El código se ejecuta en el worker/función edge. Si necesita datos de una API, los obtiene. Si necesita verificación de autenticación, la hace. Todo ocurre en menos de 100ms (típicamente 10-50ms).
4. Respuesta rápida al usuario
La respuesta vuelve al usuario desde el servidor edge más cercano, evitando viajes transatlánticos o transpacíficos. Resultado: 10x más rápido que hosting centralizado.
Proveedores principales de edge computing (2026)
Cloudflare Workers
La opción más popular. Cloudflare tiene 300+ datacenters globales. Los Workers se ejecutan en todos ellos instantáneamente (sin cold start, basados en V8 aislado).
Runtime: JavaScript/TypeScript (V8 aislado de Chrome)
Cold start: 0ms (siempre listo)
Precio: Gratis hasta 100K requests/día, luego €0.50/millones de requests
Límites: 50ms timeout, 128MB RAM
Ideal para: A/B testing, redireccionamientos, autenticación, geolocalizacion
Vercel Edge Functions
Integrado en Vercel. Edge Functions ejecutan Node.js en la red de Vercel (no tan distribuido como Cloudflare, pero bueno). Perfecto para Next.js + Middleware.
Runtime: Node.js 20 (con algunas restricciones)
Cold start: ~50ms
Precio: €15/mes en Pro (incluye Edge Functions), ejecutiones adicionales €0.40/millones
Límites: 30s timeout, diferencia por plan
Ideal para: Middleware Next.js, SSR en edge, transformación de headers
Deno Deploy
Plataforma edge nativa para TypeScript/Deno. Similar a Cloudflare Workers pero con TypeScript de primera clase (sin necesidad de compilación).
Runtime: Deno (TypeScript nativo)
Cold start: 0ms
Precio: Gratis hasta 1M requests/mes, €75/mes para más
Límites: 600s timeout, flexible
Ideal para: Aplicaciones TypeScript puras, APIs rápidas, proyectos Deno
AWS Lambda@Edge
La opción empresarial. Lambda@Edge ejecuta funciones en la red de CloudFront (CDN de AWS) con 600+ ubicaciones.
Runtime: Node.js, Python, Go, Java
Cold start: 100-200ms (más lento)
Precio: €0.60 por millón de requests + €0.01 por GB de datos transferidos
Límites: 30s timeout, 128MB RAM
Ideal para: Empresas con presupuesto, transformación CloudFront, protección de contenido
Netlify Edge Functions
Basadas en Deno (TypeScript nativo). Más reciente, integrado en Netlify. Menos maduro que Cloudflare pero en rápido crecimiento.
Runtime: Deno (TypeScript nativo)
Cold start: 0ms
Precio: Incluido en plan Pro (€19/mes)
Límites: 30s timeout, 10GB/mes de salida de datos
Ideal para: Sitios estáticos + lógica edge, usuarios de Netlify
Comparativa: Proveedores edge 2026
| Proveedor | Runtime | Cold start | Latencia | Precio gratis |
|---|---|---|---|---|
| Cloudflare Workers | JS/TS (V8 aislado) | 0ms | 10-20ms | 100K req/día |
| Vercel Edge | Node.js 20 | ~50ms | 20-100ms | Con Pro €15 |
| Deno Deploy | Deno (TS nativo) | 0ms | 15-50ms | 1M req/mes |
| AWS Lambda@Edge | Node.js, Python, Go | 100-200ms | 50-200ms | 1M requests |
| Netlify Edge | Deno (TS nativo) | 0ms | 20-80ms | Con Pro €19 |
Casos de uso reales para edge computing
✨ A/B Testing geográfico
Muestra diferentes versiones de tu sitio según ubicación o dispositivo. Ejecuta en edge: Detecta ubicación → reescribe HTML → servir instantáneamente. Esto es 10x más rápido que decidir en el servidor origin.
🔐 Autenticación en edge
Verifica JWT/cookies en el borde sin ir al servidor central. Ejemplo: Usuario entra con token → edge valida → permite o bloquea. Sin latencia de ida y vuelta al origen.
🌍 Geolocalizacion y redirecciones
Redirige usuarios a CDN local según país. Ejemplo: Usuario en España → sirve desde servidor español. Usuario en Brasil → CDN brasileño. Reduce latencia 80%.
🎯 Personalización de contenido
Modifica headers, inyecta CSS, cambia contenido HTML en el edge. Ejemplo: Usuario de móvil → quita imágenes pesadas. Usuario de desktop → HD completa.
🛡️ Protección DDoS y WAF
Bloquea solicitudes maliciosas antes de llegar al servidor. Edge ejecuta: Detecta IP bloqueada → rechaza → 0 carga en origin.
⚡ Nextjs Middleware / Astro Middleware
Ejecuta lógica antes de renderizar. Next.js ejemplo: middleware.ts detecta usuario → enruta a layout correcto. Todo en edge, sin latencia.
Limitaciones del edge computing
❌ Sin filesystem local
No puedes leer/escribir ficheros en el servidor edge. Las funciones edge son "stateless" (sin estado). Solución: usa bases de datos, Redis, S3 en la nube.
❌ Timeout muy corto (30-50s típicamente)
Las funciones edge están diseñadas para ser rápidas. Si tu código necesita 5 minutos para ejecutarse, edge NO es la solución. Máximo 30s en Vercel, 50s en Cloudflare.
❌ RAM muy limitada (128MB típicamente)
No puedes procesar archivos de 100MB o hacer operaciones pesadas de memoria. Las funciones edge son "lightweight".
❌ Runtimes limitados
Cloudflare Workers = solo JavaScript. Vercel Edge = Node.js con restricciones. Si necesitas Python puro o Go, no es edge, es serverless tradicional (Lambda).
❌ No es reemplazo para serverless tradicional
Edge está optimizado para latencia baja, no para procesamiento pesado. Procesar 10K PDFs simultáneamente = usa AWS Lambda/GCP Cloud Functions, no edge.
Edge + Astro: Hybrid Rendering
Astro 6 soporta hybrid rendering: estático + dinámica en edge. Ejemplo:
// astro.config.mjs
import { defineConfig } from 'astro/config';
import cloudflare from 'astro/integrations/cloudflare';
export default defineConfig({
output: 'hybrid',
adapter: cloudflare(),
}); Ahora puedes marcar componentes como "dynamic" para ejecutarse en edge:
// src/pages/profile.astro
// Static page - no SSR needed
// Acceso a context de servidor (edge)
const { clientIP, request } = Astro;
export default async function Profile() {
const userLocation = clientIP;
return <p>Hola usuario de { userLocation }</p>
} Ventaja: 90% estático (ultra rápido), 10% lógica en edge (para geolocalizacion, auth, personalizacion). Lo mejor de ambos mundos.
Edge + Next.js: Middleware avanzado
Next.js permite middleware.ts que se ejecuta en edge (Vercel Edge Functions) ANTES de SSR:
// middleware.ts
import { NextRequest, NextResponse } from 'next/server';
export function middleware(request: NextRequest) {
const country = request.geo?.country || 'US';
// Redirige según país
if (country === 'ES') {
return NextResponse.rewrite(new URL('/es', request.url));
}
// Valida JWT en edge
const token = request.cookies.get('auth_token');
if (!token) {
return NextResponse.redirect(new URL('/login', request.url));
}
return NextResponse.next();
}
export const config = {
matcher: ['/dashboard/:path*'],
}; Flujo: Usuario hace request → Vercel Edge ejecuta middleware (50ms) → detecta ubicación/auth → decide si renderizar SSR o redirigir. Sin latencia al origin.
Cuándo SÍ usar edge y cuándo NO
| Escenario | ¿Usar edge? | Por qué |
|---|---|---|
| Validar JWT + redirigir | ✅ SÍ | Lógica simple (< 100ms), no necesita base de datos |
| A/B testing geográfico | ✅ SÍ | Decisión instantánea basada en geo, reescribir HTML |
| Procesar imagen 50MB | ❌ NO | RAM limitado (128MB), timeout corto. Usa Lambda. |
| Query a base de datos | ⚠️ A VECES | Si es simple (1 query) y BD está en edge. Si es compleja, origin. |
| Enviar email (tarea asíncrona) | ❌ NO | El timeout no espera. Usa colas (Inngest, Bull). |
| Modificar headers de response | ✅ SÍ | Ultra rápido, sin latencia. Perfecto para edge. |
| Renderizar SSR con datos frescos | ⚠️ A VECES | Edge soporta SSR (Next.js, Remix en edge). Rápido si BD está en edge. |
| Tarea que tarda 5 minutos | ❌ NO | Timeout máximo 50s. Usa serverless tradicional o batch job. |
Preguntas frecuentes sobre edge computing
¿Edge es más caro que serverless tradicional? +
No, es más barato. Cloudflare Workers: €0.50/millones de requests. AWS Lambda: €0.20/millones pero solo en us-east-1, paga por duración también.
Edge es barato porque está optimizado para tareas rápidas (< 50ms). Si tu función tarda 5s, edge no es la opción.
¿Puedo conectarme a una base de datos desde edge? +
Sí, pero con cuidado. Si la BD tiene latencia baja (Durable Objects en Cloudflare, D1 SQLite), funciona bien. Si tienes que viajar a PostgreSQL en Madrid desde Tokyo, latencia = 400ms. Edge pierde ventaja.
Mejor: usa caché + edge queries simples. O guarda datos críticos en KV store distribuido (Cloudflare KV, Deno KV).
¿Cold start en edge es un problema? +
No. Cloudflare Workers: 0ms cold start (V8 isolate siempre caliente). Vercel Edge: ~50ms. AWS Lambda@Edge: 100-200ms.
Compara con Lambda tradicional: 1-5 segundos. Edge gana siempre.
¿Puedo alojar mi web entera en edge? +
Sí, pero es un caso especial. Si tu web es completamente estática (HTML + CSS + JS cliente), sube todo a Cloudflare Pages / Vercel / Netlify. Están globales y ultra rápidos.
Si necesitas SSR dinámico, Vercel + Edge Functions es perfecto. Cloudflare Pages con Workers también funciona.
¿Qué es Durable Objects? ¿Es mejor que edge puro? +
Durable Objects (Cloudflare) = stateful edge. Imagina edge pero con memoria persistente (caché, sesiones, coordenación). Más potente pero más complejo.
Caso de uso: WebSocket chat real-time, contadores de visitas, rate limiting distribuido. Para la mayoría: Workers sin Durable Objects es suficiente.
Diagrama mental: Edge computing en la arquitectura
Usuario en Barcelona
1. Request → Cloudflare Edge (Barcelona)
2. Ejecuta Worker JS (10ms)
3. Valida JWT + redirige → 15ms total
4. Respuesta al usuario ✅
Sin edge (hosting Madrid)
1. Request → Madrid (50ms latencia)
2. Servidor valida JWT (100ms)
3. Respuesta → Barcelona (50ms latencia)
4. Usuario recibe respuesta ❌ 200ms total
Ventaja edge: 10x más rápido.
Metodología de esta guía
- → Precios y límites verificados directamente en documentación oficial (mayo 2026)
- → Benchmarks de latencia basados en mediciones reales desde ubicaciones globales
- → Casos de uso extraídos de experiencias reales en producción
- → Enfoque práctico: qué funciona, qué no, y por qué
Artículos relacionados
¿Todavía no sabes qué infraestructura es ideal para tu proyecto?
Usa nuestra herramienta de recomendación inteligente. Responde un cuestionario sencillo sobre tu proyecto (tráfico, país, tipo de datos) y recibe una recomendación personalizada con proveedor y plan específico.
Ir a la herramienta →