Renderizado del lado del servidor
El renderizado del lado del servidor (SSR) es la estrategia de renderizado en la que el HTML de una página se ensambla por completo en el servidor en el momento de la solicitud y se envía al navegador como un documento completo. La primera respuesta ya contiene texto, enlaces y meta etiquetas, de modo que la página tiene sentido antes de que se ejecute cualquier JavaScript.
El renderizado del lado del servidor (SSR) es la estrategia de renderizado en la que el HTML de una página se ensambla por completo en el servidor en el momento de la solicitud y se envía al navegador como un documento completo. La primera respuesta ya contiene texto, enlaces y meta etiquetas, de modo que la página tiene sentido antes de que se ejecute cualquier JavaScript.
Por qué importa
Los motores de búsqueda y los crawlers de AI invierten presupuesto real en la ejecución de JavaScript. Googlebot utiliza un modelo de dos pasadas, primero un análisis inicial del HTML y luego una pasada de renderizado de JS diferida, y entregar una carcasa vacía renderizada en el cliente puede retrasar u omitir por completo la indexación. Los crawlers de AI como GPTBot, PerplexityBot y ClaudeBot en su mayoría no ejecutan JS en absoluto, lo que significa que el CSR es prácticamente invisible para los motores de respuesta. El SSR soluciona esto de un solo movimiento, al tiempo que mejora los Core Web Vitals; es una de las decisiones técnicas de mayor impacto para el SEO y el GEO.
CSR frente a SSR frente a SSG frente a ISR
| Estrategia | Ubicación del renderizado | Primer HTML | Idoneidad para SEO | Caso de uso |
|---|---|---|---|---|
| CSR (Client-Side Rendering) | Navegador | Carcasa vacía | Débil | Paneles con sesión iniciada |
| SSR (Server-Side Rendering) | Servidor, en cada solicitud | Completo | Fuerte | Contenido dinámico y personalizado |
| SSG (Static Site Generation) | En tiempo de compilación | Completo | El más fuerte | Blogs, documentación, marketing |
| ISR (Incremental Static Regeneration) | Compilación + regeneración periódica | Completo | El más fuerte | Páginas estáticas que se actualizan con frecuencia |
La prioridad para el SEO es aproximadamente SSG ≈ ISR > SSR > CSR. Frameworks como Next.js, Nuxt, Remix y SvelteKit permiten combinar estos modos en una sola base de código.
Implicaciones para el SEO y el GEO
Indexación inmediata: el contenido es visible en la primera pasada de Googlebot, sin esperar a la pasada de renderizado diferida. La indexación de páginas nuevas pasa de días a horas.
Compatibilidad con crawlers de AI: GPTBot y similares no ejecutan JS. Sin SSR, tu contenido prácticamente no existe para el entrenamiento ni la búsqueda de los LLM.
Mejora de los Core Web Vitals: el LCP se dispara cuando llega el primer HTML, no después de que un paquete de JS se descargue y se ejecute. FCP, LCP y TTI mejoran todos.
Meta etiquetas fiables: Open Graph, los fragmentos de búsqueda y los datos estructurados deben estar en la primera respuesta para que se confíe en ellos. El CSR envía meta etiquetas vacías a Twitter, Facebook y otros bots sociales.
Mejora progresiva: el contenido es accesible incluso con JS deshabilitado, en redes lentas o en dispositivos antiguos.
Compensaciones del SSR
Mayor costo de servidor: la generación de HTML por solicitud consume CPU, memoria e infraestructura. La caché de CDN y el ISR lo mitigan.
Posible aumento del TTFB: una lógica de servidor pesada retrasa el tiempo hasta el primer byte. Las consultas a la base de datos y las API externas se convierten en cuellos de botella.
Complejidad: las discrepancias de hidratación, las diferencias entre los entornos de servidor y cliente, y la invalidación de la caché añaden costo de depuración.
Límites de personalización: el SSR por usuario es difícil de almacenar en caché. El patrón es una carcasa compartida + personalización del lado del cliente.
La hidratación y sus trampas
Después de que el SSR entrega el HTML, el cliente lo "hidrata" volviendo a adjuntar JavaScript para hacerlo interactivo. Lo que puede salir mal:
Discrepancia de hidratación: cuando el HTML renderizado en el servidor y el primer renderizado del cliente divergen, React/Vue lanza advertencias, a menudo un parpadeo visible o un comportamiento defectuoso.
Costo de hidratación: hidratar una página grande bloquea el hilo principal y perjudica el INP. La hidratación parcial, los React Server Components y las islas de Astro son alternativas.
SSR ≠ paquetes más pequeños: el SSR no reduce el paquete del cliente. Ambos siguen necesitando optimización.
Cuándo usar SSR
- El contenido depende del tráfico de SEO/GEO (blogs, noticias, comercio electrónico, documentación)
- Los datos específicos del usuario deben estar en el primer pintado (paneles personalizados)
- Las etiquetas OG dinámicas importan para compartir en redes sociales
- Estás buscando citas en la búsqueda con AI
Cuándo el SSR es excesivo
- Paneles autenticados (sin preocupación por el SEO)
- Contenido estático: el SSG es más rápido y económico
- Sitios diminutos: un único archivo HTML estático es suficiente
Errores comunes
Aplicar SSR a todo: el contenido estático es más rápido y económico como SSG/ISR. Elige el modo adecuado para cada ruta.
Consultar API sin caché: las obtenciones de datos por solicitud sin caché disparan el TTFB. Usa SWR o encabezados de caché.
Ignorar las discrepancias de hidratación: las advertencias de la consola indican que el HTML que vio Google difiere del HTML del usuario, un riesgo para el SEO.
Establecer meta etiquetas solo en el cliente: las meta etiquetas deben existir en el head de la respuesta SSR para que los bots las lean.
Confiar en los valores predeterminados del framework: Next.js y Nuxt no siempre eligen el modo correcto automáticamente. Establécelo de forma explícita por cada ruta.
Sources: