Rendering

• Cuando usás Next.js 15+ con App Router, algo clave es decidir dónde llamar a los endpoints:

¿Lo hacemos en el servidor (SSR, RSC, SSG, ISR)?
¿O lo hacemos en el cliente (CSR con useEffect)?

La elección impacta en el SEO, el rendimiento y hasta en la seguridad. Veamos todo con ejemplos.

📝 Nota: cuando hablamos de SEO, no solo nos referimos a Google, sino también a otros motores como Bing, DuckDuckGo, Yahoo, etc. Todos ellos dependen del contenido renderizado para indexar correctamente las páginas.

🧠 Modos de renderizado en Next.js

Next.js ofrece varios modos de renderizado para adaptarse a diferentes necesidades. A continuación, un resumen con definiciones y enlaces a la documentación oficial:

• SSR (Server Side Rendering): El contenido se genera en el servidor en cada request. Ideal para SEO y contenido dinámico.
  👉 Ver doc oficial
• RSC (React Server Components): Renderiza componentes en el servidor, enviando solo el resultado al cliente. Muy útil para mantener lógica del lado del servidor.
  👉 Ver doc oficial
• SSG (Static Site Generation): Genera páginas HTML en tiempo de build. Súper rápidas, ideales para contenido que no cambia seguido.
  👉 Ver doc oficial
• ISR (Incremental Static Regeneration): Permite regenerar páginas estáticas después del build, combinando lo mejor de SSG y SSR.
  👉 Ver doc oficial

🖥️ SSR – Server Side Rendering

El servidor hace el fetch antes de renderizar. El usuario recibe una página ya armada, lo que favorece el SEO y reduce el tiempo hasta el primer contenido.

Cuándo usar SSR:

• Sitios con datos que cambian con frecuencia.
• Contenido sensible al usuario (auth, cookies).
• SEO es prioridad.

Ejemplo:

// app/news/page.tsx
export const dynamic = "force-dynamic";
 
export default async function NewsPage() {
	const res = await fetch("https://api.sitio.com/news", {
		cache: "no-store",
	});
	const news = await res.json();
 
	return (
		<div>
			<h1>Últimas Noticias</h1>
			<ul>
				{news.map((item) => (
					<li key={item.id}>{item.title}</li>
				))}
			</ul>
		</div>
	);
}

🌐 CSR – Client Side Rendering

Los datos se obtienen en el cliente luego de montar el componente usando useEffect. El HTML inicial está vacío.

Cuándo usar CSR:

• Dashboards, contenido personalizado.
• El contenido depende del usuario logueado.
• No hay necesidad de optimización SEO.

Ejemplo:

// app/dashboard/page.tsx
"use client";
 
import { useEffect, useState } from "react";
 
export default function DashboardPage() {
	const [data, setData] = useState(null);
 
	useEffect(() => {
		fetch("/api/user/dashboard")
			.then((res) => res.json())
			.then(setData);
	}, []);
 
	if (!data) return <p>Cargando...</p>;
 
	return <h1>Hola {data.name}, este es tu dashboard</h1>;
}

🪄 SSG – Static Site Generation

El contenido se genera una sola vez en tiempo de build y se entrega como HTML desde CDN.

Cuándo usar SSG:

• Blogs, documentaciones, landings.
• Contenido que no cambia frecuentemente.
• SEO es importante, pero no es contenido dinámico.

Ejemplo:

// app/about/page.tsx
export const revalidate = false;
 
export default async function AboutPage() {
	const res = await fetch("https://api.sitio.com/about");
	const data = await res.json();
 
	return <div dangerouslySetInnerHTML={{ __html: data.html }} />;
}

🔄 ISR – Incremental Static Regeneration

Permite generar páginas como SSG pero revalidarlas automáticamente después de X segundos.

Cuándo usar ISR:

• Catálogos de productos, blogs que se actualizan a diario.
• Necesitás rendimiento + contenido actual.
• Querés evitar hacer SSR en cada request.

Ejemplo:

// app/blog/page.tsx
export const revalidate = 60;
 
export default async function BlogPage() {
	const res = await fetch("https://api.sitio.com/posts");
	const posts = await res.json();
 
	return (
		<div>
			<h1>Blog</h1>
			{posts.map((post) => (
				<article key={post.id}>
					<h2>{post.title}</h2>
					<p>{post.excerpt}</p>
				</article>
			))}
		</div>
	);
}

🔐 Seguridad y performance en llamadas a APIs

Llamada desde el servidor (SSR, SSG, ISR):

• Oculta la API Key.
• Ideal para tokens secretos, CMSs, etc.

Llamada desde el cliente (CSR):

• Se expone la API Key.
• Solo si no hay datos sensibles.

🔍 Comparativa SSR vs CSR

Supongamos una página que obtiene productos desde una API externa como Contentful.

SSR:

• fetch() se hace en el servidor.
• SEO listo, contenido visible al instante.
• Ideal para bots y usuarios reales.

CSR:

• El HTML llega vacío.
• useEffect() hace el fetch después.
• Google ve poco o nada de contenido (peor para SEO).

✅ ¿Cuándo usar cada uno?

• SSR: Contenido dinámico y con SEO.
• CSR: Contenido personalizado por usuario, sin necesidad de SEO.
• SSG: Contenido estático (blogs, landings).
• ISR: Contenido semi-estático que se actualiza cada tanto.

📊 Comparativa Final

📌 Glosario

• SEO: Search Engine Optimization.
• Tiempo inicial: Tiempo en mostrar contenido visible.
• Revalidación: Tiempo de espera hasta regenerar la página (ISR).
• CDN: Red de entrega de contenido que mejora el rendimiento.
• “Client-only”: Código que se ejecuta solo en el navegador (no en el server).