SSR en el edge: renderizar cerca del usuario

Renderizar en el servidor —SSR— siempre fue una elección entre HTML listo al instante y la latencia de un servidor lejano. El edge reescribe esa ecuación: si el servidor que renderiza está a milisegundos del usuario, obtienes lo mejor de ambos mundos, HTML dinámico y personalizado sin el peaje de la distancia. Pero mover el cómputo cerca del usuario abre una pregunta nueva y afilada: ¿dónde están los datos? El SSR en el edge es tan potente como cuidadoso hay que ser con eso, y esta lección es sobre ambas caras.

Renderizar a milisegundos del usuario

En el SSR clásico, un servidor central —pongamos en una región de Estados Unidos— recibe la petición, renderiza el HTML y lo devuelve. Para un usuario en Madrid o en Yakarta, cada petición cruza el planeta dos veces antes de ver un solo píxel. El edge elimina ese viaje: el mismo código de renderizado se ejecuta en el centro de datos más cercano a quien pide, así que el HTML se genera al lado del usuario y no a un océano de distancia.

La ventaja se nota sobre todo en el tiempo hasta el primer byte, el TTFB. Como el isolate arranca sin cold start y renderiza localmente, el HTML empieza a fluir casi de inmediato. Y a diferencia de una página estática, sigue siendo dinámico: puedes personalizar por usuario, por región o por la hora, porque hay cómputo real detrás de cada respuesta.

Conviene contrastarlo con la alternativa que dominó la década anterior: el renderizado en el cliente. Ahí el servidor envía un armazón de HTML casi vacío y un paquete de JavaScript que, ya en el navegador, pide los datos y construye la interfaz. El usuario mira una pantalla en blanco mientras descarga y ejecuta ese paquete. El SSR en el edge invierte el reparto: el trabajo pesado ocurre en el servidor cercano, y lo que llega al navegador es HTML ya formado que se pinta sin esperar a un bundle. El cliente recibe contenido, no una promesa de contenido.

La trampa de la localidad de datos

Aquí está el matiz que separa una demo bonita de un sistema real. Mover el cómputo al edge no mueve tus datos. Si tu Worker renderiza en Yakarta pero tu base de datos vive en Virginia, cada consulta que el renderizado necesite cruza medio mundo, y basta con encadenar unas pocas para que la latencia de los datos devore por completo la que ganaste acercando el cómputo.

Es la reencarnación de los dos ejes que atraviesan todo el track: acercar el cómputo al usuario solo rinde si los datos que ese cómputo consume también están cerca. Un SSR en el edge contra una base de datos regional y lejana puede ser más lento que un SSR regional pegado a esa misma base, porque suma la distancia en cada viaje de ida y vuelta.

flowchart TB
U[Usuario en Yakarta] --> W[Render en el edge cercano]
W -->|consulta 1| DB[Base de datos en Virginia]
DB -->|respuesta 1| W
W -->|consulta 2| DB
DB -->|respuesta 2| W
W --> H[HTML al usuario]
style W fill:#fab387,color:#11111b
style DB fill:#f38ba8,color:#11111b

Las salidas son dos, y conviene tenerlas claras. La primera es acercar también los datos: usar almacenes pensados para el edge —KV para lecturas globales, D1 con réplicas, Durable Objects para estado coordinado— de modo que la lectura no cruce el planeta. La segunda, cuando los datos deben vivir en una base regional, es la colocación inteligente: pedir a la plataforma que ejecute el Worker cerca de esos datos en lugar de cerca del usuario, invirtiendo el reparto para minimizar el número y la longitud de los viajes.

Streaming: no esperes al HTML entero

El edge tiene una carta extra que el SSR tradicional rara vez juega bien: el streaming. Como el fetch handler puede devolver una Response cuyo cuerpo es un ReadableStream, el framework puede empezar a enviar el HTML de la cabecera y del armazón de la página mientras aún resuelve los datos de las partes lentas. El navegador recibe y pinta lo primero de inmediato, y el resto llega en cuanto está listo.

// el render devuelve un stream; el runtime envia bytes segun se producen
const stream = await renderToReadableStream(<App />);
return new Response(stream, {
  headers: { "Content-Type": "text/html" },
});

Los frameworks modernos —React con sus Suspense, Astro con sus islas de servidor— exponen esto de forma declarativa. La consecuencia práctica es que la latencia de los datos deja de bloquear la primera pintura: el usuario ve estructura al instante y el contenido lento aparece en su hueco cuando llega, en lugar de mirar una pantalla en blanco hasta que todo esté resuelto.

La caché es la otra mitad

La pregunta más sana ante cualquier SSR es: ¿de verdad necesito renderizar esto en cada petición? Muchísimo HTML cambia poco entre usuarios o entre minutos, y renderizarlo una y otra vez es quemar cómputo para reproducir un resultado idéntico. La caché del edge convierte ese derroche en una lectura instantánea.

Con la Cache API o con cabeceras Cache-Control, guardas el HTML renderizado en el mismo edge que lo produjo, de forma que las siguientes peticiones lo reciben sin volver a renderizar ni a tocar la base de datos. El patrón stale-while-revalidate afina la idea: sirve la versión cacheada al instante y revalida en segundo plano, así nadie espera por el renderizado y el contenido se mantiene fresco.

// sirve del cache al instante, revalida en segundo plano hasta 5 min
return new Response(html, {
  headers: {
    "Content-Type": "text/html",
    "Cache-Control": "public, s-maxage=60, stale-while-revalidate=300",
  },
});

La regla mental es sencilla: renderiza en cada petición solo lo que de verdad cambia en cada petición. Un panel personalizado para un usuario concreto lo justifica; una página de producto que cambia una vez al día, no. Situar cada ruta en el punto correcto entre el estático y el SSR puro es, en la práctica, la decisión que más afecta al coste y a la latencia de una aplicación en el edge.