El espectro de renderizado edge: el framework de decisión que usamos para sitios de contenido

No existe una talla única para renderizar contenido web. Decidir si una página debe ser estática, renderizarse en el edge, o generarse completamente desde el servidor es una de las decisiones técnicas que más impacto tiene en rendimiento, costo y experiencia de usuario. En 2026, con las opciones multiplicándose — static build, Server Islands, edge SSR, server SSR, CSR — el problema ya no es "cómo renderizar esto", sino "qué parte renderizar dónde".

Llevamos seis meses operando mintec.co y varios sitios de clientes sobre Astro + Cloudflare Pages, combinando static build con Server Islands y edge functions. Estos son los números reales, el framework de decisión que construimos a partir de ellos, y las lecciones que nos llevamos.

El espectro: seis niveles de renderizado

La mayoría de los análisis sobre rendering comparan dos opciones (SSG vs SSR) y se detienen ahí. En la práctica, existen al menos seis niveles, y cada uno responde a un perfil distinto de contenido:

La clave no está en elegir un nivel para todo el sitio, sino en asignar cada página o componente al nivel correcto. Eso es lo que hace que este espectro sea útil como framework de decisión, no solo como clasificación.

Nuestros datos de producción

Hemos medido estos niveles en proyectos reales. La tabla anterior no es teórica — corresponde a métricas de:

• mintec.co: static build (nivel 1) con Server Islands (nivel 3) para el contador de proyectos y testimonios dinámicos. Build completo en ~30s. Hosting: $0/mes en Cloudflare Pages. Lighthouse 99/100.
• Portal editorial multilingüe: 2,500+ páginas en 3 idiomas. Static build (nivel 1). 95% del contenido servido desde CDN sin ejecutar una sola función. TTFB medio de 98ms desde edge en Panamá para usuarios latinoamericanos.
• Portal de marca de lujo con galerías 4K: Server Islands (nivel 3) para carga diferida de video. LCP pasó de 6.2s a 1.2s. INP de 98ms.

El patrón que se repite: el 80% del contenido de un sitio de contenido puede ser estático (nivel 1). El 15% necesita Server Islands (nivel 3). Solo el 5% requiere edge SSR o superior (niveles 4-6). Cuando violamos esta regla — y lo hemos hecho — pagamos en complejidad de infraestructura y fugas de presupuesto.

El framework de decisión: cuatro preguntas

Decidir el nivel de renderizado para cada página o componente se reduce a cuatro preguntas. Las formulamos después de varios intentos de sobre-ingeniería — esa tentación de la que ya hemos hablado.

1. ¿Cada cuánto cambian estos datos?

Esta es la pregunta más importante. Si el contenido se actualiza manualmente (blog posts, páginas de servicio), la respuesta es "en cada deploy" — y la opción correcta es static build (nivel 1 o 2). Si los datos cambian cada hora (precios, inventario), necesitas Server Islands o Live Collections (nivel 3). Si cambian en cada request (dashboard personalizado), estás en nivel 4+.

2. ¿El contenido varía por usuario o ubicación?

Sin personalización → static o Server Island. Con personalización por región (precios en moneda local, testimonios por país) → Server Islands son suficientes si el número de variantes es manejable. Con personalización 1:1 (cada usuario ve algo distinto) → edge SSR o server SSR.

3. ¿Cuánto tráfico recibe y desde dónde?

Para sitios con audiencia predominantemente latinoamericana, la latencia importa más que en mercados con mejor infraestructura. Nuestras mediciones muestran que un static build servido desde Cloudflare edge (nivel 1) tiene TTFB de 50-120ms en toda Latinoamérica. Un edge SSR desde el mismo edge (nivel 4) añade 100-200ms por la ejecución de la función. Un server SSR desde un VPS en Miami (nivel 5) puede superar los 600ms para un usuario en Perú. En dispositivos mid-range con conexiones 3G/4G, esa diferencia puede convertir una página aceptable en una que el usuario abandona.

4. ¿Cuánta interactividad necesita la página?

Si la página necesita poca o ninguna interacción → static (nivel 1-2). Si necesita componentes interactivos puntuales → islands (nivel 2-3). Si la página entera es una aplicación → CSR (nivel 6) con SSR en las rutas críticas.

La matriz de decisión

Combinando las cuatro preguntas, llegamos a esta matriz que usamos en cada proyecto:

Lo que aprendimos aplicando esto

Tres lecciones concretas después de seis meses aplicando este framework en proyectos reales:

La sobre-ingeniería empieza en el nivel 3. Server Islands son tan fáciles de implementar en Astro 6+ que la tentación es convertir todo en isla. En uno de nuestros proyectos, el equipo hizo server island hasta del footer. El footer no necesitaba datos frescos ni personalización. Era más rápido y simple como HTML estático. La regla: si puedes predecir el output en build time, no lo conviertas en isla.

El edge no es gratis. Aunque Cloudflare Workers tienen un generoso free tier, cada invocación de Server Island o edge function añade latencia y costo. Medimos que una página con 3 Server Islands tenía un TTFB 2.3x mayor que la misma página con 0 islands (98ms vs 225ms). Para la mayoría de los casos, vale la pena, pero demuestra que no deberías añadir islands por estética técnica — solo cuando los datos lo requieran.

LatAm necesita el edge más que otros mercados. Los 300+ puntos de presencia de Cloudflare hacen que el static build servido desde el edge tenga TTFB competitivo incluso contra servidores locales. Hemos visto sitios con hosting tradicional en Miami que rinden peor para usuarios en Centroamérica que un static build en Cloudflare Pages. Para nuestros clientes latinoamericanos, static build + edge es casi siempre la combinación correcta, con Server Islands solo para los componentes mínimos que realmente necesitan datos vivos.

Cuándo subir de nivel

El framework no es rígido. Hay casos donde tiene sentido subir de nivel aunque las preguntas digan lo contrario. Nuestros benchmarks de Astro vs Next.js muestran que un proyecto puede beneficiarse de edge SSR incluso con contenido mayormente estático si necesita renderizado multilingüe complejo o accesibilidad cross-browser que requiera lógica de servidor.

La diferencia entre un buen arquitecto web y uno excelente no está en saber implementar Server Islands o edge functions — está en saber cuándo no usarlos. Ese criterio es lo que separa un sitio rápido y mantenible de una sobre-arquitectura que se siente moderna pero cuesta más de lo que aporta.

Si estás definiendo la arquitectura de tu próximo sitio de contenido, empieza por lo mínimo (static build) y escala hacia arriba solo cuando los datos lo exijan. Esa disciplina, más que cualquier tecnología específica, es lo que realmente determina el rendimiento en producción.