Netlify vs Vercel vs Cloudflare Pages: cuál elegir y por qué nosotros usamos Cloudflare

No es una decisión trivial

Las tres plataformas compiten en el mismo espacio — deploy de webs estáticas, CDN global, funciones en el edge — y las tres hacen bien su trabajo básico. La decisión importa no porque una sea claramente mejor que las otras, sino porque afecta a velocidad real, estructura de costes y cuánto dependerás de decisiones que toma otra empresa.

Hemos desplegado proyectos en las tres. Clientes en Netlify que llevaban años ahí y funcionaba bien, proyectos Next.js en Vercel que era la opción obvia, y desde hace un tiempo Cloudflare Pages como elección por defecto para prácticamente todo lo que construimos en Astro. Esta no es una comparativa neutral — es el razonamiento que seguimos nosotros.

Vercel: excelente si usas Next.js, caro si escalas

Vercel construyó Next.js. Eso se nota en todo: el DX es el mejor del mercado si trabajas con ese framework, los despliegues son rápidos, los preview deployments funcionan de forma impecable y la integración con el ecosistema de Vercel es fluida. Si tienes un equipo que ya conoce el stack y un proyecto Next.js con SSR intensivo, Vercel es difícil de superar técnicamente.

El problema empieza cuando el proyecto crece. El pricing de Vercel escala rápido en cuanto tienes volumen real de tráfico o empiezas a usar funciones serverless con frecuencia. Hemos visto proyectos que pasaron de 0 a facturas de tres cifras en pocos meses sin haber hecho nada especialmente intensivo — simplemente por el modelo de precios de las invocaciones de funciones.

El otro problema, más sutil pero más importante a largo plazo, es el lock-in. Next.js tiene características que solo funcionan al 100% en Vercel: el Image Optimization API, algunos comportamientos del App Router, las edge functions con ciertos patrones de caché. Migrar un proyecto Next.js complejo de Vercel a otra plataforma no es imposible, pero tampoco es trivial. Eso hay que saberlo antes de empezar, no cuando ya quieres salir.

Lo elegiríamos para proyectos Next.js con SSR intensivo donde el equipo ya domina el stack y el presupuesto de infraestructura aguanta el escalado. No lo elegiríamos para webs mayoritariamente estáticas o proyectos donde el control de costes a largo plazo es prioritario.

Netlify: pionero que sigue siendo válido en su nicho

Netlify fue el primero en popularizar el concepto de deploy automático desde Git para webs estáticas. Su interfaz es la más amigable de las tres — cualquier persona con acceso al repositorio puede entender qué está pasando y hacer un despliegue sin necesidad de conocimientos técnicos. Eso tiene valor real en proyectos donde el cliente gestiona él mismo los cambios.

Los formularios integrados de Netlify son cómodos: sin backend propio, sin configuración de servidor, con notificaciones por email incluidas. Para proyectos pequeños donde el cliente necesita recibir contactos del formulario web y no quiere (ni debe) gestionar un backend, Netlify Forms resuelve el problema con cero fricción.

Donde flojea es en el rendimiento puro. La red CDN de Netlify es correcta pero no está ni cerca de la cobertura de Cloudflare. En mercados fuera de Norteamérica y Europa Occidental, la diferencia de latencia se nota. Los build times también son más lentos que los de Vercel y Cloudflare para proyectos equivalentes, lo que acaba siendo un factor cuando trabajas con repositorios grandes o tienes muchos deploys al día.

Lo elegiríamos para proyectos pequeños o medianos donde el cliente va a gestionar el deploy él mismo, donde los formularios sin backend son suficientes, y donde el presupuesto de infraestructura es prácticamente cero. No lo elegiríamos como plataforma base para proyectos donde la velocidad de carga en mercados internacionales sea un criterio.

Cloudflare Pages: por qué es nuestra elección

La razón principal es la red. Cloudflare opera más de 300 ubicaciones edge en todo el mundo — la red privada más grande del planeta, por delante de cualquier cloud provider. Eso significa que cuando un usuario carga una web desplegada en Cloudflare Pages, el HTML estático se sirve desde un nodo geográficamente muy próximo a él, prácticamente siempre. La latencia en mercados como Latinoamérica, Asia o Oriente Medio es sustancialmente mejor que en las alternativas.

El pricing es generoso de forma que el escalado no da sustos. El plan gratuito aguanta mucho tráfico, y cuando se pasa al plan de pago los costes son predecibles — no hay modelo de facturación por invocaciones que pueda dispararse. Para proyectos de clientes con presupuesto ajustado y crecimiento incierto, eso importa.

Los Workers integrados son otra ventaja real. A diferencia de las funciones serverless de Vercel o Netlify, Cloudflare Workers corre en el edge sin cold starts apreciables — el tiempo de arranque en frío es de microsegundos, no de cientos de milisegundos. Cuando necesitas lógica en el servidor (redirecciones condicionales, autenticación ligera, manipulación de respuestas), Workers es notablemente más rápido en la primera petición.

El ecosistema de Cloudflare también permite ir más lejos sin cambiar de proveedor: KV para almacenamiento clave-valor en el edge, D1 como base de datos SQLite en el edge, R2 para almacenamiento de objetos compatible con S3. Para proyectos que empiezan como webs estáticas y evolucionan hacia aplicaciones con algo de lógica, poder escalar dentro del mismo ecosistema sin migrar de plataforma tiene valor.

La integración con Astro es directa — hay un adaptador oficial, el deploy funciona sin configuración especial y los Workers se integran de forma natural con el modelo de islas de Astro.

Lo que no es: la interfaz de Cloudflare no es la más amigable. El panel tiene más opciones, más configuración disponible y más curva de aprendizaje que Netlify. Para un cliente que va a gestionar los deploys él mismo sin perfil técnico, Cloudflare Pages no es la primera opción.

Lo que no te cuentan en las landings

Los cold starts en funciones serverless son un problema real en Vercel y Netlify que aparece más en producción que en desarrollo. Una función que no se ha invocado en los últimos minutos tarda varios cientos de milisegundos en arrancar. En páginas donde esa función es parte del camino crítico de carga, el usuario lo nota. Cloudflare Workers tiene cold starts tan bajos que son irrelevantes en la práctica.

Los límites de build minutes en planes gratuitos se alcanzan antes de lo que parece si tienes varios proyectos activos o si el CI corre deploys frecuentes. No es un drama — se actualiza el plan — pero hay que tenerlo en cuenta en la planificación inicial.

El vendor lock-in de Vercel con Next.js es mayor de lo que parece al principio. Algunos patrones de Next.js —especialmente los más recientes del App Router— asumen implícitamente la infraestructura de Vercel para funcionar con el rendimiento esperado. Descubrir esto cuando ya tienes el proyecto en producción es tarde.

Migrar entre plataformas es más fácil de lo que parece si el proyecto es verdaderamente estático. Un sitio Astro que genera HTML en build time se puede mover de Netlify a Cloudflare Pages en una tarde: conectar el repositorio, configurar las variables de entorno y apuntar el DNS. El lock-in real viene con las funciones, las integraciones nativas de cada plataforma y el runtime específico de cada proveedor.

Nuestra decisión

Usamos Cloudflare Pages por defecto en todos los proyectos Astro. No porque Vercel o Netlify sean malos, sino porque la combinación Astro + Cloudflare da el mejor resultado en velocidad real, coste predecible y control técnico sin depender de un ecosistema propietario.

Para proyectos Next.js, evaluamos Vercel caso por caso. Si el equipo del cliente ya trabaja con ese stack y el presupuesto aguanta el escalado, Vercel es la opción con menos fricción. Si hay dudas sobre los costes a largo plazo o el cliente quiere más independencia de infraestructura, exploramos alternativas.

La plataforma de deploy importa menos de lo que parece si el sitio está bien construido. Un Astro bien optimizado carga rápido en las tres. Donde sí importa — y es donde ponemos el criterio — es en qué pasa en el largo plazo: cómo escalan los costes, cuánta dependencia generas de decisiones de pricing que no controlas y cuánta libertad tienes para mover el proyecto si en algún momento necesitas hacerlo.