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
- Navegador requestea
/products/42 - Servidor fetchea datos, corre tree componentes, genera HTML
- Servidor devuelve HTML — navegador muestra inmediatamente
- Navegador descarga bundle JavaScript
- JS hidrata HTML — página se vuelve interactiva
SSR vs otras estrategias rendering
| Estrategia | HTML generado | Trade-off |
|---|---|---|
| SSR | Por request, en servidor | Fresco + SEO; necesita servidor |
| SSG (Static) | Una vez en build time | Delivery más rápida; stale |
| CSR | En navegador vía JS | UX app-like; primer paint lento |
| ISR | Build + on-demand | Performance static + frescura dinámica |
| Edge SSR | Por request en CDN edge | Latencia 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
| Pros | Cons |
|---|---|
| Primer paint rápido (LCP) | TTFB más lento que SSG |
| SEO-friendly out-of-box | Necesita servidor corriendo |
| Contenido siempre fresco | Costo hosting más alto |
| Personalización per-user | Complejidad 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.
Herramientas LoadFocus relacionadas
Lleva este concepto a la práctica con LoadFocus — la misma plataforma que potencia todo lo que acabas de leer.