Edge rendering en 2026: islas, streaming y la vuelta del HTML

Después de una década mandando JavaScript para renderizar HTML, la industria se acordó en conjunto de que los servidores son bastante buenos generando markup. El stack de 2026 se parece sospechosamente al de 2006, pero con mejores herramientas: HTML por la red, interactividad solo donde se gana sus bytes y una CDN que ejecuta tu código en vez de limitarse a cachearlo.

Cómo llegamos hasta acá

La era de las single-page apps optimizó la experiencia del desarrollador y las interacciones ricas, y lo pagó con bundles que pasaron el megabyte. El time-to-interactive en celulares de gama media (o sea, en los dispositivos que tiene la mayoría de la gente) se volvió una vergüenza que se medía en segundos. Las Core Web Vitals convirtieron esa vergüenza en una penalización de ranking, y de golpe la idea de mandar menos JavaScript tuvo respaldo de la gerencia.

Islas por defecto

El patrón ganador trata la interactividad como la excepción y no como la regla: HTML estático en todos lados, con hidratación reservada para los componentes que de verdad la necesitan, como el buscador, el carrito o el formulario de comentarios. Todo lo demás sale como markup y se queda como markup. Los equipos que adoptan islas reportan bundles entre un 80 y un 90% más chicos sin perder funcionalidad, porque la mayor parte de lo que hidrataban nunca había necesitado ser interactivo.

El streaming es la llave

El streaming fuera de orden permite pintar el shell de la página al instante mientras los datos más lentos van llegando. El usuario ve la navegación, el título y el layout en el primer round trip; las recomendaciones personalizadas aparecen cuando responde la base de datos. Sumado al cómputo en el edge, el time-to-first-byte pasa a ser un problema geográfico que sí se puede resolver: el shell se renderiza a 20 milisegundos del usuario mientras el origen hace el trabajo pesado.

La trampa de la localidad de datos

El edge rendering tiene una limitación honesta: tu cómputo se mudó a Frankfurt, pero tu base de datos sigue en Virginia. Una página que hace cuatro consultas secuenciales desde el edge es más lenta que la misma página renderizada al lado de los datos. Los patrones que funcionan: replicar en el edge los datos de mucha lectura, agrupar las consultas en un solo round trip, o renderizar los fragmentos con muchos datos en el origen y streamearlos dentro de un shell renderizado en el edge. Elegir mal es la causa número uno del clásico "nos pasamos al edge y quedamos más lentos".

Qué hacer con una app existente

Nadie mejora sus vitals reescribiendo todo desde cero. La migración que funciona es incremental: primero renderizá en estático las páginas de marketing y de contenido, después pasá el app shell a streaming, y degradá los componentes de hidratados a estáticos de a uno, midiendo en cada paso. El péndulo va a seguir oscilando, pero la dirección está clara: la web vuelve a ser un lugar donde el HTML es el producto y el JavaScript es el condimento.