Qué cambia con SSR
SSR traslada la generación del marcado inicial al servidor. El navegador recibe el HTML y, después, JavaScript puede hidratar los componentes interactivos. SSR no equivale a generación estática, caché, un TTFB rápido ni a una indexación correcta.
La prueba es el cuerpo y el estado de la respuesta de una URL real, no un ajuste del framework.
Comprueba la respuesta
Inspecciona el HTML inicial con JavaScript desactivado o con una petición sin procesar (raw fetch). Comprueba el estado, la etiqueta canonical, el texto principal y el comportamiento ante errores antes de la hidratación.
- Descarga el HTML inicial.
- Prueba una ruta que no exista.
- Compara el contenido renderizado con el contenido sin procesar.
- Mide el TTFB por separado.
- Prueba las variantes de caché.
Elige el tipo de renderizado
Usa SSR cuando haga falta obtener datos en el momento de la petición o personalizar contenido, y el origen pueda responder de forma fiable. Para páginas públicas y estables puede encajar mejor una salida estática o en caché.
| Pregunta | Comprobación | Límite |
|---|---|---|
| Contenido inicial | Presente en el HTML de la respuesta | El HTML por sí solo no garantiza la calidad |
| Ruta de error | Estado 404/410/500 correcto | La interfaz del cliente puede ocultar el estado |
| Rendimiento | TTFB y recursos por separado | Una sola puntuación oculta las capas |
Límites de SSR
Una página renderizada en el servidor también puede ser lenta, devolver un error u ocultar contenido tras llamadas posteriores del cliente.