Rendimiento de SSR: caché, streaming y el edge

En un sitio estático el HTML ya existe cuando llega la petición; en SSR se fabrica en ese instante, y el reloj del rendimiento arranca en el servidor. Ahora hay un tiempo nuevo que gobernar —el que tarda tu código en producir el primer byte— y sobre él se apoya todo lo demás: por rápido que sea el navegador, no puede pintar lo que aún no ha recibido. Afinar SSR es aprender a mover el trabajo en el tiempo y en el espacio: adelantarlo con caché, aplazarlo con streaming, acercarlo con el edge. La latencia deja de ser un coste fijo y se vuelve algo que se programa.

TTFB: la primera cifra del SSR

El TTFB —Time To First Byte— mide cuánto tarda el servidor en enviar el primer byte de la respuesta desde que recibe la petición. En un sitio estático es minúsculo; en SSR lo domina el trabajo que haces antes de emitir HTML: consultar bases de datos, llamar a APIs, renderizar. Un TTFB alto empuja hacia atrás todo lo demás, incluido el LCP, porque el navegador no puede empezar hasta que llega ese primer byte.

# Medir el TTFB de una URL sin descargar el cuerpo entero
curl -w "TTFB: %{time_starttransfer}s\n" -o /dev/null -s https://mi-sitio.dev

La causa más común de un TTFB inflado es una espera lenta en el bloque de la página —una consulta que tarda— colocada en el camino crítico. La disciplina del SSR consiste en atacar esa espera por tres vías: no repetirla (caché), no bloquear con ella toda la página (streaming) o hacerla desde más cerca (edge).

Cachear datos y respuestas

Hay dos niveles de caché y conviene no confundirlos. El primero es cachear los datos: evitar repetir una consulta cara guardando su resultado con un tiempo de vida. El segundo es cachear la respuesta entera en un CDN, para que muchas peticiones idénticas ni siquiera lleguen a ejecutar tu código.

// Cachear datos en memoria con un tiempo de vida
const cache = new Map<string, { valor: unknown; hasta: number }>();

async function cachear(clave: string, ttl: number, cargar: () => Promise<unknown>) {
  const hit = cache.get(clave);
  if (hit && hit.hasta > Date.now()) return hit.valor;
  const valor = await cargar();
  cache.set(clave, { valor, hasta: Date.now() + ttl });
  return valor;
}

Para cachear la respuesta, la cabecera Cache-Control con directivas de CDN hace el trabajo. s-maxage fija cuánto la sirve cacheada el CDN, y stale-while-revalidate permite entregar una versión ligeramente vieja al instante mientras se refresca en segundo plano: el visitante nunca espera a la revalidación.

// El CDN sirve cacheado 60 s y revalida sin bloquear durante 10 min
context.response.headers.set(
  'Cache-Control',
  'public, s-maxage=60, stale-while-revalidate=600',
);

Streaming de HTML

Astro no espera a tener el HTML completo para empezar a enviarlo: lo transmite por streaming a medida que lo genera. El navegador recibe la cabecera y el esqueleto de la página, y empieza a descargar estilos y a pintar, mientras el servidor sigue produciendo el resto. Esto hace que dónde colocas tus esperas importe enormemente.

El bloque de una página .astro corre entero antes de emitir su HTML. Si pones ahí una espera lenta que bloquea toda la página, retrasas el primer byte de todo. La alternativa es no bloquear el esqueleto con lo lento: dejar que el shell fluya y traer los datos tardíos por otra vía.

---
// MAL: esta espera lenta retrasa el primer byte de toda la pagina
const todo = await consultaLentisima();
---
<article>{todo.contenido}</article>

Server islands y el edge

La herramienta que Astro da para sacar lo lento del camino crítico es la server island. Ya la viste: server:defer renderiza al instante un contenido de reserva y produce la parte dinámica en una petición aparte que se inserta después, sin bloquear el esqueleto y sin un gramo de JavaScript de cliente. Es la forma idiomática de mezclar un shell cacheable con una pieza fresca por visita.

---
import Recomendados from '../components/Recomendados.astro';
---
<article>Contenido estático y cacheable de la página.</article>

<Recomendados server:defer>
  <p slot="fallback">Cargando recomendaciones...</p>
</Recomendados>

La última palanca es espacial: acercar el cómputo. Desplegar el SSR en el edge —servidores repartidos por el mundo, cerca del visitante— recorta la latencia de red y con ella el TTFB, porque la petición viaja menos. El precio es un entorno más limitado y la distancia a tus datos: si tu base de datos está lejos del edge, ganas en un lado lo que pierdes en el otro. Mídelo antes de decidir.

Prerenderizar lo que no cambia

La optimización más contundente de una ruta SSR es dejar de renderizarla por petición. En el modo híbrido de Astro, cada página decide su naturaleza: las que no dependen de la petición pueden prerenderizarse a HTML estático en el build y servirse con TTFB de archivo, reservando el SSR para lo que de verdad cambia por visita.

---
// Esta pagina se genera en el build, no por peticion
export const prerender = true;
---

El criterio es preguntar, ruta a ruta, si su contenido depende de quién pide o de cuándo pide. La portada de un blog, una ficha de producto que cambia cada hora, la documentación: casi todas pueden ser estáticas o cacheadas con revalidación, y solo el panel personalizado o el carrito necesitan renderizado fresco. Afinar SSR empieza por reducir cuánto SSR hay: la ruta más rápida es la que ya estaba escrita antes de que llegara la petición.

flowchart LR
REQ[peticion entra] --> EDGE[servidor en el edge cercano]
EDGE --> C{respuesta en cache}
C -->|si| HIT[TTFB minimo sin render]
C -->|no| REN[renderiza y guarda en cache]
REN --> SHELL[envia el shell por streaming]
SHELL --> DEF[server islands llegan despues]
style HIT fill:#a6e3a1,color:#11111b
style SHELL fill:#89b4fa,color:#11111b
style DEF fill:#fab387,color:#11111b