Despliega Next.js en Vercel: costes y rendimiento reales

Desplegar Next.js en Vercel es la vía de menor fricción que existe: conectas el repo, haces git push y en segundos tienes preview deployments, HTTPS, CDN global e ISR funcionando sin tocar infraestructura. El problema no es arrancar, es lo que pasa cuando el proyecto crece: la factura empieza a moverse y no siempre entiendes por qué. Aquí van los costes reales de 2026, dónde están las sorpresas y cómo exprimir el rendimiento sin dispararlos.

Hobby vs Pro: qué incluye cada plan

El plan Hobby es gratis pero solo para proyectos no comerciales. En cuanto tu proyecto genera ingresos, Vercel te obliga a pasar a Pro ($20 por usuario/mes, con $20 de crédito de uso mensual incluido por asiento).

Estos son los límites incluidos a día de hoy:

La diferencia clave no es solo la cuota: el Hobby tiene límites duros (si los superas, se corta), mientras que el Pro es elástico y factura el exceso. Eso es cómodo y peligroso a partes iguales.

Cuándo empiezas a pagar de verdad

Con el crédito de $20 por asiento, un proyecto pequeño (decenas de miles de visitas al mes) suele quedar cubierto: pagas los $20 del asiento y poco más. El punto de inflexión llega alrededor de 1 TB de egress mensual. A partir de ahí, cada recurso factura por separado y las cifras escalan rápido.

Las sorpresas más comunes en la factura:

• Edge Requests: cuenta cada asset de cada visita. Una página con 35 recursos (imágenes, scripts, CSS) más una llamada a API son 36 edge requests por visita. Con tráfico real, este contador se dispara.
• Active CPU: se factura el tiempo de CPU que tu función consume de verdad; el tiempo esperando I/O (una query a base de datos, un fetch) no cuenta. Un await lento no te cuesta CPU, pero un render pesado sí.
• Fast Origin Transfer: datos que van de tu función al edge. Fácil de ignorar hasta que devuelves respuestas grandes sin cachear.
• Edge Middleware: si tu middleware.ts corre en todas las rutas (incluidos assets), multiplicas invocaciones sin darte cuenta.
• Image Optimization: se factura por imagen de origen procesada, más lecturas y escrituras de caché. En sitios con muchas imágenes distintas, suma.
• Marketplace add-ons: Postgres, KV, Blob... se facturan aparte del plan.

El error típico es mirar solo el bandwidth y olvidar que hay siete u ocho contadores corriendo en paralelo.

Rendimiento real

Lo que sí cumple Vercel es el rendimiento base:

• Edge Network / CDN: los assets estáticos y las páginas cacheadas se sirven desde el POP más cercano al usuario. La latencia de contenido estático es excelente sin configurar nada.
• Cold starts: históricamente el talón de Aquiles del serverless. Con Fluid Compute (hoy el modelo por defecto), Vercel reutiliza instancias entre invocaciones y reduce drásticamente los arranques en frío. Sigue habiendo cold starts en picos o tras inactividad, pero son mucho menos frecuentes que hace un par de años.
• Streaming SSR: con React 19 y el App Router, puedes enviar HTML en trozos y usar <Suspense> para que el contenido crítico llegue antes mientras lo pesado sigue cargando.
• ISR (Incremental Static Regeneration): regeneras páginas estáticas en segundo plano sin rebuild completo. Es la mejor relación coste/rendimiento para contenido semi-dinámico como un blog.

Un patrón de streaming con Suspense en el App Router:

import { Suspense } from "react";

export default function Page() {
  return (
    <section>
      <Header /> {/* llega al instante */}
      <Suspense fallback={<PostsSkeleton />}>
        <Posts /> {/* async, no bloquea el resto */}
      </Suspense>
    </section>
  );
}

async function Posts() {
  const posts = await fetchPosts(); // se transmite cuando resuelve
  return <PostList posts={posts} />;
}

Optimizaciones concretas para reducir costes

1. Cachea de forma agresiva con ISR

Cada página regenerada por ISR es una página que no invoca una función serverless en cada visita. En un blog, servir contenido estático revalidado cada hora en lugar de renderizar en cada request cambia por completo el consumo de CPU y funciones:

// app/blog/[slug]/page.tsx
export const revalidate = 3600; // revalida como mucho cada hora

export async function generateStaticParams() {
  const posts = await fetchAllSlugs();
  return posts.map((slug) => ({ slug }));
}

2. Controla Image Optimization

El componente <Image> es potente, pero cada tamaño y formato distinto genera una transformación facturable. Limita los sizes, sirve dimensiones razonables y, si tienes muchísimas imágenes, valora un loader externo o desactivar la optimización para assets que ya vienen optimizados:

import Image from "next/image";

<Image
  src="/portada.webp"
  alt="Portada"
  width={1200}
  height={630}
  sizes="(max-width: 768px) 100vw, 800px"
/>

3. Evita el over-fetching en Server Components

Cada fetch sin cachear en un Server Component puede convertirse en una invocación con su Active CPU y su Fast Origin Transfer. Marca explícitamente qué se cachea y qué no:

// Cacheado y revalidado: barato
const data = await fetch(url, { next: { revalidate: 60 } });

// Siempre dinámico: úsalo solo cuando de verdad lo necesites
const live = await fetch(url, { cache: "no-store" });

4. Edge vs Serverless: elige con criterio

No todo debe correr en el edge. El Edge Runtime es ideal para lógica ligera y con baja latencia (redirecciones, geolocalización, A/B testing en middleware). Para trabajo pesado, acceso a bases de datos o librerías Node completas, las funciones serverless (Node runtime) suelen salir más rentables y sencillas.

// Solo si la lógica es ligera y necesitas latencia mínima
export const runtime = "edge";

Y mantén el middleware.ts acotado con un matcher para que no corra en assets estáticos:

export const config = {
  matcher: ["/((?!_next/static|_next/image|favicon.ico).*)"],
};

¿Merece la pena Vercel? Comparativa breve

La conclusión práctica: por debajo de ~1 TB de egress al mes y con un equipo pequeño, Vercel es difícil de superar en relación productividad/coste. Por encima de ese umbral, o cuando el middleware y las imágenes disparan contadores en cada request, toca hacer números: Cloudflare (egress gratis) o un VPS con Next.js en Docker pueden dividir la factura entre varios.

Siguientes pasos

Antes de que la factura te sorprenda:

1. Activa Spend Management en Vercel para poner topes de gasto y alertas.
2. Revisa la pestaña de Usage y localiza qué contador domina tu consumo.
3. Ataca primero lo que más cuesta: normalmente egress e Image Optimization.
4. Cachea todo lo cacheable con ISR y recorta el alcance del middleware.

Vercel no es caro por definición; es caro cuando lo usas como si el render dinámico fuese gratis. Con caché agresiva y contadores bajo control, el plan Pro cunde muchísimo antes de plantearte mudarte.