Diseñar el render por página: el mapa de decisión

El dial de renderizado que aprendiste —estático, SSR, server island— no es un interruptor que se acciona una vez para todo el proyecto: es una decisión que se toma ruta a ruta, y un producto real de verdad usa las cuatro posiciones a la vez. Diseñar el render es el arte de mirar cada página y preguntarle dos cosas: cuán fresco necesita ser su dato y si cambia según quién la pide. Las respuestas la colocan, sin ambigüedad, en el punto exacto del dial donde es más rápida y más barata sin dejar de ser correcta.

Dos preguntas deciden el render de cada ruta

Toda la complejidad del renderizado se colapsa en dos preguntas, y su cruce forma un cuadrante que no deja huecos.

La primera: ¿el dato de esta página cambia entre el build y la petición? Si basta con lo que había al construir —un artículo, una página legal, la documentación—, es estático: se hornea una vez y lo sirve un CDN sin ejecutar nada. Si el dato debe estar fresco en el instante de la visita —un stock, un precio, un panel—, es dinámico y necesita resolverse bajo demanda.

La segunda: ¿la página es igual para todos o se personaliza por usuario? Una portada idéntica para el mundo entero es cacheable aunque su dato sea algo dinámico; un carrito o un dashboard dependen de quién pregunta y no se pueden compartir entre visitantes. El cruce de ambos ejes te dice si la ruta es estática, una server island cacheable, o SSR por usuario.

---
// El dial se acciona por pagina con una linea
export const prerender = true;   // horneada en el build, servida por CDN
// export const prerender = false; // bajo demanda, resuelta en cada peticion
---

El cuadrante, sin huecos

Cruzar los dos ejes produce cuatro casillas, y toda página del mundo cae en una de ellas. Nombrarlas convierte la intuición en método.

El mapa aplicado a un producto real

Tomemos un producto completo —una tienda con blog, cuenta de usuario y documentación— y coloquemos cada zona en el dial. Este reparto es el patrón, no la excepción.

Fíjate en que el listado de productos es el caso más interesante: la rejilla, los filtros y el texto son estáticos y cacheables, pero el precio y la disponibilidad son server islands. Una página que parece dinámica es, en realidad, HTML estático servido al instante con unos pocos huecos que se rellenan con dato fresco. El patrón se lee limpio en el propio componente:

---
// src/pages/tienda/[slug].astro  ->  estatico por defecto
import Precio from '../../components/Precio.astro';
---
<h1>{producto.nombre}</h1>
<p>{producto.descripcion}</p>
<Precio server:defer>
  <span slot="fallback">Consultando precio...</span>
</Precio>

La búsqueda, en cambio, sí es dinámica de arriba abajo: es un endpoint o una página SSR porque su resultado depende por completo de lo que el usuario teclea, y no hay build que pueda anticiparlo.

// src/pages/api/buscar.ts  ->  dinamico de arriba abajo, nada que hornear
export const prerender = false;
export async function GET({ url }) {
  const q = url.searchParams.get('q') ?? '';
  return Response.json(await buscarEnIndice(q));
}

Esta asimetría es reveladora: dos rutas de la misma tienda —la ficha casi estática con un hueco fresco, la búsqueda entera dinámica— viven en extremos opuestos del dial porque su relación con el dato es opuesta. No hay un modo de render correcto para la tienda; hay uno correcto para cada una de sus páginas, y diseñar el render es desmenuzar el producto hasta que cada ruta cae, sola, en su casilla.

flowchart TD
R[Nueva ruta] --> Q1{El dato cambia en cada peticion}
Q1 -->|no basta el build| EST[Estatico SSG en CDN]
Q1 -->|si| Q2{Es personalizado por usuario}
Q2 -->|no igual para todos| SI[Server island con cache propia]
Q2 -->|si| Q3{Necesita computo pesado o BD cercana}
Q3 -->|no la latencia manda| EDGE[SSR en el edge]
Q3 -->|si| REG[SSR regional serverless o Node]
style EST fill:#a6e3a1,color:#11111b
style SI fill:#94e2d5,color:#11111b
style EDGE fill:#89b4fa,color:#11111b
style REG fill:#fab387,color:#11111b

Edge o región: el último matiz

Cuando una ruta es SSR, queda una decisión más: dónde corre ese código. El edge —Workers repartidos por el globo— pone tu cómputo a milisegundos del usuario, ideal para personalización ligera, geolocalización y redirecciones rápidas. La región —una función serverless o un Node en un centro de datos— gana cuando el trabajo es pesado, necesita estar junto a la base de datos, o dura más de lo que un Worker tolera.

La server island añade el matiz más fino de todos: te deja mantener la página estática en el CDN y empujar al servidor solo el fragmento dinámico, con su propia cabecera de caché. Es el dial en su máxima granularidad —no la página o el servidor, sino este trozo aquí, con esta frescura—. Diseñar bien el render es, casi siempre, mantener el máximo de superficie en el extremo barato del dial y escalar quirúrgicamente lo mínimo imprescindible.

Ese fragmento se declara con server:defer sobre una página que sigue horneada: la cáscara es estática y solo el trozo marcado viaja al servidor, con su propio fallback mientras resuelve.

---
// La pagina sigue estatica; solo el fragmento se resuelve en el servidor
export const prerender = true;
---
<article>{articulo.cuerpo}</article>
<Stock server:defer>
  <span slot="fallback">Comprobando disponibilidad...</span>
</Stock>