Introducción: El Fin de la Era "Loading..."
Si eres desarrollador web desde hace más de una década, recordarás la promesa de las Single Page Applications (SPAs) allá por 2015. Nos prometieron interfaces fluidas como aplicaciones nativas. Pero el precio que pagamos fue alto: enviamos megabytes de JavaScript al navegador del usuario, destruimos el SEO y obligamos a los móviles de gama baja a procesar lógica compleja que debería haber ocurrido en el servidor.
El resultado fue la Web del Spinner: pantallas en blanco, seguidas de una rueda de carga, seguidas de un salto de contenido (CLS), y finalmente, la web interactiva.
Estamos en 2026. Ese modelo está obsoleto.
Con la llegada de Next.js 16 y la madurez definitiva de React 19, el péndulo de la historia ha vuelto a su centro de gravedad natural: el servidor. Pero no hemos vuelto al PHP de 2005. Hemos evolucionado hacia una arquitectura híbrida perfecta donde el servidor hace el trabajo pesado (renderizado, acceso a bases de datos, seguridad) y el cliente solo se encarga de lo que mejor sabe hacer: la interactividad inmediata.
Esta guía no es un tutorial de «Hola Mundo». Es una disección de la arquitectura que impulsa la web moderna. Vamos a entender por qué Vercel y el equipo de React reescribieron las reglas del juego con los React Server Components (RSC), por qué el App Router es la única forma sensata de construir aplicaciones escalables hoy en día, y cómo Partial Prerendering (PPR) ha eliminado el debate entre estático y dinámico.
Bienvenido al desarrollo web en 2026.
Capítulo 1: React Server Components (RSC): El Cambio de Paradigma
Para entender Next.js 16, primero debes desaprender lo que creías saber sobre React. Durante años, pensamos en React como una librería del cliente («Client-Side Library»). Componentes, estado (useState), efectos (useEffect)… todo vivía en el navegador.
El Server-Side Rendering (SSR) tradicional (Next.js antiguo) era solo un parche: generaba el HTML inicial en el servidor para que Google lo viera, pero luego enviaba todo el JavaScript al navegador para «hidratar» la página. Era una duplicación de trabajo.
Los React Server Components (RSC) son diferentes. Son componentes que se ejecutan exclusivamente en el servidor y nunca se envían al cliente.
1.1 ¿Qué son realmente? (El Modelo Mental 2026)
Imagina tu aplicación como un árbol.
-
El Tronco y las Ramas (Server Components): Son la estructura estática. El Layout, la barra de navegación, el pie de página, la lista de artículos del blog. Estos componentes acceden a la base de datos, leen archivos, renderizan el HTML y mueren en el servidor. Al navegador solo llega el resultado (HTML/JSON serializado). Cero JavaScript.
-
Las Hojas (Client Components): Son las partes interactivas. El botón de «Me gusta», el carrusel de imágenes, el formulario de búsqueda. Solo estos pequeños fragmentos necesitan enviarse al navegador e hidratarse.
(Insertar Imagen 2: El Árbol de Componentes)
Esto invierte la carga de la prueba. En Next.js 16, todos los componentes son Server Components por defecto. Tú tienes que optar explícitamente por enviar algo al cliente.
1.2 La Separación: "use client" vs. Default
La directiva "use client" no significa «esto solo corre en el cliente». Significa «esto es un límite entre el servidor y el cliente».
Ejemplo de Arquitectura 2026:
// app/blog/[slug]/page.tsx (Server Component por defecto)
import { db } from ‘@/lib/db’;
import LikeButton from ‘./LikeButton’; // Client Component
export default async function BlogPost({ params }) {
// 1. Acceso directo a BD (¡Sin API routes!)
const post = await db.posts.findUnique({
where: { slug: params.slug }
});
return (
<article>
<h1>{post.title}</h1>
<div dangerouslySetInnerHTML={{ __html: post.content }} />
{/* 2. Inyectamos interactividad solo donde hace falta */}
<LikeButton postId={post.id} initialLikes={post.likes} />
</article>
);
}
// app/blog/[slug]/LikeButton.tsx
‘use client’; // 3. Marcamos el límite
import { useState } from ‘react’;
import { likePost } from ‘@/app/actions’; // Server Action
export default function LikeButton({ postId, initialLikes }) {
const [likes, setLikes] = useState(initialLikes);
return (
<button onClick={async () => {
const newLikes = await likePost(postId); // Llamada RPC invisible
setLikes(newLikes);
}}>
♥ {likes}
</button>
);
}
En este ejemplo, la lógica pesada (renderizar el contenido del blog, conectar a la BD) se queda en el servidor. El navegador solo descarga el código del botón pequeño.
1.3 El Beneficio Invisible: Zero-Bundle-Size
El impacto en rendimiento es brutal. Supongamos que usas una librería pesada para formatear fechas (date-fns) o para renderizar Markdown (remark, rehype).
-
Antes (Next.js 12): Esa librería se empaquetaba y se enviaba al usuario. Si la librería pesaba 50KB, tu web pesaba 50KB más.
-
Ahora (Next.js 16): Si usas la librería en un Server Component, se ejecuta en el servidor, genera el HTML y se queda allí. Coste para el usuario: 0 KB.
Esto permite usar librerías potentes sin miedo a degradar las Core Web Vitals.
Capítulo 2: El App Router en Next.js 16: La Arquitectura Estándar
El sistema de enrutamiento basado en archivos (pages/) sirvió bien durante años, pero tenía limitaciones fundamentales para layouts anidados y streaming. El App Router (app/) es la respuesta arquitectónica a esas limitaciones.
2.1 Adiós pages/, hola app/
El App Router no es solo un cambio de nombre de carpeta; es un cambio de mentalidad.
-
Pages Router: La ruta
/blog/slugmapeaba a un solo archivopages/blog/[slug].js. Si querías un layout persistente (ej. una barra lateral que no se recarga al navegar), tenías que hacer malabares en_app.js. -
App Router: La ruta
/dashboard/settingsmapea a una estructura de carpetas anidadas.
app/
├── layout.tsx # Root Layout (HTML, Body)
├── page.tsx # Home Page (/)
└── dashboard/
├── layout.tsx # Dashboard Layout (Sidebar persistente)
├── page.tsx # Dashboard Home (/dashboard)
└── settings/
└── page.tsx # Settings Page (/dashboard/settings)
2.2 Layouts, Templates y la Persistencia de Estado
La magia reside en layout.tsx. Un layout envuelve a todas las páginas (y sub-layouts) dentro de su carpeta. Cuando navegas de /dashboard a /dashboard/settings:
-
Next.js mantiene el
dashboard/layout.tsx(la barra lateral). No la vuelve a renderizar. -
Si tenías un estado en la barra lateral (ej. un menú desplegado o un input de búsqueda con texto), se preserva.
-
Solo se reemplaza el contenido de la
page.tsx.
Esto crea una sensación de «Aplicación Nativa» (SPA) pero con la eficiencia del servidor.
2.3 Archivos Especiales 2026
Next.js 16 estandariza el manejo de estados de UI mediante archivos reservados. Ya no necesitas if (isLoading) return <Spinner /> dentro de tu componente.
-
page.tsx: La UI principal de la ruta. -
loading.tsx: Una interfaz de carga instantánea (Skeleton) que se muestra inmediatamente mientraspage.tsxcarga sus datos asíncronos. Se basa en React Suspense. -
error.tsx: Un «Error Boundary» que captura fallos en esa ruta y muestra una UI de error sin romper toda la aplicación. -
not-found.tsx: UI específica para errores 404 dentro de esa sección. -
default.tsx: (Avanzado) Para Parallel Routes, define qué mostrar si no hay coincidencia.
Esta estructura hace que la gestión de errores y estados de carga sea declarativa y automática.
Capítulo 3: Data Fetching: Olvida useEffect para siempre
Aquí es donde los desarrolladores de React tradicionales sufren un cortocircuito (y luego se enamoran). En 2026, la regla de oro es: «Si puedes obtener los datos en el servidor, hazlo en el servidor».
3.1 async/await en Componentes
En React tradicional (cliente), un componente no podía ser asíncrono. Tenías que usar el patrón «Fetch-on-Render»:
-
Renderizar componente vacío.
-
Disparar
useEffect. -
Hacer
fetch. -
Actualizar estado.
-
Re-renderizar con datos. Esto causaba «Waterfalls» (cascadas) de red y saltos de contenido.
En Next.js 16 (RSC), tu componente es simplemente una función asíncrona (async function).
// app/products/page.tsx
async function getProducts() {
const res = await fetch(‘https://api.example.com/products’);
return res.json();
}
export default async function ProductsPage() {
// El servidor PAUSA aquí, obtiene los datos, y luego continúa.
const products = await getProducts();
return (
<ul>
{products.map((p) => (
<li key={p.id}>{p.name}</li>
))}
</ul>
);
}
Es tan simple como PHP, pero con la potencia de componentes de React. Los datos están disponibles antes de que empiece el renderizado.
3.2 Fetch API Extendida: Caching y Revalidación
Next.js 16 extiende la API nativa fetch del navegador para darle superpoderes de caché. Ya no necesitas librerías complejas como React Query o SWR para el servidor (aunque siguen siendo útiles en el cliente).
-
Caché por defecto:
fetch('...', { cache: 'force-cache' }). Next.js guarda el resultado en el sistema de archivos. Si otro usuario pide la misma página, se sirve instantáneamente desde la caché. -
Revalidación (ISR):
fetch('...', { next: { revalidate: 3600 } }). «Mantén estos datos frescos por 1 hora. Luego, vuelve a pedirlos en segundo plano». -
On-Demand Revalidation: Puedes purgar la caché cuando quieras mediante Server Actions (
revalidatePath('/products')). Si actualizas un precio en tu CMS, la web se actualiza al instante.
3.3 Streaming y Suspense: Rompiendo la Cascada
«Pero espera», dirás, «si uso await en el servidor, ¿el usuario tiene que esperar a que la base de datos responda para ver algo?». Ahí es donde entra el Streaming.
Si envuelves una parte lenta de tu UI en <Suspense>, Next.js envía el resto de la página inmediatamente.
export default function Page() {
return (
<section>
<h1>Mis Productos</h1>
{/* Esto se muestra INMEDIATAMENTE */}
<Suspense fallback={<ProductSkeleton />}>
{/* Esto carga en segundo plano y se «inyecta» cuando está listo */}
<ProductList />
</Suspense>
</section>
);
}
En Next.js 16, el servidor mantiene una conexión abierta HTTP. Envía el HTML inicial (el título, el layout) y un «placeholder» donde va la lista de productos. Cuando la base de datos responde, Next.js envía el HTML de los productos por el mismo flujo y React lo inserta en el hueco correcto. Resultado: Time to First Byte (TTFB) casi instantáneo, incluso para páginas dinámicas pesadas.
Capítulo 4: Server Actions: Mutaciones sin API Routes
En la era de las Single Page Applications (2015-2023), enviar un formulario era un calvario de «Glue Code» (código pegamento):
-
Crear un componente de formulario.
-
Crear un estado
useStatepara cada campo. -
Crear una función
onSubmit. -
Hacer un
fetch('/api/submit'). -
Crear el archivo API Route (
pages/api/submit.ts). -
Validar los datos en el backend.
-
Guardar en BD.
-
Devolver JSON.
-
Manejar el error en el frontend.
En Next.js 16, todo esto se ha condensado. Las Server Actions son funciones asíncronas que se ejecutan en el servidor, pero que puedes llamar desde tus componentes (Cliente o Servidor) como si fueran funciones locales.
4.1 Qué son las Server Actions ("use server")
Son funciones marcadas con la directiva 'use server'. Next.js crea automáticamente un endpoint HTTP seguro (POST) detrás de escena, serializa los argumentos y maneja la respuesta.
Ejemplo 2026: Un formulario de Newsletter
// app/actions.ts
‘use server’;
import { db } from ‘@/lib/db’;
import { z } from ‘zod’; // Validación
import { revalidatePath } from ‘next/cache’;
const schema = z.object({
email: z.string().email(),
});
export async function subscribe(prevState: any, formData: FormData) {
// 1. Validación en el Servidor (¡Crucial!)
const validatedFields = schema.safeParse({
email: formData.get(‘email’),
});
if (!validatedFields.success) {
return { error: ‘Email inválido’ };
}
// 2. Mutación directa a BD
try {
await db.subscribers.create({
data: { email: validatedFields.data.email },
});
// 3. Revalidación de Caché (Actualiza la UI al instante)
revalidatePath(‘/’);
return { success: true };
} catch (e) {
return { error: ‘Error al guardar’ };
}
}
// app/newsletter.tsx
‘use client’;
import { useActionState } from ‘react’; // Hook nuevo en React 19/Next 16
import { subscribe } from ‘./actions’;
export default function Newsletter() {
const [state, formAction] = useActionState(subscribe, null);
return (
<form action={formAction}>
<input name=»email» type=»email» required />
<button type=»submit»>Suscribirse</button>
{state?.error && <p className=»text-red-500″>{state.error}</p>}
{state?.success && <p className=»text-green-500″>¡Gracias!</p>}
</form>
);
}
4.2 Formularios Progresivos
La magia de este código es que funciona incluso si JavaScript está desactivado en el navegador. Como es un <form action={...}> estándar de HTML, el navegador envía la petición POST nativa. Next.js la intercepta en el servidor, ejecuta la acción y devuelve la página actualizada. Cuando el JS carga (Hidratación), React toma el control y lo hace sin recargar la página (Soft Navigation).
Es la robustez de la web antigua (PHP) con la experiencia de usuario moderna.
4.3 Seguridad: No te confíes
Aunque parece magia, es un endpoint público.
-
Autenticación: Siempre verifica la sesión dentro de la Server Action (
const session = await auth()). -
Autorización: Verifica si el usuario tiene permisos (
if (session.user.role !== 'admin') throw new Error()). -
Validación: Nunca confíes en el input. Usa Zod o Valibot. Next.js encripta los closures, pero los datos viajan por la red.
Capítulo 5: Partial Prerendering (PPR): El Santo Grial del Rendimiento
Durante años, tuvimos que elegir:
-
Estático (SSG): Rápido, barato, pero contenido viejo. (Ej: Blog).
-
Dinámico (SSR): Contenido fresco, pero lento (TTFB alto) y caro. (Ej: E-commerce).
En Next.js 16, Partial Prerendering (PPR) elimina esta dicotomía. Es la característica que define el 2026.
5.1 ¿Estático o Dinámico? Ambos a la vez.
Con PPR, una sola ruta puede ser estática y dinámica simultáneamente. Next.js pre-renderiza una «Cáscara Estática» (Static Shell) en tiempo de construcción. Esta cáscara incluye el Layout, el Header, el Footer y cualquier componente que no dependa de datos específicos del usuario (cookies, headers).
Esta cáscara se sirve desde el Edge (CDN) instantáneamente (10-50ms).
Dentro de esa cáscara, hay «agujeros» (Holes) donde va el contenido dinámico (Ej: «Hola, Juan», «Tu carrito tiene 3 items»). Estos agujeros se llenan mediante Streaming en paralelo desde el servidor.
5.2 Cómo funciona: Suspense como Frontera
Tú no tienes que configurar nada complejo. El límite lo define .
// app/page.tsx
import { Suspense } from ‘react’;
import UserProfile from ‘./UserProfile’;
import StaticNews from ‘./StaticNews’;
export const experimental_ppr = true; // Activo en Next.js 16
export default function Home() {
return (
<main>
<h1>Bienvenido a Mi Tienda</h1> {/* ESTÁTICO (CDN) */}
<StaticNews /> {/* ESTÁTICO (CDN) */}
<Suspense fallback={<Spinner />}>
{/* DINÁMICO (Streaming desde Servidor) */}
{/* El navegador recibe el HTML estático YA, y luego inyecta esto */}
<UserProfile />
</Suspense>
</main>
);
}
5.3 Despliegue en el Edge
Cuando despliegas esto (en Vercel, AWS o Docker optimizado), el servidor no tiene que «pensar» para enviar el primer byte. Envía el HTML estático pre-calculado. El usuario ve la web al instante. Luego, el servidor procesa solo la parte personalizada. Resultado: Core Web Vitals (LCP/FCP) perfectos, experiencia personalizada.
Capítulo 6: Integración con IA (Vercel AI SDK)
En 2026, la IA no es un «añadido»; es parte del stack. Next.js 16 integra el Vercel AI SDK (versión 4.0+) para hacer que la IA sea reactiva.
6.1 Generative UI: Componentes, no solo Texto
Hasta 2024, los chatbots solo devolvían texto o markdown. Con Next.js 16 y RSC, el servidor puede devolver Componentes de React como respuesta de un LLM.
-
Usuario: «¿Qué tiempo hace en Madrid?»
-
LLM (Servidor): Detecta la intención «weather». Llama a una API de tiempo. Decide renderizar el componente
<WeatherCard city="Madrid" temp={22} />. -
Cliente: Recibe el componente renderizado, interactivo y bonito. No texto plano.
6.2 Streaming de LLMs
El SDK permite hacer streaming de la respuesta del LLM (token a token) directamente a un componente RSC.
import { streamText } from ‘ai’;
import { openai } from ‘@ai-sdk/openai’;
export async function POST(req: Request) {
const { messages } = await req.json();
const result = await streamText({
model: openai(‘gpt-5’),
messages,
});
return result.toDataStreamResponse();
}
Esto se conecta con el hook useChat en el cliente para una experiencia tipo ChatGPT instantánea.
Capítulo 7: Turbopack y el Entorno de Desarrollo
El mayor dolor de los desarrolladores de Next.js en 2022 era la velocidad. Iniciar el servidor de desarrollo (npm run dev) en un proyecto grande podía tardar minutos.
7.1 El Fin de Webpack
Turbopack, escrito en Rust, es el sucesor de Webpack. En Next.js 16, ya es estable (Stable) y es el motor por defecto.
-
Arranque: 700% más rápido que Webpack.
-
HMR (Hot Module Replacement): Actualizaciones instantáneas al guardar un archivo, sin importar si tu proyecto tiene 100 o 10.000 páginas.
-
Producción: Ahora Turbopack también se usa para
next build, reduciendo los tiempos de CI/CD a la mitad.
Capítulo 8: Migración y Mejores Prácticas en 2026
¿Cómo sobrevives a este cambio de paradigma sin volverte loco?
8.1 La Regla del Dedo Gordo: Cliente vs Servidor
No intentes hacerlo todo en el servidor.
-
Usa Server Components para: Obtener datos (Fetch), acceder al Backend, mantener secretos (API Keys), renderizar HTML estático.
-
Usa Client Components para:
onClick,onChange,useState,useEffect,useRef, animaciones del navegador, localStorage.
Patrón «Leaf» (Hoja): Intenta que tus Client Components sean las «hojas» del árbol, lo más abajo posible. No hagas que el Layout sea cliente si puedes evitarlo. Pasa Server Components como children a Client Components.
// ✅ BIEN: El ClientComponent recibe el ServerComponent ya renderizado
<ClientWrapper>
<ServerComponent />
</ClientWrapper>
8.2 Gestión de Estado: URL State
En las SPAs antiguas, usábamos Redux o Context para todo. En Next.js 16, la URL es la fuente de la verdad.
-
¿Tienes un filtro de búsqueda? No uses
useState. UsasearchParams(?q=zapatos). -
Esto permite que el servidor lea el estado (para renderizar los resultados iniciales) y que la URL sea compartible.
-
Para estado global de cliente (ej: un reproductor de música persistente), Zustand sigue siendo la recomendación ligera sobre Redux.
Conclusión: La Web Vuelve a sus Raíces
Hemos completado el círculo. La web empezó en el servidor (HTML estático). Luego se movió al cliente (SPA, React, Angular) buscando interactividad, pero sacrificando rendimiento. Con Next.js 16, hemos vuelto al servidor, pero trayendo con nosotros la interactividad de React.
Los React Server Components no son una «feature» más; son la arquitectura definitiva para la próxima década. Nos permiten construir aplicaciones que cargan instantáneamente (gracias a PPR y Streaming), que son amigables con los motores de búsqueda (SEO nativo), y que ofrecen una experiencia de usuario rica y fluida.
Ya no tienes que elegir entre una web rápida y una web dinámica. En 2026, puedes tenerlo todo.
La pregunta ahora no es si deberías usar Server Components, sino: ¿cuánto código puedes borrar hoy migrando a ellos?
💬 Preguntas y Respuestas (FAQ)
1. ¿Cuál es la diferencia real entre React Server Components (RSC) y el SSR tradicional (Server-Side Rendering)?
1. ¿Cuál es la diferencia real entre React Server Components (RSC) y el SSR tradicional (Server-Side Rendering)?
Esta es la confusión #1. El SSR tradicional (Next.js antiguo) generaba HTML en el servidor, pero aún así enviaba todo el JavaScript al cliente para «hidratar» la página. La página se volvía interactiva solo cuando cargaba el JS. Los RSC (Next.js 16) se ejecutan exclusivamente en el servidor y no envían su código JavaScript al navegador. Envían el resultado renderizado (un formato JSON especial serializado que React entiende). Esto reduce drásticamente el tamaño del bundle, ya que las librerías pesadas (ej: formateadores de fecha, markdown) se quedan en el servidor.
2. ¿Significa esto que ya no puedo usar hooks como useState o useEffect?
2. ¿Significa esto que ya no puedo usar hooks como useState o useEffect?
No puedes usarlos en los Server Components, que son el defecto en Next.js 16. Pero sí puedes (y debes) usarlos en los Client Components. Simplemente añades la directiva "use client" al principio del archivo. Esto le dice a Next.js: «Oye, este trocito de la UI (un botón, un carrusel) necesita interactividad, envíalo al navegador». La arquitectura moderna es un árbol donde el tronco es del servidor y las hojas interactivas son del cliente.
3. ¿Qué es el Partial Prerendering (PPR) y por qué es tan importante en Next.js 16?
3. ¿Qué es el Partial Prerendering (PPR) y por qué es tan importante en Next.js 16?
Hasta Next.js 14, tenías que elegir: o tu página era Estática (rápida, pero desactualizada) o Dinámica (lenta, pero actual). El PPR elimina esa elección. Permite que una misma página tenga un «caparazón» estático (Navbar, Footer, Layout) que se sirve instantáneamente desde el Edge (CDN), mientras que las partes dinámicas (Carrito de compra, Perfil de usuario) se «streamean» en paralelo desde el servidor. Obtienes el TTFB (Time to First Byte) de una web estática con la funcionalidad de una dinámica.
4. ¿Son seguras las Server Actions? ¿No es peligroso llamar a la base de datos desde el frontend?
4. ¿Son seguras las Server Actions? ¿No es peligroso llamar a la base de datos desde el frontend?
Parece que llamas a la BD desde el frontend, pero no es así. Las Server Actions son funciones que parecen funciones de JavaScript normales, pero que Next.js convierte automáticamente en endpoints de API seguros (POST requests) bajo el capó. Sin embargo, la seguridad no es automática. Debes validar siempre los inputs (usando librerías como Zod) y verificar la autenticación/autorización dentro de la Server Action, tal como lo harías en un controlador de API tradicional.
5. ¿Necesito hospedarme en Vercel obligatoriamente para usar Next.js 16?
5. ¿Necesito hospedarme en Vercel obligatoriamente para usar Next.js 16?
No, aunque Vercel ofrece la mejor experiencia «Zero-Config» (especialmente para PPR y Edge Functions). Next.js 16 puede desplegarse en cualquier servidor que soporte Node.js o en un contenedor Docker. Puedes usar AWS (vía SST o Amplify), Google Cloud Run, o un VPS tradicional. La única limitación puede estar en funcionalidades muy específicas del Edge que dependen de la infraestructura, pero el núcleo (App Router, RSC) funciona en todas partes (suponiendo soporte de Node.js 20+).
6. ¿Cómo manejo la autenticación (Auth) con Server Components?
6. ¿Cómo manejo la autenticación (Auth) con Server Components?
Librerías como Auth.js (antes NextAuth) o Clerk se han adaptado completamente. Ahora puedes verificar la sesión del usuario directamente en el servidor (en un Layout o Página) sin esperar a que cargue el cliente. Ejemplo: const session = await auth();. Si no hay sesión, haces un redirect('/login') instantáneo desde el servidor. Esto elimina el parpadeo de contenido protegido que ocurría en las apps antiguas hechas solo con React.
7. ¿Qué pasa con las librerías de estilos como Styled-Components o Emotion?
7. ¿Qué pasa con las librerías de estilos como Styled-Components o Emotion?
Las librerías «CSS-in-JS» que dependen de la ejecución en tiempo de ejecución (runtime) han tenido problemas con los Server Components. En 2026, el estándar es usar Tailwind CSS (que es estático) o CSS Modules. Si necesitas CSS-in-JS, librerías «Zero-Runtime» como Panda CSS o StyleX son las recomendadas, ya que son compatibles con la renderización en servidor y no bloquean el hilo principal.
8. ¿Cómo afecta Next.js 16 al SEO (Core Web Vitals)?
8. ¿Cómo afecta Next.js 16 al SEO (Core Web Vitals)?
Positivamente, de forma brutal.
-
LCP (Largest Contentful Paint): Al enviar menos JavaScript y usar Streaming, el contenido principal se pinta mucho antes.
-
CLS (Cumulative Layout Shift): El sistema de Layouts anidados y la gestión de fuentes (
next/font) eliminan los saltos de contenido. -
INP (Interaction to Next Paint): Al mover la lógica pesada al servidor, el hilo principal del navegador está libre para responder a los clics del usuario instantáneamente.
9. ¿Es difícil migrar del "Pages Router" al "App Router"?
9. ¿Es difícil migrar del "Pages Router" al "App Router"?
Es un cambio mental importante, pero la migración puede ser incremental. Next.js permite que ambos routers coexistan. Puedes mantener tu blog en pages/ mientras construyes tu nuevo dashboard en app/. No tienes que reescribir toda la aplicación de golpe. Sin embargo, para aprovechar las Server Actions y RSC, debes moverte a app/.
10. ¿Por qué Next.js cachea todo por defecto y cómo lo controlo?
10. ¿Por qué Next.js cachea todo por defecto y cómo lo controlo?
Next.js tiene una filosofía agresiva de caching para rendimiento. Cachea las peticiones de datos (fetch), las rutas renderizadas y los componentes de cliente. En Next.js 15/16, el control es más granular. Puedes usar export const dynamic = 'force-dynamic' para desactivarlo en una página, o revalidatePath() y revalidateTag() en tus Server Actions para limpiar la caché bajo demanda (ej: cuando actualizas un producto en el CMS, limpias solo la caché de ese producto).
