Cómo funciona Next.js: Arquitectura técnica
Next.js se ubica entre React y la infraestructura de implementación, orquestando la renderización, el enrutamiento y la optimización.
La pila
Navegador de usuario
↓
Aplicación Next.js (componentes React + funciones de servidor)
↓
Tiempo de ejecución de Node.js (o tiempo de ejecución de Edge)
↓
Plataforma de alojamiento (Vercel, AWS, Netlify, etc.)
Sistema de archivos como enrutador
Next.js utiliza el sistema de archivos para definir rutas:
app/
├── page.js → / (página de inicio)
├── acerca de/
│ └── page.js → /acerca de
├── blog/
│ ├── page.js → /blog
│ └── [babosa]/
│ └── page.js → /blog/cualquier-slug-de-publicación
Cada page.js exporta un componente React que se convierte en la interfaz de usuario para esa ruta.
Componentes de servidor y cliente
Con App Router (introducido en Next.js 13), los componentes se configuran por defecto como Componentes de Servidor: se ejecutan en el servidor y envían el HTML renderizado al cliente. Nunca envían JavaScript al navegador.
Los componentes de cliente añaden interactividad. Al marcar un archivo con "usar cliente", Next.js debe ejecutarlo en el navegador.
'usar cliente'
importar { useState } desde 'react'
exportar función predeterminada Counter() {
const [count, setCount] = useState(0)
devolver <button onClick={() => setCount(count + 1)}>{count}</button>
}Los componentes del servidor obtienen datos, acceden a bases de datos y gestionan la lógica empresarial. Los componentes del cliente gestionan el estado, gestionan eventos y utilizan las API del navegador (Documentación de Next.js, 2026).
La carga útil del componente de servidor React (carga útil RSC)
Al navegar a una página con componentes de servidor, Next.js no envía HTML tradicional. Envía un formato binario compacto llamado carga útil RSC:
Salida renderizada de los componentes del servidor
Marcadores de posición para donde se representan los componentes del cliente
Propiedades pasadas del servidor a los componentes del cliente
React en el cliente usa esta carga útil para construir el DOM de manera eficiente (Documentación de Next.js, 2026).
Proceso de construcción e implementación
Desarrollo: Ejecute npm run dev. Turbopack inicia un servidor de desarrollo con recarga en caliente y actualizaciones casi instantáneas.
Compilación: Ejecute npm run build. Next.js pre-renderiza páginas estáticas, optimiza recursos y agrupa JavaScript.
Implementar: enviar a Vercel (configuración cero) o a cualquier host Node.js, contenedor Docker o host estático.
Next.js sigue el control de versiones semántico. Las versiones principales se publican aproximadamente cada 12 a 18 meses, con actualizaciones menores cada 2 a 4 semanas (Index.dev, 2026).
Estrategias de renderizado: explicación de SSR, SSG, ISR y CSR
Comprender cuándo utilizar cada estrategia de renderizado es fundamental para el rendimiento y la experiencia del usuario.
Generación de sitios estáticos (SSG)
Qué es: Las páginas se crean como HTML en tiempo de compilación. El mismo HTML se utiliza para todos los usuarios.
Ideal para:
Publicaciones de blog
Páginas de marketing
Documentación
Páginas de productos con actualizaciones poco frecuentes
Rendimiento: Tiempos de carga rapidísimos. El HTML ya existe, por lo que el tiempo hasta el primer byte (TTFB) es prácticamente nulo. Excelentes puntuaciones LCP.
Ejemplo:
// app/blog/[slug]/page.js
exportar función asíncrona generateStaticParams() {
constante posts = await obtenerPosts()
devolver publicaciones.map(publicación => ({ slug: post.slug }))
}
exportar función asíncrona predeterminada Página({params}) {
constante post = await obtenerPost(params.slug)
devolver <article>{post.content}</article>
}(Documentación de Next.js, 2026)
Representación del lado del servidor (SSR)
Qué es: Las páginas se representan en el servidor para cada solicitud. El HTML es nuevo y personalizado
Ideal para:
Paneles de usuario
Contenido autenticado
Páginas con datos que cambian con frecuencia
Análisis en tiempo real
Rendimiento: TTFB más lento que SSG (el servidor debe procesar cada solicitud), pero aún más rápido que CSR. Ideal para SEO.
Métricas típicas de aplicaciones de complejidad media:
TTFB: ~400-600 ms
FCP: ~800-1200 ms
LCP: ~1200-1800 ms
(FrontDose, 2025)
Contras: Mayor carga del servidor y ciclos de CPU por solicitud. Considere estrategias de almacenamiento en caché.
Regeneración estática incremental (ISR)
Qué es: Las páginas se crean de forma estática pero se regeneran en segundo plano después de un intervalo establecido.
Ideal para:
Páginas de productos de comercio electrónico
Sitios de noticias
Contenido que se actualiza cada hora o a diario
Rendimiento: Combina la velocidad de SSG con la actualización de SSR. El primer usuario después del intervalo ve contenido obsoleto, pero activa una reconstrucción. Los usuarios posteriores reciben contenido actualizado.
Ejemplo:
export const revalidate = 3600 // Reconstruir cada hora
export default async function Page() {
const productos = await obtenerProductos()
devolver <ProductList productos={productos} />
}En un caso práctico documentado, Best IT utilizó ISR para reducir los tiempos de reconstrucción de horas a menos de 5 minutos, a la vez que mejoraba la velocidad de carga de las páginas en un 40 % (Naturaily, 2025).
Representación del lado del cliente (CSR)
Qué es: Se envía HTML mínimo al navegador. JavaScript obtiene los datos y representa el contenido
Ideal para:
Aplicaciones altamente interactivas (paneles de control, paneles de administración)
Datos en tiempo real (chat en vivo, análisis)
Aplicaciones donde el SEO no importa (detrás del inicio de sesión)
Rendimiento: Carga inicial más lenta, pero interacciones ágiles tras la hidratación. Core Web Vitals deficientes:
FCP: ~1500-2500 ms
LCP: ~2000-3500 ms
TTI: ~2500-4000 ms
(FrontDose, 2025)
Cuándo evitarlo: Contenido público. La RSC perjudica el SEO y la experiencia del usuario en conexiones lentas
Elegir la estrategia correcta
Según una discusión de GitHub de 2025 sobre las estrategias de representación de Next.js:
Usa SSR cuando:
El SEO es importante (publicaciones de blog, páginas de productos, páginas de destino)
Necesitas datos actualizados en cada solicitud
Las páginas respetan el estado de autenticación inmediatamente (paneles personalizados)
Utilice CSR cuando:
El SEO no importa (después de iniciar sesión)
Quiere una navegación fluida entre vistas
Los datos se actualizan con frecuencia o en tiempo real (gráficos, análisis, transmisiones en vivo)
(Discusiones sobre Next.js en GitHub, 2026)
La flexibilidad para combinar estrategias por página es la característica estrella de Next.js. Tu página de inicio puede ser estática, tus páginas de producto usan ISR y tu panel de control usa SSR, todo en un mismo código.
Componentes de React Server y el enrutador de aplicaciones
¿Qué son los componentes de React Server?
Los componentes de servidor de React (RSC) son componentes que se ejecutan exclusivamente en el servidor. Estos componentes:
Nunca envíe JavaScript al navegador
Puede acceder a bases de datos y API directamente
Reducir el tamaño del paquete del lado del cliente
Mejorar el rendimiento del contenido no interactivo
Ejemplo:
// app/products/page.js (Componente de servidor por defecto)
función asíncrona getProducts() {
const db = await connectDB()
devolver db.products.find()
}
exportar función asíncrona predeterminada ProductsPage() {
const products = await getProducts() // Se ejecuta en el servidor
devolver (<div> {productos.map(p => <ProductCard clave={p.id} producto={p} />)} </div> ) }La función getProducts() nunca se envía al cliente. Las credenciales de la base de datos se mantienen seguras. El tamaño del paquete se reduce.
Según la encuesta "State of JavaScript 2024", solo alrededor del 29 % de los desarrolladores han utilizado componentes de servidor, a pesar de que más de la mitad expresa una opinión positiva sobre la tecnología. Esta brecha representa una oportunidad significativa (Netguru, 2025).
Componentes de servidor vs. componentes de cliente
Componentes del servidor:
Predeterminado en el enrutador de aplicaciones
Ejecutar en el servidor
Puede obtener datos directamente
No se pueden usar estados, efectos ni API del navegador
No enviar JavaScript
Componentes del cliente:
Marcados con 'usar cliente'
Ejecutar en el servidor (para HTML inicial) y luego hidratar en el cliente
Puede utilizar estados, efectos y controladores de eventos.
Acceder a las API del navegador
Enviar JavaScript
Práctica recomendada: Mantenga los componentes de cliente pequeños y a nivel de hoja. La mayor parte de su árbol debe ser componentes de servidor, con bordes interactivos como componentes de cliente (Nucamp, 2026).
El enrutador de aplicaciones
Introducido en Next.js 13, el enrutador de aplicaciones es un sistema de enrutamiento basado en el sistema de archivos creado específicamente para los componentes de servidor React
Conceptos clave:
Diseños: Interfaz de usuario compartida que envuelve varias páginas
Estados de carga: Límites de suspensión automáticos con loading.js
Límites de error: manejo de errores con error.js
Transmisión: Entrega progresiva de HTML
Estructura de ejemplo:
app/
├── layout.js # Diseño raíz (envuelve todas las páginas)
├── page.js # Página de inicio
├── panel/
│ ├── layout.js # Diseño del panel
│ ├── loading.js # Cargando la interfaz de usuario
│ ├── error.js # Interfaz de usuario de error
│ └── page.js # Página del panel de control
El enrutador de aplicaciones es ahora el enfoque recomendado. Según la documentación de Next.js, "El enrutador de aplicaciones es un enrutador basado en el sistema de archivos que utiliza las últimas funciones de React, como componentes de servidor, Suspense y funciones de servidor" (Documentación de Next.js, 2026).
Next.js se erige como el único marco con soporte completo listo para producción para React Server Components en 2025. Cuando Meta presentó RSC, colaboraron directamente con el equipo de Next.js para desarrollar el complemento webpack necesario (Netguru, 2025).
Puntos de referencia de rendimiento y elementos esenciales de la web
¿Qué son los Core Web Vitals?
Core Web Vitals son tres métricas que Google utiliza para medir la experiencia del usuario:
Pintura con contenido más grande (LCP): Tiempo hasta que se renderiza el elemento de contenido más grande. Objetivo: ≤2,5 segundos.
Interacción con la siguiente pintura (INP): Tiempo hasta que la página responde a la entrada del usuario (reemplazó a FID en marzo de 2024). Objetivo: ≤200 milisegundos.
Desplazamiento acumulativo de diseño (CLS): Estabilidad visual durante la carga de la página. Objetivo: ≤0,1.
Las Core Web Vitals deficientes perjudican el posicionamiento SEO. Google utiliza explícitamente estas métricas como factores de posicionamiento (NUS Technology, 2026).
Cómo Next.js mejora los Core Web Vitals
División automática de código: solo carga JavaScript necesario por página, lo que reduce el TTI y mejora el INP.
Optimización de imágenes: El componente next/image proporciona automáticamente los tamaños y formatos correctos, realiza la carga diferida de imágenes fuera de pantalla y evita el CLS reservando espacio. Esto mejora drásticamente el LCP (NUS Technology, 2026).
Optimización de fuentes: next/font incorpora CSS y elimina solicitudes de red adicionales, lo que mejora LCP y CLS (NUS Technology, 2026).
Precarga: el componente <Link> precarga páginas vinculadas en segundo plano, lo que hace que la navegación sea instantánea (NUS Technology, 2026).
SSR/SSG: el HTML pre-renderizado entrega contenido inmediatamente, mejorando FCP y LCP en comparación con CSR.
Comparación del rendimiento en el mundo real
Según un análisis de 2025 que compara SSR y CSR en Next.js, las métricas típicas de una aplicación de complejidad media muestran:
SSR:
TTFB: 400-600 ms
FCP: 800-1200 ms
LCP: 1200-1800 ms
CSR:
TTFB: 100-200 ms (HTML mínimo)
FCP: 1500-2500 ms
LCP: 2000-3500 ms
El patrón es claro: SSR proporciona contenido visual más rápido, pero CSR puede lograr una interactividad más rápida con menores recursos de servidor (FrontDose, 2025).
Mejores prácticas de optimización
Según una guía de 2025 sobre la optimización de Core Web Vitals con Next.js:
Generación estática predeterminada para la mayoría de las páginas públicas
Utilice ISR para contenido que cambia cada hora o día
Utilice SSR solo cuando necesite datos actualizados en cada solicitud
Evite la RSE para el contenido público: perjudica los Core Web Vitals
Utilice la prerenderización parcial (PPR) (introducida en Next.js 15) para mezclar contenido estático y dinámico en la misma página
(Medium, 2025)
PPR carga una carcasa estática al instante mientras las piezas dinámicas se introducen a medida que están listas. Es el punto óptimo para muchas aplicaciones
Comentarios