Cómo elegir un stack frontend, con números

Publicado el 19 de noviembre de 2025. Actualizado el 5 de agosto de 2026 con fuentes y umbrales concretos.

Elegí el stack por lo que el proyecto tiene que hacer, no por lo que está de moda. En la práctica se reduce a tres preguntas: cuánto de la página necesita ser interactivo, qué tan rápido tiene que renderizar la primera vista, y quién lo mantiene dentro de un año. Todo lo que sigue es una forma de contestarlas con números en vez de preferencias.

Definí "rápido" antes de elegir nada

"Buen rendimiento" no es una opinión. Google publica umbrales, y una página los cumple sólo si los alcanza en el percentil 75 de las cargas, en móvil y escritorio:

• LCP (largest contentful paint): 2,5 segundos o menos.
• INP (interaction to next paint): 200 milisegundos o menos.
• CLS (cumulative layout shift): 0,1 o menos.

Escribí esos tres números en el brief antes de que alguien discuta frameworks. Una decisión de stack que no podés contrastar contra un umbral es una preferencia, y las preferencias son la razón por la que los equipos terminan rehaciendo todo en dieciocho meses.

La pregunta que realmente separa las opciones

¿Cuánto de la página es interactivo?

Esa sola respuesta elimina más opciones que cualquier comparativa de funcionalidades. Un sitio de documentación es texto con un buscador. Un dashboard es interactivo de punta a punta. No son el mismo problema y no piden la misma herramienta.

Casi todo estático: Astro

El default de Astro es el agresivo. Su documentación es explícita: "por defecto, Astro renderiza automáticamente cada componente de UI a sólo HTML y CSS, quitando todo el JavaScript del cliente". La interactividad se activa componente por componente con las directivas client:*, así que una página envía JavaScript sólo donde lo pediste.

Es el default correcto para blogs, documentación, sitios de marketing y todo aquello donde el LCP es la métrica que importa. La trampa es la que encuentran sus propios usuarios: si el proyecto resulta más interactivo de lo que pensabas, terminás activando hidratación en todos lados y perdés la ventaja por la que lo elegiste.

Mixto, que es la mayoría de los productos: Next.js

Casi todo proyecto real es una superficie pública de marketing más una aplicación con login, y comparten componentes. Next.js está construido para esa costura: renderizado en servidor, generación estática y regeneración incremental en un mismo proyecto, con las convenciones de rutas y datos ya decididas.

El costo es real y conviene nombrarlo: decide muchas cosas por vos. En un sitio chico eso es sobrecarga, y la vas a sentir cada vez que pelees contra una convención en lugar de usarla.

Interactivo de punta a punta: React solo

Una herramienta interna detrás de un login no tiene requisitos de SEO ni presión de primer render desde el buscador. Ahí un meta-framework aporta menos y sus convenciones te cuestan flexibilidad. React con el router que elijas suele ser la respuesta honesta.

El riesgo es el que nadie presupuesta: todo lo que un framework habría decidido —rutas, obtención de datos, división de código, manejo de errores— pasa a ser una decisión que tu equipo toma y sostiene. Con gente senior está bien; sin ella, sale caro.

Comercio en Shopify: Hydrogen

Si la tienda está en Shopify y necesitás un storefront a medida, Hydrogen existe exactamente para eso y se integra directo. Fuera de ese contexto no es una opción de propósito general.

Un detalle que conviene saber antes de asumir que el renderizado en servidor resuelve el SEO solo: Next.js documenta que los bots y rastreadores se detectan por user agent y se manejan distinto — saltea el shell estático y renderiza la página entera en el momento del pedido, porque un rastreador necesita el documento completo. Suele ser lo que querés, y también significa que una página que renderiza bien para una persona puede fallar para un rastreador si el shell dependía de datos que no están disponibles en ese momento. Probá con un rastreador, no con tu navegador.

La restricción que todos se saltean

¿Quién mantiene esto dentro de un año?

Un stack que sólo su autor puede extender es un pasivo, por buenos que sean los benchmarks. Si tu equipo sabe React y la elección ideal es otra cosa, probablemente la elección ideal esté mal — la distancia entre "técnicamente mejor" y "mi equipo entrega con confianza" es donde mueren los presupuestos.

Nuestra lectura, después de tomar esta decisión muchas veces: la segunda mejor tecnología mantenida por gente que la entiende le gana a la mejor que nadie quiere tocar. Es el criterio menos vistoso y el que decide la mayoría de los proyectos.

Cómo decidir en la práctica

Anotá, en este orden: qué porcentaje de la página necesita interactividad en el cliente, cuál es tu objetivo de LCP, quién la mantiene, y si tiene que crecer hacia otra cosa dentro de un año. Si las respuestas son "casi nada", "menos de 2,5 segundos", "un equipo chico" y "probablemente no", estás mirando una herramienta estática primero. Si la interactividad es alta y el SEO es irrelevante, estás mirando una aplicación sin más. La mayoría de los proyectos cae en el medio, y por eso Next.js es la respuesta habitual: no porque sea la mejor, sino porque casi todos los productos son híbridos.

Después comprobalo. A las seis semanas, medí LCP, INP y CLS en el percentil 75 contra los números que anotaste. Una elección de stack que nunca se contrastó contra un umbral nunca fue una decisión.

Preguntas frecuentes

¿Next.js es demasiado para una landing?

Muchas veces sí. Una página de marketing sin aplicación detrás no necesita convenciones de rutas, modos de renderizado en servidor ni regeneración incremental. La razón para elegirlo igual es que esa landing sea la primera pantalla de un producto que vas a construir: migrar después cuesta más que la sobrecarga inicial.

¿Astro significa que no puedo usar React?

No. Astro renderiza componentes de React a HTML estático e hidrata sólo los que marcás con una directiva client:*. Conservás el modelo de componentes y sacás el costo de runtime en todo lo que no lo necesita.

¿Cómo sé si mi stack actual es el problema?

Medí antes de rehacer. Si LCP, INP y CLS están dentro de los umbrales y el equipo entrega a un ritmo razonable, el stack no es tu problema — y una reescritura va a costar meses para llegar a donde ya estabas.

¿Y si elegimos mal?

Los errores reversibles son baratos y los irreversibles son estructurales. Elegir framework suele ser reversible en el plazo de un año. Acoplar tu contenido, tu modelo de datos y tu estrategia de renderizado en algo que entiende una sola persona, no.

Fuentes

• Web Vitals — Google, web.dev. Umbrales de LCP, INP y CLS.
• Caching y Partial Prerendering — documentación oficial de Next.js.
• Islands Architecture — documentación oficial de Astro.