React & Next.js — Aplicaciones web de alto rendimiento
Usamos React 18 y Next.js 15 (App Router) en todos los proyectos de frontend: desde webs corporativas hasta SaaS complejos con decenas de miles de usuarios. El código es TypeScript estricto, las pruebas y el despliegue están automatizados.
Por qué Next.js en nuestros proyectos
Next.js 15 con App Router ofrece un modelo híbrido único: las páginas estáticas (SSG) se sirven desde el CDN, las páginas dinámicas se ejecutan como Server Components que no envían JavaScript innecesario al navegador, y las páginas con datos en tiempo real usan Client Components aislados.
Las imágenes se optimizan automáticamente mediante el componente `<Image>` (WebP/AVIF, srcSet responsive, lazy loading), las fuentes se incrustan en el CSS crítico con `next/font` y los scripts de terceros se cargan con estrategias de prioridad.
- Server Components para las páginas de marketing: cero JS en el cliente, HTML completo generado en el servidor
- Streaming SSR con Suspense para paneles con datos en vivo
- Incremental Static Regeneration (ISR) para contenido semidinámico
- Route Groups y Parallel Routes para maquetaciones complejas sin re-render
TypeScript estricto: sin errores silenciosos
Todos nuestros proyectos usan TypeScript con `strict: true`, `noImplicitAny`, `exactOptionalPropertyTypes` y `noUncheckedIndexedAccess`. Estos ajustes bloquean en tiempo de compilación categorías enteras de errores en producción: acceso a undefined, tipos incompletos en las respuestas de API, comparaciones erróneas. Un proyecto típico llega a CI con 0 errores de TypeScript antes de ejecutar ninguna prueba.
Para la gestión de estado usamos Zustand (ligero, sin boilerplate) o React Context para el estado local. La obtención de datos se gestiona con TanStack Query (caché automática, invalidación inteligente, stale-while-revalidate). Formularios con React Hook Form y validación por esquema Zod: validación síncrona y asíncrona sin duplicar código.
- ESLint con reglas propias para patrones prohibidos (any, console.log, cadenas mágicas)
- Prettier con configuración uniforme: ningún PR se rechaza por formato
- Zod para validar en tiempo de ejecución los datos de API externas
- Alias de rutas (`@/components/...`): importaciones claras sin `../../..`
Pruebas automatizadas y CI/CD
Pruebas unitarias con Vitest (rápido y compatible con la API de Jest), pruebas de componentes con React Testing Library y E2E con Playwright en 3 navegadores (Chromium, Firefox, WebKit). El pipeline de GitHub Actions ejecuta todas las pruebas en cada PR; la fusión se bloquea si alguna falla. Cobertura mínima del 80 % sobre la lógica de negocio.
- Lighthouse CI: una puntuación inferior a 90 bloquea el despliegue en staging
- Analizador de bundle automático: alerta si el bundle crece más de un 5 % respecto a main
- Storybook para los componentes de interfaz: documentación visual viva
Ventajas y limitaciones
Ventajas
- Optimización de imágenes y fuentes integrada: `<Image>` (WebP/AVIF) y `next/font`.
- SSR y SSG nativos: el HTML completo se entrega desde el servidor.
- TypeScript estricto detecta los errores al compilar, no en producción.
- Ecosistema maduro: Vercel, miles de paquetes, una comunidad enorme.
Limitaciones
- La curva de aprendizaje del App Router y los Server Components es pronunciada.
- Cambios frecuentes entre versiones mayores: exige mantenimiento continuo.
- Para una web estática sencilla, Next.js puede ser excesivo frente a HTML puro.
- Los builds grandes aumentan el tiempo de compilación y el coste de CI.
Veredicto breve
Elige React y Next.js para webs y aplicaciones que deban ser rápidas, indexables y escalables. Para una única landing estática sin interactividad, basta con una solución más sencilla.
Tabla de especificaciones
| Capacidad | Límite / umbral | Uso habitual | |
|---|---|---|---|
| Renderizado | SSR, SSG, ISR, CSR | Los Server Components limitan las API del navegador | Marketing estático + panel dinámico |
| Rendimiento | Server Components, `<Image>` y `next/font` | El JS de hidratación crece con la interactividad | Webs de alto tráfico, SEO crítico |
| Escalado | Decenas de miles de usuarios, CDN en el edge | Requiere hosting Node o serverless | SaaS, portales, comercio electrónico |
| Coste típico | Open source, hosting desde ~0 € | Las funciones serverless se facturan por uso | Desde proyectos pequeños hasta empresa |
Next.js frente a las alternativas
| Criterio | Next.js | Nuxt / Astro / Vite |
|---|---|---|
| SSR + SSG en un solo framework | Sí, de forma nativa | Parcial (Nuxt sí, Vite no) |
| Ecosistema React | Completo | Vue (Nuxt) o multiframework (Astro) |
| Óptimo para web puramente estática | Bueno | Astro es más ligero |
Preguntas frecuentes
¿Por qué Next.js y no React a secas (Vite)?
React con Vite solo renderiza en el cliente, así que el HTML inicial llega vacío: malo para SEO y GEO. Next.js añade SSR y SSG y entrega el HTML completo desde la primera respuesta del servidor.
¿Next.js es bueno para el SEO?
Sí. SSR/SSG entregan HTML indexable, con los metadatos y el JSON-LD generados en el servidor, en la misma respuesta.
¿Puedo migrar una web existente a Next.js?
Sí, de forma incremental: las páginas se trasladan una a una manteniendo las URL y las redirecciones 301 para no perder posiciones en Google.
¿Qué hosting necesita Next.js?
Las páginas estáticas funcionan en cualquier CDN. Las funciones dinámicas (SSR, rutas de API) necesitan Node.js o un runtime serverless como Vercel, Netlify o un contenedor Docker.