En desarrollo web, hay una frustración común, creamos interfaces espectaculares que funcionan como un rayo en nuestro entorno local… pero al publicarlas, algo sucede que no controlamos como en el entorno local. El tiempo de carga se alarga, la interacción se retrasa y los usuarios abandonan antes de que la Web pueda reaccionar.
Sergio Vergara
La causa no suele estar en tu JavaScript, ni en la conexión del usuario. El problema está probablemente en el servidor, pero en algunas ocasiones se trata de la arquitectura de renderizado.
Con este escenario en mente, quiero presentarte una técnica poco aprovechada pero extremadamente poderosa, el HTML streaming desde el servidor. Con ella puedes acelerar significativamente la carga inicial, sin reescribir toda tu aplicación ni cambiar de framework.
¿Por qué las aplicaciones modernas siguen cargando lento?
La mayoría de aplicaciones web actuales usan frameworks como React, Vue o Angular, y por defecto implementan renderizado del lado del cliente (Client-Side Rendering CSR, por sus siglas en inglés).
¿Qué significa esto?
- El navegador pide la página.
- El servidor responde con un HTML vacío (o casi).
- El navegador empieza a descargar un gran paquete de JavaScript.
- Una vez descargado, lo ejecuta.
- El JavaScript hace llamadas a APIs para obtener los datos.
- Finalmente, se construye la UI y se muestra al usuario.
Este flujo es secuencial. Cada paso depende del anterior. Y eso es lo que genera la famosa “pantalla en blanco” durante varios segundos, sobre todo en conexiones lentas o dispositivos poco potentes.
El cuello de botella: la cascada del CSR
Tomemos un ejemplo simple: una pantalla de gráficas en una SaaS CRM.
Aunque visualmente no sea muy complejo, en CSR el navegador:
- Recibe solo el esqueleto HTML.
- Descarga el JS.
- Espera las respuestas de la API.
- Recién entonces muestra contenido útil para ver las gráficas.
Cada retraso se encadena al siguiente. Y si el paquete JS pesa 2MB y tu API tarda 1 o 2 segundos, el usuario puede estar mirando una pantalla vacía durante 5 segundos o más, y eso es demasiado.
Una alternativa es Server-Side Rendering (SSR)
El renderizado del lado del servidor (SSR) soluciona parte del problema. En lugar de enviar un HTML vacío, el servidor genera todo el contenido HTML y lo envía ya renderizado. Así, el usuario ve contenido desde el primer momento, incluso si el JS aún no ha terminado de cargar.
Esto mejora enormemente la percepción de rendimiento.
Pero el SSR clásico no es tan fácil de aplicar si tu app ya está en producción. Implica reestructurar componentes, manejar el estado del servidor y del cliente, y lidiar con la famosa “hidratación” en React, que puede generar errores sutiles.
La solución ligera: HTML Streaming
Aquí es donde entra el protagonista del día: transmisión de HTML en streaming desde el servidor.
La idea es simple pero efectiva, en lugar de esperar a tener todo el contenido listo para enviar la respuesta, el servidor va enviando el HTML por partes, a medida que los datos están disponibles.
Esto permite paralelizar lo que normalmente es una cadena de tareas secuenciales.
¿Cómo funciona?
- El usuario accede a tu página.
- El servidor envía inmediatamente un primer fragmento de HTML con la cabecera, los estilos, y quizá un loader.
- Mientras el navegador procesa ese primer trozo y comienza a descargar el JS, el servidor hace las llamadas a la API necesarias.
- A medida que llegan los datos, el servidor sigue enviando fragmentos de HTML que van completando la página.
- Para cuando el JS esté listo, ya tiene los datos necesarios embebidos en el HTML. No es necesario hacer llamadas extra desde el cliente.
Ejemplo práctico con Express y Node.js
Veamos cómo sería esto en un entorno real con Express:
¿Qué hace este servidor?
Lo interesante de este ejemplo con Express es que no se comporta como el típico backend que espera tener todo listo antes de responder. En lugar de eso, actúa de forma mucho más eficiente, apenas recibe la solicitud del navegador, empieza a enviar contenido. Concretamente, lanza un primer bloque de HTML con lo esencial, cabecera, estilos, estructura básica, para que el navegador ya tenga algo que procesar y no muestre una pantalla en blanco.
Mientras tanto, y sin hacer esperar al usuario, el servidor inicia una llamada a una API para obtener los datos de ejemplo (en este caso, una lista de empleados). Cuando esos datos llegan, no se los guarda para más tarde ni espera a renderizar un componente completo, los inyecta directamente en el HTML a través de un <script> que los expone como una variable global. De esta forma, cuando el JavaScript del cliente se cargue, ya tendrá a mano la información que necesita, sin necesidad de volver a pedirla.
Y para cerrar el proceso, el servidor completa el HTML con el resto de la estructura, incluyendo la etiqueta de cierre del </body>, y finaliza la transmisión. El resultado es que el navegador empieza a renderizar antes de que el backend haya terminado del todo, lo que da una sensación de rapidez inmediata.
¿Por qué esta técnica es tan potente?
Lo realmente poderoso del HTML Streaming es cómo consigue romper la cadena de dependencias secuenciales que suele ralentizar las aplicaciones modernas. En lugar de esperar a que el JavaScript se descargue, se ejecute y recupere datos para mostrar algo en pantalla, aquí se da la vuelta a la lógica: el servidor se adelanta y le da al navegador un adelanto. Y eso es todo lo que el usuario necesita para empezar a interactuar con la página.
No se trata solo de velocidad técnica, sino de percepción de rendimiento. El usuario siente que la app es más rápida, más viva, más ágil, porque algo ocurre inmediatamente. Y en el mundo digital, eso es oro, una carga más rápida significa más retención, más conversión, menos rebotes.
Además, lo mejor es que no necesitas cambiar tu stack ni migrar a un framework nuevo. Si ya tienes una aplicación montada con React o Vue en CSR, puedes aplicar esta técnica desde el backend, sin tocar demasiado el frontend.
¿Y en qué casos tiene sentido utilizarlo?
HTML Streaming no es una solución mágica que debas aplicar a todo. Su valor aparece en situaciones muy concretas, pero comunes, por ejemplo, cuando la primera vista de tu aplicación depende de datos que puedes obtener desde el servidor sin intervención del usuario. Un dashboard con información del usuario, una página de inicio personalizada, o incluso una tienda con configuraciones básicas. Todos esos escenarios se benefician muchísimo de esta estrategia.
Es especialmente útil si estás en un proyecto en el que no puedes permitirte una migración completa a SSR o a un framework como Next.js. O si simplemente quieres dar un salto de calidad en rendimiento sin comprometer tu arquitectura actual.
También es ideal cuando tus datos no cambian constantemente, feature flags, configuraciones iniciales, listas precargadas… Si puedes predecir qué necesitará tu frontend antes de que empiece a actuar, puedes empezar a dárselo desde el minuto cero.
Algunos detalles importantes a tener en cuenta
Como toda técnica avanzada, HTML Streaming también requiere atención a ciertos aspectos para que funcione bien en producción. No basta con escribir res.write() y pensar que todo está resuelto.
Primero, hay que cuidar la caché de los recursos estáticos, si vas a servir CSS, imágenes o JavaScript en paralelo, asegúrate de que el navegador pueda almacenarlos y reutilizarlos eficazmente. Lo mismo ocurre con la compresión del contenido, activando Gzip o Brotli en tu servidor, reducirás aún más los tiempos de transferencia.
Luego está la cuestión de la seguridad. Si vas a inyectar datos directamente en el HTML, debes garantizar que están debidamente saneados para evitar vulnerabilidades como XSS (Cross-Site Scripting). Esto es especialmente crítico si esos datos provienen de fuentes externas o del usuario.
Y por supuesto, vale la pena monitorizar los efectos. Herramientas como Lighthouse, WebPageTest o el panel de rendimiento de Chrome te permiten medir el impacto real que tiene esta técnica sobre métricas como el Time to First Byte (TTFB) o el Largest Contentful Paint (LCP). No se trata solo de implementar una solución elegante, sino de confirmar que realmente mejora la experiencia para tus usuarios.
Frameworks que utilizan Streaming HTML
Varios frameworks modernos ya utilizan HTML streaming de forma nativa o lo incorporan como parte de sus estrategias de renderizado híbrido. Aquí te detallo los principales:
React 18 (con frameworks como Next.js o RSC)
React 18 introdujo oficialmente “Server Components” y streaming SSR como parte del core. Esto permite:
- Enviar partes del HTML a medida que están listas.
- Hacer suspense en el servidor.
- Evitar que todo el frontend espere a tener los datos completos.
¿Cómo se utiliza?
- Next.js 13+ con la carpeta app/ usa React Server Components y HTML streaming de forma nativa.
- Usa ReactDOMServer.renderToPipeableStream() en Node.js para lograr este flujo.
Next.js (v12.2+ en adelante)
Next.js adoptó el streaming en su renderizado híbrido:
- Puedes mezclar páginas estáticas, SSR tradicional y streaming.
- Con el nuevo router (app/) se aprovecha React 18 + HTML streaming.
- También soporta funciones como suspense, loading.tsx, y layouts anidados.
Remix
Remix es un framework pensado desde el principio para aprovechar las ventajas del servidor, y usa HTML streaming por defecto.
- Desde la primera carga ya estás transmitiendo contenido.
- La lógica del servidor y del cliente están profundamente integradas.
- El HTML llega al navegador antes de que el JS se haya descargado del todo.
Astro
Aunque Astro no hace “streaming” en el sentido tradicional de SSR reactivo, su estrategia de “partial hydration” y renderizado por islas permite:
- Cargar HTML estático rápidamente.
- Inyectar interactividad por partes, solo donde se necesita.
Si bien no transmite HTML progresivamente por chunks como React o Remix, su enfoque consigue un rendimiento similar con otro paradigma.
Qwik
Qwik va un paso más allá con su enfoque de resumibilidad. Su estrategia:
- Carga el HTML completo con estado incluido.
- Ejecuta el JS sólo cuando el usuario interactúa.
- A diferencia de React o Next, ni siquiera necesita hidratar toda la app de inmediato.
Esto evita por completo la cascada de CSR, y simula el resultado de un HTML streaming perfecto.
SvelteKit
SvelteKit soporta SSR con streaming en algunos adaptadores como el de Node.js.
- Puedes devolver respuestas text/html como streams.
- Hay soporte para ReadableStream en entornos como Cloudflare Workers o Vercel Edge.
Aunque el streaming no está tan integrado como en Next o Remix, puede implementarse si el entorno lo permite.
Otros frameworks que permiten HTML streaming:
- Nuxt 3 (Vue): Soporta streaming SSR cuando se usa con el motor Nitro.
- Express con React/Vue/Handlebars: Puedes implementarlo manualmente usando res.write() y renderToNodeStream() o renderToPipeableStream() (como en el ejemplo que vimos).
- Marko (de eBay): Diseñado para renderizado incremental y streaming desde el inicio.
En resumen:
Conclusión
El HTML streaming no es magia, pero es una técnica sorprendentemente eficaz para mejorar el rendimiento inicial de tu web sin tener que rehacer toda tu arquitectura.
Puedes implementarlo con pocas líneas de código, y en muchos casos, notarás una diferencia inmediata en la experiencia del usuario.
Cuando el rendimiento importa —y siempre importa—, cada segundo cuenta.
Referencias:
· Server-side rendering (SSR)
· Server-Side Rendering (SSR) overview
