¿Qué problema resuelve Fluid Compute?
Vercel Fluid Compute, que alcanzó GA en 2025, es una plataforma de ejecución de nueva generación que unifica los runtimes que antes estaban separados en «Serverless Functions» y «Edge Functions». Las funciones serverless tradicionales tenían el problema del cobro en tiempo de inactividad bajo el modelo «1 request = 1 contenedor»; las Edge Functions, por su parte, estaban limitadas por un tamaño de código máximo de 50 MB y restricciones de compatibilidad con Node.js. Fluid Compute adopta un modelo de «multi-tenant concurrency» en el que una sola instancia procesa múltiples requests en paralelo, y excluye del cobro el tiempo de espera en I/O. Como resultado, es posible mantener conexiones a la base de datos y al mismo tiempo obtener latencias cercanas al edge, dos características que antes eran mutuamente excluyentes.
A abril de 2026, las opciones del parámetro `runtime` en `next.config.ts` son tres: `"nodejs"`, `"edge"` y `"fluid"`. El valor predeterminado en Next.js 16 es `"fluid"`, y las rutas bajo `/app` corren sobre Fluid salvo que se declare explícitamente `export const runtime = "edge"`. Las Edge Functions han quedado restringidas a casos de uso como la terminación de WebSockets o APIs de latencia extremadamente baja; el debate antes habitual de «¿edge o Lambda?» ha pasado a ser «¿es suficiente con Fluid o se necesita Edge?».
Renderizado en el edge con RSC en Next.js 16
Next.js 16 permite generar el output de streaming de los React Server Components (RSC) en los puntos de presencia (PoP). Concretamente, hace un flush asíncrono de HTML y del payload RSC por cada límite de Suspense, reduciendo el TTFB a alrededor de 40 ms. Lo clave es la ubicación del fetching de datos: aunque con RSC se puede escribir `fetch` que se resuelve íntegramente en el servidor, la regla es evitar la conexión directa a la base de datos de origen e intercalar siempre una capa de caché como Vercel Data Cache (antes Request Memoization), Hyperdrive o PlanetScale Boost.
Los RSC que corren sobre Edge Runtime tienen restricciones: no se pueden usar `fs`, `net` ni `child_process` de Node.js, y la criptografía debe hacerse a través de la Web Crypto API. Con el adapter compatible con edge agregado a finales de 2025, Prisma 6 y Drizzle ORM funcionan sin problemas, mientras que Sequelize y TypeORM siguen recomendándose sobre Fluid. La arquitectura estándar de 2026 es «RSC en Edge, escrituras a la base de datos en Fluid».
```typescript // app/products/[id]/page.tsx export const runtime = "edge"; export const revalidate = 60; export default async function ProductPage({ params }: { params: Promise<{ id: string }> }) { const { id } = await params; const product = await fetch(`${process.env.EDGE_API}/products/${id}`, { next: { revalidate: 60, tags: [`product-${id}`] }, }).then((r) => r.json()); return ( <> <ProductHeader product={product} /> <Suspense fallback={<ReviewsSkeleton />}> <ProductReviews id={id} /> </Suspense> </> ); } ```
Streaming SSR y Partial Prerendering (PPR)
PPR es una funcionalidad introducida de forma experimental en Next.js 14, estabilizada en la versión 15 y habilitada por defecto en la 16. Combina la generación en tiempo de compilación y en tiempo de ejecución para entregar un «shell estático con huecos dinámicos»: el esqueleto HTML generado en el build se devuelve de inmediato desde el PoP, mientras que las partes específicas del usuario (icono del carrito, productos recomendados) se mantienen como límites de Suspense y se envían en flush posterior desde el servidor. Esto permite mantener la tasa de hit en CDN sin sacrificar la personalización.
El problema más común en la implementación es que «en el momento en que se hace referencia a `cookies()` o `headers()`, todo ese árbol se vuelve dinámico». Llamar a `headers()` de forma inadvertida en el layout hace que el shell estático de PPR no se genere y que cada request caiga en SSR completo. Es necesario auditar periódicamente el ratio entre «Static (prerendered)» y «Dynamic (on-demand)» en el log de `next build` y detectar en CI cualquier caída en la tasa de páginas estáticas.
Edge Config y feature flags respaldados por CDN
Edge Config es un almacén JSON de solo lectura ofrecido por Vercel, accesible en menos de 1 ms desde Edge Runtime. En 2026, la solución práctica habitual es construir una infraestructura de feature flags propia usando Edge Config + Vercel Flags SDK, sin recurrir a servicios SaaS como LaunchDarkly o Statsig. Las escrituras se propagan a todas las regiones en segundos a través de la API de administración; las lecturas están incrustadas en el Isolate del runtime, sin latencia de red.
Flags SDK unifica las pruebas A/B y la evaluación de flags en una misma API, y mantiene la identidad sincronizada entre RSC y componentes de cliente. El patrón concreto es: fijar el ID de usuario en una cookie desde el middleware, evaluar `flag("new-checkout").bucket(userId)` dentro del RSC y propagar el resultado como `searchParams` a los componentes hijos. Así, la variante decidida en el servidor en el primer acceso se mantiene también en las navegaciones siguientes, logrando una experiencia tipo SPA desde el edge.
```typescript import { flag } from "@vercel/flags/next"; import { get } from "@vercel/edge-config"; export const newCheckout = flag<boolean>({ key: "new-checkout", async decide({ entities }) { const config = await get<{ rollout: number }>("new-checkout"); const userId = entities?.user?.id ?? "anon"; return hash(userId) % 100 < (config?.rollout ?? 0); }, }); ```
El límite de tamaño de Edge Config se amplió a 512 KB por store y 10 stores por proyecto (a finales de 2025). En la práctica se usa para almacenar valores de configuración que se actualizan cada varios segundos o minutos, como definiciones de flags, tablas de precios o listas de palabras prohibidas por región; no es adecuado para datos que se actualizan con alta frecuencia, como perfiles de usuario, que deben manejarse con KV o Redis.
Observabilidad y sourcemaps
Fluid Compute incluye instrumentación automática de OpenTelemetry: con solo importar el paquete `@vercel/otel`, los traces fluyen a Datadog, Honeycomb o Grafana Cloud. Las llamadas a `fetch` dentro de los RSC generan spans automáticamente; los Web Vitals (LCP, INP, CLS) se recopilan como RUM en un stream separado. A partir de 2026, Vercel Observability Plus permite subir sourcemaps de producción de forma segura y resolver los stack traces hasta el número de línea en TypeScript.
Para la gestión del error budget, el patrón establecido es definir SLOs con VQL (el lenguaje de consulta de Vercel Monitoring) y enviar alertas de burn rate a Slack o PagerDuty. Mostrar en un mismo dashboard la latencia P99 de Edge Functions, las invocaciones concurrentes de Fluid y la tasa de hit de Data Cache permite detectar a tiempo cualquier caída en la tasa estática de PPR o un aumento en los cache misses. En el edge, la clave no es solo la velocidad, sino también la consistencia de esa velocidad.