1) Requisitos previos

• Repo en GitHub/GitLab/Bitbucket con tu app (Next.js, Astro, SvelteKit, Remix o estático).
• Script de build definido (p. ej. next build).
• Variables de entorno por entorno: VERCEL_ENV=development|preview|production.

2) Despliegue paso a paso

1. Conecta tu repo desde Vercel > Add New… > Project.
2. Ajusta la configuración de build:
   • Next.js: Vercel detecta next build.
   • Estático: define npm run build y Output Directory (p. ej. dist).
3. Variables de entorno: crea grupos para Development, Preview y Production.
4. Dominios: añade el dominio y activa redirecciones apex ↔ www.
5. Preview Deployments: cada PR genera una URL para QA.
6. Production: haz merge a main para publicar; activa protección si necesitas aprobación.

3) Optimización de costes (lo que realmente ahorra)

• SSG primero: páginas estáticas desde CDN son más baratas que funciones serverless.
• ISR (Incremental Static Regeneration): usa revalidate para refrescar sin recalcular en cada request.
• Edge para lógica corta (AB testing, reescrituras). Evita conexiones largas en serverless.
• Caché agresiva para assets con Cache-Control e immutable.
• Optimiza imágenes (WebP/AVIF, tamaños responsivos, lazy).
• Reduce tamaño de funciones: menos dependencias, artefactos ligeros, evita SDKs pesados.
• Cron breves con Vercel; mueve trabajos pesados a colas/servicios externos.
• BD y caché: pools y KV/Redis con TTL para reducir invocaciones.
• Logs/analítica: muestreo y niveles más bajos en producción.
• Limpia previews antiguos y medios no usados.
• Monitorea Usage y define alertas internas.

4) Configuración útil (copiar/pegar)

// next.config.js
const nextConfig = {
  reactStrictMode: true,
  swcMinify: true,
  // Artefacto ligero para serverless/edge
  output: 'standalone',
  images: {
    formats: ['image/avif', 'image/webp'],
    minimumCacheTTL: 31536000
  },
  experimental: {
    optimizePackageImports: ['lodash', 'date-fns']
  }
};
module.exports = nextConfig;

{
  "headers": [
    {
      "source": "/(.*)\\.(js|css|jpg|jpeg|png|webp|avif|svg|woff2)",
      "headers": [
        { "key": "Cache-Control", "value": "public, max-age=31536000, immutable" }
      ]
    }
  ],
  "redirects": [
    { "source": "/www/(.*)", "destination": "/$1", "permanent": true }
  ]
}

// app/blog/[slug]/page.tsx — ISR (App Router)
export const revalidate = 60; // revalida cada 60s

// app/api/revalidate/route.ts — revalidación bajo demanda
import { revalidatePath } from 'next/cache';
export async function POST(req: Request) {
  const { path } = await req.json();
  revalidatePath(path);
  return Response.json({ revalidated: true, now: Date.now() });
}

// middleware.ts — lógica barata en Edge
import { NextResponse } from 'next/server';
import type { NextRequest } from 'next/server';

export const config = { matcher: ['/es/:path*'] };

export function middleware(req: NextRequest) {
  const url = req.nextUrl.clone();
  if (!url.pathname.endsWith('/')) url.pathname += '/';
  return NextResponse.rewrite(url);
}

5) Checklist de ahorro rápido

• ¿Páginas críticas como SSG/ISR?
• ¿Imágenes en AVIF/WebP y tamaños correctos?
• ¿Funciones serverless con pocos MB y sin dependencias pesadas?
• ¿Caché CDN y headers immutable para assets?
• ¿Previews antiguos eliminados?
• ¿Logs/analítica muestreados?
• ¿Cron jobs breves y trabajos pesados fuera?
• ¿Revisión del Usage semanal?

6) Errores comunes que encarecen

• SSR en cada request sin necesidad.
• Subir imágenes gigantes sin optimizar.
• Acumular deployments de preview.
• Hacer warming constante a funciones.
• Incluir SDKs nativos pesados dentro de funciones.

7) FAQ

¿SSR es siempre más caro? No siempre, pero cada request ejecuta compute. Si puedes cachear o usar ISR, suele salir más barato.

¿Conviene Edge para todo? Úsalo para lógica corta cerca del usuario. Para tareas intensivas o dependencias nativas, mejor serverless tradicional o un worker externo.

¿Cómo bajo el TTFB sin gastar más? Pre-render, CDN, HTML mínimo primero y carga diferida de JS.