De Next.js a Astro + Cloudflare Pages: por qué migramos y cuánto mejoró el rendimiento

Migrar un sitio en producción de un framework a otro no es una decisión que tomamos a la ligera. Cuando heredamos mintec.co, corría sobre Next.js 14 desplegado en Vercel. Funcionaba. Pero tenía problemas: los Core Web Vitals eran inconsistentes, el bundle de JavaScript pesaba 463 KB, los builds tomaban más de 4 minutos, y estábamos pagando $49/mes por un plan Pro que apenas usábamos. Decidimos migrar a Astro + Cloudflare Pages. Este artículo documenta los números reales, las decisiones técnicas y lo que aprendimos en el proceso.

El punto de partida: ¿por qué Next.js no era la respuesta?

Next.js es un framework excelente, pero tiene un sesgo importante: está diseñado para aplicaciones web completas, no para sitios de contenido. En Next.js 14 con SSG (Static Site Generation), cada página genera HTML estático en build time, pero el framework siempre incluye el runtime de React en el bundle del cliente. Eso significa que aunque tu página no tenga un solo componente interactivo, el navegador igual descarga, parsea y ejecuta React — 463 KB de JavaScript que no hacen nada visible para el usuario.

Los números antes de la migración:

El problema no era Next.js per se, sino que estábamos usando la herramienta equivocada para el trabajo. Nuestro sitio es principalmente contenido: páginas de servicios, blog, portfolio. No tenemos dashboards, no tenemos autenticación, no tenemos estado compartido entre páginas. Para lo que necesitábamos, Astro ofrecía una arquitectura más limpia.

La arquitectura Astro + Cloudflare Pages

Astro cambia la premisa fundamental: cero JavaScript por defecto. En lugar de renderizar componentes en el servidor y enviar el runtime al cliente (como hace Next.js), Astro renderiza todo a HTML estático en build time y solo envía JavaScript para componentes que explícitamente lo necesiten (islas).

+------------------+       +------------------+
|     Next.js      |  →   |      Astro       |
|                  |       |                  |
|  React runtime   |       |  Zero JS by      |
|  (463 KB)        |       |  default (0 KB)  |
|  Pages Router    |       |  Content         |
|  API Routes      |       |  Collections     |
|  Image Opt.      |       |  Astro Islands   |
|  Middleware       |       |  View Transitions|
+------------------+       +------------------+
|  Deploy: Vercel  |       |  Deploy: CF      |
|  $49/mes         |       |  Pages: FREE     |
+------------------+       +------------------+

La pila final:

Los números después de la migración

Los resultados de laboratorio (Lighthouse desde simulación de red lenta 3G):

Los datos de campo (Chrome User Experience Report) también mejoraron significativamente. El percentil P75 de LCP pasó de 3.8 s a 1.6 s en visitas desde Latinoamérica, donde la infraestructura de Cloudflare tiene mejor presencia que Vercel.

Lo que sacrificamos

No todo fue ganancia. Migrar tiene costos que hay que conocer:

1. Islas de interactividad. Si necesitas componentes React con estado (formularios dinámicos, carritos, dashboards), Astro los soporta mediante client:load, pero cada isla añade JS al bundle. No es un problema para sitios de contenido, pero sí para aplicaciones interactivas.

2. Sin API routes. Cloudflare Pages Functions pueden reemplazar API routes de Next.js, pero la DX no es tan pulida. Para sitios puramente estáticos como el nuestro, no lo necesitamos.

3. Ecosistema más pequeño. Astro tiene menos componentes, plugins y tutoriales que Next.js. Para casos de uso estándar (blogs, marketing sites, documentación) está más que cubierto, pero encontrar soluciones a problemas muy específicos puede requerir más investigación.

4. View Transitions requiere configuración. Aunque Astro 5+ trae integración nativa de View Transitions API, para que funcione bien entre páginas hay que configurar view-transition-name en elementos compartidos, lo que añade complejidad al CSS.

Cuándo elegir Astro vs Next.js (nuestro framework de decisión)

Basado en nuestra experiencia, este es el framework que usamos en Mintec para cada tipo de proyecto:

Lecciones aprendidas

Si estás considerando una migración similar, esto es lo que haríamos igual y lo que haríamos diferente:

Lo que hicimos bien ✅

• Medimos antes de migrar. Lighthouse, WebPageTest, datos de campo de CrUX. Sin líneas base, no sabes si mejoraste.
• Migramos por fases. Primero las páginas estáticas (home, servicios), luego el blog, después las páginas dinámicas. Cada fase validaba la arquitectura.
• Eliminamos dependencias innecesarias. Aprovechamos la migración para revisar cada dependencia. Pasamos de 23 dependencias a 11.

Lo que haríamos diferente 🔄

• Presupuestar más tiempo para View Transitions. La migración de datos fue rápida (2 días); la configuración de animaciones tomó casi una semana adicional.
• No subestimar la configuración de redirects. Teníamos URLs legacy del sitio anterior que necesitaban 38 redirects. En Cloudflare Pages, los redirects se configuran en un archivo _redirects con sintaxis específica que tiene sus propios edge cases.
• Comunicar el cambio al equipo. Pasamos de un stack conocido (React + Next.js) a uno menos familiar (Astro). La curva de aprendizaje para el equipo fue real.

Conclusión

Migrar de Next.js a Astro + Cloudflare Pages fue la mejor decisión técnica que tomamos para mintec.co. Redujimos el JavaScript en un 94%, mejoramos todos los Core Web Vitals, eliminamos un costo recurrente de $49/mes, y los builds pasaron de 4 minutos a 48 segundos.

Pero no es una receta universal. Next.js sigue siendo superior para aplicaciones web interactivas. La clave está en elegir la herramienta según el tipo de proyecto, no según la moda o la familiaridad.

Si tu sitio es principalmente contenido y estás pagando por funcionalidades que no usas, la migración a Astro probablemente te dé resultados similares. Si necesitas un framework full-stack con dashboards, APIs y autenticación, quédate con Next.js.

Al final, el mejor framework es el que no estorba entre tu contenido y tus usuarios.

¿Tienes un proyecto y no estás seguro de qué stack elegir? En Mintec te ayudamos a tomar la decisión correcta desde el día uno. Contáctanos para una consultoría gratuita de arquitectura web.

Artículos relacionados:

• View Transitions API en producción: patrones que funcionan más allá del demo
• Agentes de IA en backoffice: automatización de operaciones internas