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.

×