React y Next.js: aplicaciones web de alto rendimiento

← Inicio
Frontend moderno

React y Next.js: aplicaciones web de alto rendimiento

Utilizamos React 18 y Next.js 15 (App Router) en toda la plataforma 4lawyers: las páginas de presentación del despacho, el calendario de expedientes, las fichas de clientes y el panel del despacho. El código está escrito en TypeScript estricto, las pruebas están automatizadas y los despliegues se hacen sin tiempo de inactividad.

Por qué elegimos Next.js para nuestros proyectos

Next.js 15 con App Router ofrece un modelo híbrido único: las páginas estáticas (SSG) se sirven al instante desde la CDN, las páginas dinámicas se ejecutan como Server Components que no envían JavaScript innecesario al navegador y las páginas en tiempo real usan Client Components aislados. El resultado es una puntuación Lighthouse de 95+ de serie, sin trucos.

Las imágenes se optimizan automáticamente con el componente `<Image>` (WebP/AVIF, srcSet adaptable, carga diferida), las fuentes se integran en el CSS crítico con `next/font` y los scripts de terceros se cargan con estrategias de prioridad. En conjunto, estas optimizaciones sitúan el LCP por debajo de 2,5 segundos en redes 4G reales.

  • Server Components para las páginas públicas del despacho: cero JS en el cliente y rastreo inmediato
  • SSR en streaming con Suspense para el calendario de expedientes y la disponibilidad en directo
  • Incremental Static Regeneration (ISR) para grandes catálogos de servicios jurídicos y artículos del blog, sin recompilar
  • Route Groups y Parallel Routes para diseños complejos sin volver a renderizar

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 de ejecución: accesos a valores indefinidos, tipos incompletos en las respuestas de las API, comparaciones incorrectas. Un proyecto típico llega a la CI con 0 errores de TypeScript antes de cualquier prueba.

Para la gestión del estado usamos Zustand (ligero y sin código repetitivo) 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). Los formularios se construyen con React Hook Form y validación de esquemas con 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: ninguna PR se rechaza por formato
  • Zod para validar en tiempo de ejecución los datos de API externas
  • Alias de rutas (`@/components/...`): importaciones limpias 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; si alguna falla, se bloquea la fusión. Cobertura mínima del 80 % en la lógica de negocio.

  • Lighthouse CI: una puntuación inferior a 90 bloquea el despliegue en staging
  • Analizador de bundles 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

  • Lighthouse 95+ desde el primer día, sin ajustes manuales.
  • SSR y SSG nativos: HTML completo para Google y los motores de IA.
  • TypeScript estricto detecta los errores al compilar, no en producción.
  • Ecosistema maduro: Vercel, miles de paquetes y una comunidad enorme.

Limitaciones

  • La curva de aprendizaje de App Router y Server Components es pronunciada.
  • Cambios incompatibles frecuentes entre versiones mayores: exige mantenimiento.
  • Para un sitio estático sencillo, Next.js puede ser excesivo frente a HTML puro.
  • Las compilaciones grandes aumentan el tiempo de compilación y el coste de la CI.

Veredicto breve

Elija React y Next.js para sitios y aplicaciones web que deban ser rápidos, indexables y escalables. Para una única landing estática sin interactividad, basta con una herramienta más sencilla.

Tabla de especificaciones

CapacidadLímite / umbralUso típico
RenderizadoSSR, SSG, ISR, CSRLos Server Components limitan las API del navegadorMarketing estático + panel dinámico
RendimientoLCP < 2,5 s, Lighthouse 95+El JS de hidratación crece con la interactividadSitios de mucho tráfico y críticos para el SEO
EscaladoDecenas de miles de usuarios, CDN en el edgeRequiere alojamiento Node o serverlessSaaS, portales, plataformas jurídicas
Coste típicoCódigo abierto, alojamiento desde ~0 €Funciones serverless facturadas por usoDe proyectos pequeños a nivel empresarial

Next.js frente a las alternativas

CriterioNext.jsNuxt / Astro / Vite
SSR + SSG en un solo frameworkSí, de forma nativaParcial (Nuxt sí, Vite no)
Ecosistema ReactCompletoVue (Nuxt) o multiframework (Astro)
Mejor opción para un sitio puramente estáticoBuenaAstro es más ligero

Preguntas frecuentes

¿Por qué Next.js y no React puro (Vite)?

React con Vite solo renderiza en el cliente, así que el HTML inicial llega vacío, lo que perjudica al SEO y al GEO. Next.js añade SSR y SSG y entrega un HTML completo que Google y los motores de IA leen de inmediato.

¿Es Next.js bueno para el SEO?

Sí. SSR/SSG entregan HTML indexable, los metadatos y el JSON-LD se generan en el servidor y las Core Web Vitals son verdes por diseño: todas ellas señales de posicionamiento de peso.

¿Puedo migrar un sitio existente a Next.js?

Sí, de forma progresiva: las páginas se migran una a una, conservando las URL y con redirecciones 301 para no perder posiciones en Google.

¿Qué alojamiento 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 entorno serverless como Vercel, Netlify o un contenedor Docker.