Vercel o Netlify: el arranque en frío no cuenta toda la factura

Para una aplicación Next.js con renderizado dinámico frecuente, Vercel ofrece la integración más directa. Netlify también admite las funciones principales del framework mediante OpenNext y puede resultar atractivo por su modelo de créditos y colaboración. La elección depende de qué rutas ejecutan código en cada petición, cuánto contenido se sirve desde caché y cómo crece el consumo mensual.

Una respuesta lenta tras un arranque en frío importa para el visitante que la recibe, pero no representa todas las respuestas ni determina por sí sola el coste. Conviene separar la compatibilidad de la aplicación, la latencia de las rutas críticas y las unidades que factura cada plataforma. Una diferencia medida en una prueba externa tampoco equivale a la que verá un usuario en otra región.

Next.js: integración directa y ubicación real de las funciones

La documentación de Next.js en Vercel describe el despliegue sin configuración específica y la creación automática de Vercel Functions para el renderizado del lado del servidor. También distingue el contenido generado y almacenado en caché de las partes que deben renderizarse para cada solicitud. Esa integración reduce las decisiones de infraestructura para un equipo que utiliza las capacidades propias del framework, aunque el comportamiento de sus rutas sigue dependiendo del código y de la política de caché.

La guía de Next.js en Netlify indica que OpenNext configura funciones para SSR, regeneración estática, rutas API y Server Actions, mientras que el middleware se ejecuta mediante Edge Functions. También recoge compatibilidad con App Router, optimización de imágenes y revalidación de caché. Hay una diferencia concreta para aplicaciones sensibles a la ubicación: las páginas SSR configuradas con Edge Runtime se ejecutan en la región de funciones con Node.js, no en una ubicación de borde.

Por tanto, comprobar que una aplicación compila es solo una parte de la comparación. Una página almacenada en caché, una ruta API y una página personalizada pueden activar recursos distintos aunque pertenezcan al mismo proyecto. En Netlify, incluso una página prerenderizada puede requerir una invocación de función en su primer acceso tras un despliegue; ese detalle importa si se estima el uso a partir de una etiqueta general como «estático».

Los planes gratuitos y los costes de equipo

Los precios de Vercel reservan Hobby, de 0 dólares, para uso personal no comercial y sitúan Pro en 20 dólares mensuales con 20 dólares de crédito de uso incluido. Hobby contempla por mes 100 GB de Fast Data Transfer, un millón de invocaciones de funciones y cuatro horas de CPU activa; cada recurso tiene su propio límite. Para una pequeña empresa con una aplicación comercial, el punto de partida pertinente es Pro, que añade colaboración y cobra los recursos aplicables según su modelo de uso. Su oferta actual incluye Flat Rate CDN, por lo que el límite de transferencia de Hobby no debe trasladarse como si fuera la tarifa de Pro.

La tabla de Netlify ofrece Free con 300 créditos mensuales, Personal por 9 dólares con 1.000 créditos y Pro desde 20 dólares con 3.000 créditos y miembros ilimitados. En los planes basados en créditos, cada despliegue de producción consume 15; el cómputo, 10 por GB-hora; la transferencia, 20 por GB; y las peticiones web, dos por cada 10.000. Las vistas previas de despliegue no consumen los créditos asignados a publicaciones de producción.

La bolsa de Netlify reúne usos diferentes: una aplicación puede agotar sus créditos por tráfico aunque apenas ejecute funciones, o por cómputo aunque transfiera pocos datos. Si se alcanza el límite sin recarga, los proyectos de la cuenta pueden quedar pausados hasta el siguiente ciclo o una ampliación. Las cuentas anteriores al modelo de créditos pueden conservar planes heredados, de modo que sus condiciones no se deducen de esta tabla.

Una aplicación, tres volúmenes de tráfico

Supongamos una aplicación Next.js que realiza cuatro despliegues de producción al mes y transfiere una media efectiva de 100 KB por petición HTTP. Es un ejemplo hipotético: una visita puede originar varias peticiones y la compresión, las imágenes y la caché modifican los bytes entregados. Para ilustrar el cómputo, asignemos respectivamente 0,1, uno y diez GB-hora mensuales a tráfico bajo, medio y alto.

• Tráfico bajo: 10.000 peticiones y cerca de 1 GB transferido producirían unos 83 créditos en Netlify: 60 por despliegues, 20 por transferencia, dos por peticiones y uno por cómputo.
• Tráfico medio: 100.000 peticiones y cerca de 10 GB producirían unos 290 créditos: 60 por despliegues, 200 por transferencia, 20 por peticiones y diez por cómputo. El margen frente a Free sería pequeño.
• Tráfico alto: dos millones de peticiones y cerca de 200 GB producirían unos 4.560 créditos: 60 por despliegues, 4.000 por transferencia, 400 por peticiones y 100 por cómputo. Haría falta un nivel superior al Pro inicial o créditos adicionales.

En este supuesto domina la transferencia, no el número de publicaciones ni el cómputo asignado. Una respuesta media más pequeña reduciría esa parte del cálculo; una página que descargue numerosos recursos elevaría el número de peticiones respecto al de visitantes. Los créditos estimados tampoco son una factura universal: otros servicios consumidos por el proyecto, las condiciones del plan y la medición real pueden cambiar el total.

En Vercel, las mismas peticiones de red no equivalen necesariamente a invocaciones de funciones. Una respuesta servida desde caché evita ejecutar la función, aunque siga generando una petición a la red de distribución. Si todas las peticiones del escenario alto ejecutaran una función, superarían la cuota de invocaciones de Hobby; en Pro habría que calcular por separado invocaciones, CPU activa, memoria y las condiciones del CDN. Convertir los créditos de Netlify a dólares y compararlos con una sola cuota de Vercel ocultaría esas diferencias.

Qué mide realmente la prueba de latencia

Una prueba comunitaria de Next.js comunicó un percentil 99 combinado de páginas y API de 1.176 ms para el despliegue en Vercel y 3.266 ms para el de Netlify. El autor observó respuestas calientes más lentas en Netlify y arranques fríos más frecuentes en las rutas API de Vercel. Esos valores describen las configuraciones desplegadas y el tráfico de la prueba, no un tiempo garantizado por ninguna de las plataformas.

El percentil 99 describe el extremo lento de una muestra, no la respuesta habitual. Además, combinar páginas y API junta trabajos distintos: la proporción de cada ruta puede mover el resultado agregado sin que haya cambiado la experiencia en una ruta concreta. La distancia hasta la región de ejecución, la versión de Next.js, el adaptador y la caché también influyen. Por eso la diferencia observada sirve para valorar un riesgo de latencia, pero no permite atribuir cada milisegundo al arranque en frío ni calcular el coste mensual.

Cuándo pesa más cada plataforma

Vercel encaja especialmente bien cuando una aplicación comercial utiliza mucho SSR y otras capacidades de Next.js, y el equipo prefiere la integración directa. Esa comodidad debe presupuestarse con Pro y con el uso efectivo de funciones; la ventaja de latencia de una prueba concreta no sustituye ese cálculo. Si predominan las respuestas almacenadas en caché, el peso de las invocaciones puede ser menor que el sugerido por el tráfico total.

Netlify merece consideración cuando su adaptación de Next.js cubre las rutas críticas y la bolsa de créditos se ajusta al patrón de tráfico y publicaciones del equipo. El ejemplo muestra que una carga moderada puede acercarse al límite gratuito y que, con respuestas grandes, la transferencia puede dominar el gasto. Para aplicaciones que dependen de SSR en el borde, la región donde termina ejecutándose esa función es una diferencia técnica más decisiva que una declaración general de compatibilidad.

Lee también:

• Cloudflare Workers o Vercel: el SSR rápido puede costar más al escalar
• Cloudflare factura un 36% más: el tráfico de máquinas abre otro mercado
• Facturar una colaboración en España: el producto también puede ser pago