Modos de renderizado en Next.js
Feb 21, 2022
Updated: Jun 24, 2026

Modos de renderizado en Next.js

Una de las grandes fortalezas de Next.js es que puede renderizar cada parte de tu aplicación con la estrategia más adecuada. Como vimos en el post anterior, Obteniendo datos con Next.js, la forma en que obtienes los datos determina cómo se pre renderiza, renderiza y visualiza cada página. Estas son las estrategias principales:

  • Generación Estática (Static Generation: SSG)
  • Renderizado del lado del servidor (Server Side Rendering: SSR)
  • Renderizado del lado del cliente (Client Side Rendering: CSR)

Vigente en Next.js 16: Estos tres conceptos siguen siendo válidos como modelos mentales, pero la forma de elegirlos cambió. En el App Router (lo recomendado desde Next.js 13) ya no usas funciones a nivel de página como getStaticProps o getServerSideProps: el renderizado lo gobiernan los Server Components, la caché de `fetch` y la configuración de segmento de ruta. Más abajo mapeo cada concepto clásico a su equivalente moderno.

Generación Estática (SSG)

Son las páginas que se generan completamente en HTML en tiempo de compilación y son muy fáciles de cachear y servir desde una CDN. Ideales para contenido que no cambia en cada petición (landing pages, posts de un blog, documentación).

  • App Router (hoy): un Server Component async que hace fetch con caché (el comportamiento por defecto) se prerenderiza estáticamente. Para rutas dinámicas, usas generateStaticParams para indicar qué rutas generar en build.
  • Pages Router (heredado): equivalía a usar getStaticProps (y getStaticPaths para rutas dinámicas).
// app/blog/[slug]/page.js — SSG en el App Router
export async function generateStaticParams() {
  const posts = await fetch('https://api.midominio.com/posts').then((r) => r.json());
  return posts.map((post) => ({ slug: post.slug }));
}

export default async function Page({ params }) {
  const { slug } = await params;
  // fetch con caché por defecto => esta página se prerenderiza en build
  const post = await fetch(`https://api.midominio.com/posts/${slug}`).then((r) => r.json());
  return <article>{post.title}</article>;
}

Renderizado del lado del servidor (SSR)

Son las páginas que no se generan por completo en build, porque necesitan datos del servidor en el momento de cada petición (por ejemplo, contenido personalizado por usuario). El HTML se construye en el servidor cuando el usuario solicita la página.

  • App Router (hoy): marcas la obtención de datos como dinámica con fetch(url, { cache: 'no-store' }), o configuras el segmento con export const dynamic = 'force-dynamic'.
  • Pages Router (heredado): equivalía a getServerSideProps. Evita getInitialProps: está desaconsejado desde Next.js 9 (desactiva la optimización estática automática) y no tiene lugar en el App Router.
// app/dashboard/page.js — SSR en el App Router
export default async function Page() {
  // 'no-store' => se ejecuta en cada petición (dinámico)
  const data = await fetch('https://api.midominio.com/me', { cache: 'no-store' }).then((r) => r.json());
  return <pre>{JSON.stringify(data, null, 2)}</pre>;
}

Renderizado del lado del cliente (CSR)

A veces el HTML inicial se sirve igual para todos, pero, una vez cargado, el componente necesita pedir datos desde el navegador (por ejemplo, datos que dependen de algo que solo existe en el cliente).

Ojo con la terminología: CSR (Client Side Rendering) es una estrategia de renderizado; SPA (Single Page Application) es una arquitectura de aplicación. No son sinónimos, aunque a menudo se mencionen juntos.

  • App Router / React 19 (hoy): lo haces en un Client Component ('use client') con el hook useEffect, el hook use(), o una librería de datos como SWR o TanStack Query.
  • Heredado: antes se hacía con componentDidMount en componentes de clase, hoy obsoleto en una base React 19.
'use client';
import { useEffect, useState } from 'react';

export default function ClientWidget() {
  const [data, setData] = useState(null);

  useEffect(() => {
    fetch('/api/widget').then((r) => r.json()).then(setData);
  }, []);

  return <div>{data ? data.value : 'Cargando...'}</div>;
}

Renderizado mixto y por defecto

Lo más habitual en el App Router es combinar estrategias dentro de una misma ruta: un Server Component que prerenderiza el contenido estático y, dentro, un Client Component que pide datos en el navegador. No tienes que elegir una sola estrategia para toda la página.

Y hay dos capacidades modernas que llevan esto más lejos:

  • Streaming + `<Suspense>`: Next.js puede enviar primero la parte lista de la página y transmitir el resto a medida que se resuelve, mostrando estados de carga sin bloquear todo.
  • PPR (Partial Prerendering): combina en una misma ruta un shell estático prerenderizado con "huecos" dinámicos que se rellenan en la petición, lo mejor de SSG y SSR a la vez.

Conclusión

Espero que este post te sea de utilidad y lo puedas aplicar a algún proyecto que tengas en mente, o que simplemente te haya ayudado a entender los mecanismos que ofrece Next.js para renderizar páginas, ahora desde la óptica del App Router.

Ejercicios para practicar

  1. Crea una aplicación en Next.js 16 y experimenta con cada estrategia: una página estática (SSG con fetch cacheado), una dinámica (SSR con cache: 'no-store') y un Client Component que pide datos en el navegador (CSR).
  2. Implementa una ruta que combine un Server Component (contenido estático) con un Client Component (datos del cliente).
  3. Prueba <Suspense> con streaming y compara el rendimiento y la experiencia de usuario frente a una página totalmente dinámica.

Resumen en 3 puntos

  1. SSG, SSR y CSR siguen siendo válidos como modelos mentales; lo que cambió es cómo se eligen.
  2. En el App Router el renderizado lo gobiernan los Server Components, la caché de `fetch` y la config de segmento (dynamic/revalidate), no getStaticProps/getServerSideProps (eso es Pages Router, heredado), y nunca getInitialProps.
  3. Puedes combinar estrategias en una misma ruta, y aprovechar streaming y PPR para servir lo estático al instante y lo dinámico bajo demanda.

Déjame un comentario si te sirvió, si quieres añadir alguna opinión o si tienes alguna duda. Y recuerda que si te gustó, también puedes compartirlo usando los links a las redes sociales aquí abajo.

Sebastian Gomez

Sebastian Gomez

Creador de contenido principalmente acerca de tecnología.

Leave a Reply

0 Comments

Advertisements

Related Posts

Categorias