Server-Side Rendering (SSR): Definición, Pros, Cuándo Usar

SSR genera HTML en el servidor por request — primer paint rápido, SEO-friendly, dinámico. Usado por Next.js, Nuxt, Remix, SvelteKit.

¿Qué es Server-Side Rendering (SSR)?

Server-Side Rendering (SSR) es una estrategia rendering web donde el HTML se genera en el servidor para cada request y se envía al navegador listo para mostrarse. El navegador muestra contenido inmediatamente; JavaScript luego "hidrata" la página para hacerla interactiva. SSR contrasta con Client-Side Rendering (CSR).

SSR es el modo rendering por default para frameworks modernos como Next.js, Nuxt, SvelteKit y Remix.

Cómo funciona SSR

  1. Navegador requestea /products/42
  2. Servidor fetchea datos, corre tree componentes, genera HTML
  3. Servidor devuelve HTML — navegador muestra inmediatamente
  4. Navegador descarga bundle JavaScript
  5. JS hidrata HTML — página se vuelve interactiva

SSR vs otras estrategias rendering

EstrategiaHTML generadoTrade-off
SSRPor request, en servidorFresco + SEO; necesita servidor
SSG (Static)Una vez en build timeDelivery más rápida; stale
CSREn navegador vía JSUX app-like; primer paint lento
ISRBuild + on-demandPerformance static + frescura dinámica
Edge SSRPor request en CDN edgeLatencia baja global

Cuándo SSR es la elección correcta

  • Personalización per-user.
  • Contenido cambiando frecuentemente.
  • SEO-crítico con datos dinámicos.
  • Contenido geo-localizado.
  • A/B testing a nivel página.
  • Lógica auth/session pesada.

Cuándo NO usar SSR

  • Páginas marketing estáticas.
  • Dashboards logged-in sin necesidad SEO.
  • Apps muy interactivas con home page simple.

Pros y cons SSR

ProsCons
Primer paint rápido (LCP)TTFB más lento que SSG
SEO-friendly out-of-boxNecesita servidor corriendo
Contenido siempre frescoCosto hosting más alto
Personalización per-userComplejidad cache

Hidratación: el catch SSR

Después de SSR, cliente debe "hidratar". Hidratación es cara.

SSR con Next.js (App Router)

export default async function ProductPage({ params }) {
  const product = await fetchProduct(params.id);
  return <div><h1>{product.name}</h1></div>;
}

SSR con Express + React

import { renderToString } from 'react-dom/server';

app.get('/', (req, res) => {
  const html = renderToString(<App />);
  res.send(`<div id="root">${html}</div>`);
});

Mejores prácticas SSR

  • Cachear sabiamente.
  • Usar streaming SSR.
  • Data fetching server-only.
  • Cachear queries DB server-side.
  • Setear cache headers thoughtfully.
  • Watchear costo hidratación.
  • Manejar errores en servidor.
  • Monitor TTFB + LCP.

Pitfalls SSR comunes

  • Referencias window/document en código server.
  • Mismatch server-client.
  • Queries DB lentas bloqueando response.
  • Olvidar cachear.
  • Bundle bloat.
  • Memory leaks.
  • Auth en middleware.

FAQ: Server-Side Rendering

¿SSR o SSG: cuál es mejor?

Depende de la frescura del contenido.

¿Arregla SSR el SEO automáticamente?

Crawlers obtienen HTML, pero aún necesitas title/meta/structured data.

¿Es SSR más lento que CSR?

Para TTFB: SSR más lento. Para primer paint: SSR mucho más rápido.

¿Qué sobre TTFB con SSR?

Más alto que SSG. Mitigar con edge SSR.

¿Puedo mezclar SSR y CSR?

Sí.

¿Qué es React Server Components?

Componentes corren solo en servidor.

¿Es SSR caro de hostear?

Más que SSG. Serverless moderno lo hace barato a tráfico bajo.

Load testea apps SSR con LoadFocus

SSR shiftea trabajo al servidor — load testing es esencial. Regístrate en loadfocus.com/signup.

¿Qué tan rápido es tu sitio web?

Mejora su velocidad y SEO sin problemas con nuestra Prueba de Velocidad gratuita.

Prueba de velocidad de sitio web gratis

Analice la velocidad de carga de su sitio web y mejore su rendimiento con nuestro comprobador de velocidad de página gratuito.

×