SSR, SSG, CSR qué cambia y cómo afecta a tu web
Tres formas de renderizar una web moderna: en servidor, en build o en cliente. Diferencias, impacto SEO, rendimiento y cuándo usar cada una en Next.js.
Actualizado mayo 2026
Tres formas de entregar HTML al navegador del usuario.
SSR (Server-Side Rendering): cada petición del usuario genera el HTML en el servidor en tiempo real con los datos del momento. El navegador recibe la página ya renderizada. Bueno para contenido personalizado o que cambia constantemente.
SSG (Static Site Generation): el HTML se genera una vez en el build, se sube a un CDN y se sirve estático a todos los usuarios. Velocidad máxima posible, escalabilidad infinita. Ideal para contenido que no cambia con cada usuario (blog, marketing, docs).
CSR (Client-Side Rendering): el navegador descarga un HTML mínimo + bundle JavaScript, y la página se construye en el navegador del usuario ejecutando JS. Único modelo de las SPAs tradicionales. Malo para SEO si no se hace prerender. Bueno para apps internas tipo dashboard.
En 2026, frameworks como Next.js, Astro y Nuxt permiten combinar las tres estrategias dentro del mismo proyecto: páginas de marketing en SSG, listings dinámicos en SSR, dashboard interno en CSR. La elección por página es clave para rendimiento y SEO.
SSR, SSG, CSR: cuándo usar cada uno.
SSG → mejor para marketing y blog
Homepage, landings, blog, docs, glosario. Contenido que no cambia por usuario. Velocidad máxima, SEO perfecto, coste hosting mínimo (CDN). Regeneración periódica si cambia (ISR).
SSR → mejor para personalización dinámica
Resultados de búsqueda, perfil usuario, e-commerce con stock real, dashboards públicos con datos al minuto. Compromiso entre velocidad y frescura de datos.
CSR → mejor para apps internas
Dashboard logueado, herramientas internas, editores complejos. Donde SEO no importa porque está detrás de login. Carga inicial más lenta pero navegación entre vistas instantánea.
ISR (incremental static regeneration)
Híbrido entre SSG y SSR. Páginas estáticas que se regeneran cada X minutos o cuando algo cambia. Lo mejor de ambos mundos para blogs con miles de páginas.
Streaming SSR
Variante moderna: el servidor empieza a enviar HTML mientras todavía resuelve datos lentos. Mejor TTFB percibido. Next.js 14+ y React Server Components lo hacen nativo.
Edge rendering
SSR ejecutado en edge computing cerca del usuario. Vercel Edge Functions, Cloudflare Workers. Latencia muy baja con frescura SSR.
Estrategia mixta típica en pymes B2B.
Homepage y servicios → SSG
Cambian poco. SSG garantiza Lighthouse 100, costes bajos, SEO impecable. Regeneras solo cuando publicas cambios desde el CMS.
Blog y glosario → SSG con ISR
Cientos o miles de páginas estáticas pre-renderizadas. Se regeneran cuando el editor publica nuevo contenido. Coste cuasi-cero, SEO perfecto.
Buscador interno → SSR o CSR
Resultados varían por query. SSR para SEO de resultados indexables. CSR para experiencia interactiva sin recargar página.
Área cliente → CSR
Tras login no importa SEO. CSR es lo más fluido para navegación interna, formularios complejos, gráficos interactivos.
Checkout / pago → SSR
Datos sensibles, sesión, validaciones server-side. SSR garantiza control y seguridad. Nunca confiar al cliente.
Páginas país/idioma → SSG masivo
Programmatic SEO genera cientos de variantes estáticas. SSG con ISR cubre todo sin coste por petición.
Reglas prácticas para elegir SSR, SSG o CSR.
¿La página se ve igual para todos? → SSG
Si el contenido no depende del usuario logueado ni de datos en tiempo real, SSG es la respuesta. Más rápido, más barato, mejor SEO. Default en marketing.
¿Necesita datos al minuto? → SSR
Si los datos cambian cada pocos segundos y los usuarios esperan ver lo último (stock, precios, resultados), SSR garantiza frescura sin perder SEO.
¿Está detrás de login? → CSR
Si Google no necesita indexarla, CSR da navegación más fluida y reduce carga del servidor. SPA tradicional para áreas privadas.
¿El contenido cambia 1-10 veces al día? → ISR
Blog, glosario, casos de estudio. ISR mantiene SSG con regeneración automática. Mejor de ambos mundos.
¿Latencia global crítica? → Edge SSR
Si tu pyme tiene usuarios en varios continentes y necesitas SSR fresco con baja latencia, ejecutar en edge (Vercel, Cloudflare) reduce TTFB a 50-100 ms.
SSR/SSG/CSR en el stack web pyme.
La elección de estrategia afecta directamente a Core Web Vitals y SEO técnico. SSG suele dar la mejor puntuación; CSR mal hecho puede arruinar SEO si Google no renderiza bien el JS.
Funciona en sinergia con headless CMS y arquitecturas JAMstack: SSG + headless es el patrón dominante en webs B2B modernas.
Con edge computing y CDNs modernas, hoy se puede hacer SSR con latencia comparable a SSG. La línea entre estrategias se difumina. En Magnetia diseñamos webs Next.js con estrategia mixta para pymes B2B en CRO web B2B.
Dudas que nos hacéis llegar
¿Web lenta o problemas de SEO técnico?
Auditamos tu estrategia de renderizado, optimizamos Core Web Vitals y rediseñamos arquitectura con Next.js si compensa.