Las preguntas de entrevista de Next.js que más hacen las empresas en 2026, con respuestas claras y código real. App Router, Server Components, Turbopack, SSR, SSG y optimización de rendimiento. De nivel básico a senior.
Jesús Blanco
Autor
Alrededor del 71% de las ofertas de trabajo de React en 2026 piden explícitamente experiencia con Next.js. Lo que hace unos años era un diferenciador en el CV hoy es prácticamente un requisito para cualquier puesto de frontend o fullstack en empresas que toman en serio el rendimiento y el SEO.
Esto significa dos cosas. Primero, que las entrevistas de Next.js son más frecuentes que nunca. Segundo, que el nivel de las preguntas subió porque los entrevistadores ya no se conforman con saber si conoces SSR o SSG: quieren saber si entiendes App Router, Server Components, Turbopack y el nuevo modelo de caché de Next.js 15 y 16.
Esta guía cubre las preguntas reales que están haciendo las empresas ahora mismo, ordenadas por nivel. Si ya pasaste por nuestra guía de entrevistas React 2026 y la de entrevistas TypeScript, este es el paso natural siguiente.
React es una librería para construir interfaces de usuario. No toma decisiones por ti sobre routing, renderizado o estructura de proyecto.
Next.js es un framework fullstack construido sobre React que te da todo eso resuelto: routing basado en archivos, múltiples estrategias de renderizado (SSR, SSG, ISR), API routes, optimización de imágenes, fonts y scripts, y desde la versión 13 un sistema de layouts con el App Router.
La forma más clara de explicarlo en una entrevista es con una analogía: React es el motor, Next.js es el auto completo.
// React puro: tú gestionas el routing, el data fetching, todo
function App() {
return ...
}
// Next.js: el routing viene del sistema de archivos
// app/productos/page.tsx -> /productos
// app/productos/[id]/page.tsx -> /productos/123
export default function ProductosPage() {
return Productos
}
Lo que el entrevistador quiere escuchar: que entiendes la diferencia entre librería y framework, y que puedes explicar qué problema concreto resuelve Next.js sobre React puro.
Esta pregunta aparece en el 90% de las entrevistas de Next.js. La clave no es solo definir cada una sino saber cuándo usar cada estrategia.
CSR (Client Side Rendering): el HTML llega vacío y JavaScript construye la página en el navegador. Malo para SEO, lento en la carga inicial. Antes era la forma por defecto de React.
SSG (Static Site Generation): la página se genera en build time y se sirve como HTML estático desde un CDN. Extremadamente rápido. Ideal para contenido que no cambia frecuentemente: blogs, documentación, páginas de marketing.
SSR (Server Side Rendering): la página se genera en el servidor en cada request. El usuario siempre ve contenido actualizado. Más lento que SSG pero necesario para contenido personalizado o que cambia constantemente.
ISR (Incremental Static Regeneration): lo mejor de SSG y SSR combinados. La página se genera estáticamente pero se regenera en background cada cierto tiempo o bajo demanda. Ideal para e-commerce, noticias, catálogos.
// SSG: se genera en build time
export default async function BlogPost({ params }) {
const post = await getPost(params.slug) // se ejecuta en build
return {post.content}
}
// SSR: se ejecuta en cada request
export const dynamic = 'force-dynamic'
export default async function Dashboard() {
const data = await getUserData() // se ejecuta en cada visita
return {data.nombre}
}
// ISR: estático con revalidación periódica
export const revalidate = 3600 // regenera cada hora
export default async function Catalogo() {
const productos = await getProductos()
return {productos.map(p => {p.nombre})}
}
En App Router, el routing está basado en la estructura de carpetas dentro del directorio app/. Cada carpeta representa un segmento de ruta y el archivo page.tsx dentro de esa carpeta define el contenido de esa URL.
app/
page.tsx -> /
nosotros/
page.tsx -> /nosotros
blog/
page.tsx -> /blog
[slug]/
page.tsx -> /blog/mi-articulo
(marketing)/ -> grupo de rutas, no afecta la URL
landing/
page.tsx -> /landing
Los archivos especiales que necesitas conocer para una entrevista: layout.tsx define la estructura compartida entre páginas, loading.tsx el estado de carga, error.tsx el manejo de errores, y not-found.tsx la página 404.
Lo que diferencia a un candidato senior: explicar para qué sirven los Route Groups (carpetas con paréntesis), los Parallel Routes y los Intercepting Routes. Muy pocos juniors los conocen.
next/image resuelve automáticamente los problemas más comunes de rendimiento con imágenes: convierte a formatos modernos como WebP y AVIF, aplica lazy loading por defecto, redimensiona según el viewport y previene el Cumulative Layout Shift reservando el espacio antes de que cargue la imagen.
import Image from 'next/image'
// Forma correcta en Next.js
<Image
src="/foto-equipo.jpg"
alt="Equipo fencode"
width={800}
height={400}
priority // para imágenes above the fold
/>
// Lo que NO debes hacer:
// Pierdes todas las optimizaciones automáticas
Esta es la pregunta más importante del App Router y donde muchos candidatos intermedios tienen lagunas.
Por defecto en Next.js, todos los componentes son Server Components. Se renderizan en el servidor, tienen acceso directo a bases de datos y APIs sin exponer credenciales al cliente, y no incluyen JavaScript en el bundle del navegador. No pueden usar hooks de React ni eventos del DOM.
Los Client Components se marcan con la directiva 'use client' al inicio del archivo. Se renderizan en el cliente, pueden usar hooks, estado local y acceder al DOM. Pero su JavaScript sí llega al navegador.
// Server Component (por defecto, sin directiva)
// Puede acceder directamente a la base de datos
async function ListaProductos() {
const productos = await db.productos.findMany() // acceso directo, seguro
return (
{productos.map(p => (
{p.nombre}
{/* Client Component */}
))}
)
}
// Client Component
'use client'
function BotonAgregarCarrito({ id }: { id: string }) {
const [agregado, setAgregado] = useState(false)
return (
<button onClick={() => setAgregado(true)}>
{agregado ? 'En carrito' : 'Agregar'}
)
}
El patrón correcto: mantener la mayor parte del árbol de componentes como Server Components y solo marcar como Client los componentes hoja que necesitan interactividad. No al revés.
Error común en entrevistas: decir que hay que poner 'use client' en todos los componentes que hacen fetch de datos. Eso era el modelo antiguo con Pages Router. En App Router, el fetch de datos se hace en Server Components sin ninguna directiva.
Los Server Actions son funciones que se ejecutan en el servidor pero que puedes llamar directamente desde el cliente, sin necesidad de crear un API route intermedio. Se marcan con la directiva 'use server'.
Son especialmente útiles para mutaciones: crear, editar o eliminar datos desde un formulario o un evento del usuario.
// app/contacto/actions.ts
'use server'
export async function enviarFormulario(formData: FormData) {
const nombre = formData.get('nombre') as string
const email = formData.get('email') as string
await db.contactos.create({ nombre, email })
revalidatePath('/contacto') // revalida la caché de esa ruta
}
// app/contacto/page.tsx
import { enviarFormulario } from './actions'
export default function PaginaContacto() {
return (
Enviar
)
}
En Next.js 15, los Server Actions tienen endpoints con hash imprevisible y se eliminan automáticamente del bundle si no se usan, lo que mejora la seguridad considerablemente respecto a versiones anteriores.
El sistema de caché de Next.js 15 cambió significativamente respecto a versiones anteriores y es una fuente frecuente de confusión. Vale la pena entenderlo bien.
En Next.js 13 y 14, el fetch hacía caché por defecto. En Next.js 15, el comportamiento cambió: las peticiones fetch, los Route Handlers GET y la navegación del cliente ya no hacen caché por defecto.
Ahora tienes control explícito:
// Sin caché (nuevo comportamiento por defecto en Next.js 15)
const data = await fetch('https://api.ejemplo.com/datos')
// Con caché indefinida
const data = await fetch('https://api.ejemplo.com/datos', {
cache: 'force-cache'
})
// Con revalidación por tiempo
const data = await fetch('https://api.ejemplo.com/datos', {
next: { revalidate: 3600 } // revalida cada hora
})
// Con revalidación por tag (para invalidación bajo demanda)
const data = await fetch('https://api.ejemplo.com/productos', {
next: { tags: ['productos'] }
})
// En otro lugar, invalida por tag
import { revalidateTag } from 'next/cache'
revalidateTag('productos')
Lo que el entrevistador quiere ver: que conoces el cambio de comportamiento entre versiones y que entiendes cuándo usar cada estrategia de caché según el tipo de dato.
El Middleware se ejecuta antes de que se procese cualquier request, en el edge. Es ideal para lógica que necesita aplicarse a muchas rutas: autenticación, redirecciones, A/B testing, internacionalización.
// middleware.ts (en la raíz del proyecto)
import { NextResponse } from 'next/server'
import type { NextRequest } from 'next/server'
export function middleware(request: NextRequest) {
const token = request.cookies.get('token')
// Proteger rutas del dashboard
if (request.nextUrl.pathname.startsWith('/dashboard')) {
if (!token) {
return NextResponse.redirect(new URL('/login', request.url))
}
}
return NextResponse.next()
}
export const config = {
matcher: ['/dashboard/:path*', '/admin/:path*']
}
En Next.js 15, el Middleware tiene soporte estable para Node.js runtime, lo que significa que puedes usar cualquier API de Node.js dentro del middleware, no solo las APIs disponibles en el edge runtime.
Esta pregunta busca que demuestres que has trabajado en apps reales con problemas reales de rendimiento. Las respuestas genéricas no convencen.
Las optimizaciones más impactantes en la práctica son:
Reducir el JavaScript del cliente. El problema más común es tener demasiados Client Components o importar librerías pesadas en componentes que se renderizan en el cliente. Usar Server Components para todo lo que no necesita interactividad y hacer imports dinámicos para componentes pesados que no son necesarios en la carga inicial.
import dynamic from 'next/dynamic'
// El editor pesado solo se carga cuando el usuario lo necesita
const EditorTexto = dynamic(() => import('./EditorTexto'), {
loading: () => Cargando editor...,
ssr: false
})
Optimización de fuentes. Next.js descarga automáticamente las Google Fonts en el servidor y las sirve como assets propios, eliminando la petición externa que bloquea el renderizado.
import { Inter } from 'next/font/google'
const inter = Inter({ subsets: ['latin'] })
export default function RootLayout({ children }) {
return (
{children}
)
}
Partial Prerendering (PPR): introducido en Next.js 15 y mejorado en 16, permite servir un shell estático instantáneo mientras las partes dinámicas se van cargando en streaming. Es la materialización del concepto Islands Architecture directamente en el framework.
Esta pregunta evalúa que has trabajado con codebases reales en producción y que entiendes los tradeoffs de una migración. La respuesta incorrecta es "migro todo de una vez".
La estrategia correcta es incremental, ya que Next.js soporta que ambos routers coexistan en el mismo proyecto:
Primero se migran las rutas más simples y con menos dependencias. Segundo se identifican los patrones de data fetching que cambian: getServerSideProps y getStaticProps desaparecen y se reemplazan por fetch directo en Server Components. Tercero se migran los layouts compartidos aprovechando el sistema de layouts anidados del App Router. Las páginas que usan mucho estado del cliente se dejan para el final.
// Pages Router (antiguo)
export async function getServerSideProps() {
const productos = await getProductos()
return { props: { productos } }
}
export default function Catalogo({ productos }) {
return
}
// App Router (nuevo)
export default async function Catalogo() {
const productos = await getProductos() // fetch directo en el Server Component
return
}
Lo que busca el entrevistador: que entiendas que no es solo un cambio de sintaxis sino un cambio de modelo mental. La lógica de data fetching pasa del nivel de página al nivel de componente.
Partial Prerendering (PPR) es uno de los features más interesantes de Next.js 15 y 16. Permite que una misma página tenga partes completamente estáticas que se sirven al instante desde caché, mientras otras partes dinámicas se van transmitiendo en streaming conforme estén disponibles.
El caso de uso clásico es un e-commerce: la estructura de la página del producto (header, descripción, imágenes) es completamente estática. El precio personalizado, el inventario en tiempo real y las recomendaciones basadas en el historial del usuario son dinámicas.
import { Suspense } from 'react'
// Esta página usa PPR automáticamente cuando está habilitado
export default function PaginaProducto({ params }) {
return (
{/* Estático: se sirve instantáneamente */}
{/* Dinámico: hace streaming cuando está disponible */}
}>
}>
)
}
Para habilitarlo en Next.js 16:
// next.config.ts
const config = {
experimental: {
ppr: true
}
}
export default config
Turbopack es el sucesor de Webpack, escrito en Rust, que viene integrado en Next.js. Desde Next.js 15 es el bundler por defecto en desarrollo y desde Next.js 16 tiene soporte estable para builds de producción.
Las mejoras de rendimiento son reales y significativas: arranque del servidor de desarrollo hasta 10 veces más rápido en proyectos grandes, HMR que actualiza en milisegundos independientemente del tamaño del proyecto y compilación inicial de rutas hasta 45% más rápida.
En la práctica no requiere configuración para la mayoría de proyectos. Si tienes un proyecto existente que usa plugins de Webpack muy específicos, puede haber diferencias de comportamiento que vale la pena revisar antes de migrar.
# Turbopack es el default en Next.js 15+
next dev
# Si necesitas volver a Webpack por alguna razón
next dev --webpack
# Builds de producción con Turbopack (estable desde Next.js 16)
next build --turbopack
Detalle que pocos conocen y que impresiona en entrevistas: Turbopack usa un grafo unificado para todos los entornos (cliente y servidor), a diferencia de Webpack que usaba compiladores separados. Eso es parte de por qué es más rápido en proyectos con lógica compartida entre client y server.
Esta pregunta evalúa madurez como desarrollador. Los puntos que debes cubrir:
Variables de entorno: solo las variables con prefijo NEXT_PUBLIC_ se exponen al cliente. Todo lo demás permanece en el servidor.
// Seguro: solo en el servidor
const apiKey = process.env.API_SECRET_KEY
// Expuesto al cliente: úsalo solo para datos no sensibles
const publicUrl = process.env.NEXT_PUBLIC_API_URL
Server Actions para mutaciones: evita exponer endpoints de API que cualquiera pueda llamar. Los Server Actions con validación del servidor son más seguros porque la lógica de autorización vive donde debe vivir.
Vulnerabilidades de React Server Components: en diciembre de 2025 se publicaron dos CVEs críticos en el protocolo de RSC (CVE-2025-55184 y CVE-2025-55183) que afectaron a Next.js 13.x hasta 16.x. Si tu app corre en versiones anteriores a los parches de diciembre 2025, actualiza inmediatamente.
Lo que el entrevistador valora: que no solo conoces las buenas prácticas sino que estás al tanto de las vulnerabilidades recientes del ecosistema.
Más allá de las preguntas técnicas, estos son los errores conceptuales que aparecen repetidamente en entrevistas y que delatan falta de experiencia práctica con el framework:
Confundir el modelo de caché de Next.js 14 con el de Next.js 15. El cambio de "caché por defecto" a "sin caché por defecto" es un breaking change importante. Si explicas el comportamiento antiguo como si fuera el actual, el entrevistador sabe que no has trabajado con versiones recientes.
Poner 'use client' en componentes que hacen fetch de datos. En App Router, el fetch de datos va en Server Components. Agregar 'use client' a esos componentes los convierte innecesariamente en Client Components y expone lógica que debería estar en el servidor.
No conocer la diferencia entre revalidatePath y revalidateTag. Las dos invalidan caché, pero revalidateTag es más precisa y eficiente para invalidación selectiva. No conocer la distinción sugiere poca experiencia con ISR avanzado.
Decir que Middleware se usa para lógica de negocio compleja. Middleware corre en el edge antes de cada request. Usarlo para lógica pesada introduce latencia en cada visita. Su uso correcto es para operaciones ligeras: redirecciones, verificación de tokens, A/B testing.
No mencionar Turbopack cuando preguntan sobre rendimiento del workflow. Desde Next.js 15, Turbopack es el default. No saber que existe o no entender qué mejora sugiere que no has trabajado con versiones actuales del framework.
Resolvemos las dudas específicas sobre este tema.
