Rendering Strategies

Dónde y cuándo se produce la representación

Rendering Strategies agrupa decisiones arquitectónicas sobre dónde y cuándo se produce una representación Web y cómo se combinan trabajo generado en servidor y ejecución cliente para entregar y actualizar la UI. Importan HTML inicial, datos, runtime, activación e interacción posterior. No se reduce a elegir una etiqueta entre CSR y SSR.

El alcance de este canonical es principalmente Web. frontend-and-client-architecture también incluye clientes nativos y móviles, con lifecycles y mecanismos que no deben forzarse dentro de esta terminología. La estrategia de rendering tampoco define toda la arquitectura frontend: no resuelve por sí sola ownership de estado, colaboración de presentación, límites internos o autorización.

Como vocabulario de trabajo, el Atlas separa ubicación, momento, contenido inicial y ejecución posterior. Las fuentes pueden agruparlos de otra manera. Rendering on the Web, de web.dev distingue server rendering, client rendering y generación estática, y advierte que su uso de prerendering no equivale al prerendering del navegador para futuras navegaciones. Se conserva esa diferencia en lugar de asumir un estándar único.

Dynamic rendering también necesita contexto: Google Search usa el término para un workaround que entrega una versión renderizada a determinados bots y otra cliente a usuarios. No se adopta como sinónimo de SSR por request ni como recomendación del Atlas. Las categorías arquitectónicas de alto nivel no se presentan como taxonomía estandarizada por WHATWG o W3C.

Alternativas que pueden combinarse

Enfoque	Producción de representación	Qué revisar después
Client-Side Rendering	Trabajo significativo en el browser mediante JavaScript.	HTML inicial, datos, costo de ejecución y dependencia de JS.
SSR por request	HTML generado durante ejecución de servidor asociada a una petición.	Tiempo de respuesta, contexto, capacidad y activación cliente.
Generación estática	Representación preparada antes de la petición concreta.	Regeneración, variantes, caches y vigencia.
Composición híbrida	Reparto por ruta, página, región o interacción según plataforma.	Fronteras, coherencia y costos combinados.

La tabla no establece ranking ni categorías mutuamente excluyentes. Una misma aplicación puede combinar representación inicial de servidor y cambios cliente, o usar distintas decisiones por ruta. Un «frontend SSR» necesita más precisión para saber qué recibirá y ejecutará realmente el usuario.

CSR: trabajo significativo en el cliente

En CSR, el browser produce parte significativa de la UI utilizando runtime, estado y datos. El servidor todavía puede entregar shell HTML, assets, metadata y APIs: CSR no significa ausencia de servidor. También puede existir contenido inicial que luego se sustituye o amplía.

Esto permite interacciones ricas y navegación sin recargar documentos cuando la aplicación lo implementa. Puede exigir descargar, parsear, compilar y ejecutar JavaScript antes de mostrar o usar ciertas partes. Cantidad de código, dispositivo, red y dependencias de datos importan; CSR no es intrínsecamente lento ni garantiza una UI fluida después del arranque.

Si el JS requerido no carga o falla, parte de la funcionalidad puede quedar inaccesible aunque el HTML del shell haya llegado. Es una condición de evaluación del diseño, no una afirmación de que toda aplicación CSR queda vacía ante cualquier error. Examinar la capacidad concreta y qué contenido conserva otro camino.

SSR por request y generación previa

Aquí SSR por request designa producción de HTML durante ejecución de servidor relacionada con una petición. Puede reunir datos y representación antes de enviarlos, o transmitir partes progresivamente. No implica ausencia de JavaScript, estado cliente, hydration ni navegación similar a una SPA.

Preparar la representación puede desplazar trabajo de inicio al servidor y entregar contenido antes de ejecutar la aplicación cliente. También introduce CPU, memoria, I/O y espera de dependencias en ese recorrido. El beneficio depende de qué trabajo se elimina, cuánto tarda el backend y qué debe ejecutar después el browser. «SSR siempre es más rápido» omite esas condiciones.

Generación estática prepara HTML antes de una petición específica, comúnmente en build o publicación. El contenido puede reconstruirse, regenerarse o combinarse con datos de runtime; static no significa inmutable para siempre. Las categorías y APIs de revalidación incremental pertenecen a productos concretos, no a un protocolo universal.

Puede reducir cómputo por request y facilitar distribución de contenido ya preparado. El costo se traslada a build, regeneración y variantes: muchas URLs, idiomas o combinaciones pueden ampliar el trabajo. Hay que decidir qué vigencia admite el contenido y cómo se detecta una generación fallida o atrasada.

Activar interacción no es lo mismo que generar HTML

Hydration suele describir cómo el runtime cliente incorpora estado y comportamiento a markup generado previamente. SSR produce representación; hydration es un mecanismo posterior de interacción. Una página de servidor puede conservar HTML funcional con interacción tradicional o añadir comportamientos puntuales sin hidratar toda una aplicación.

Como ejemplo específico, React hydrateRoot conecta React con HTML previamente generado y espera correspondencia entre el output inicial del servidor y del cliente. No se prescribe su algoritmo para otras plataformas. Hydration completa de una aplicación también puede requerir mucho JavaScript; SSR por sí solo no garantiza un bundle pequeño.

Si servidor y cliente observan datos diferentes, usan tiempo o aleatoriedad de forma incompatible o dependen de APIs exclusivas del browser, pueden aparecer mismatches. Según mecanismo, pueden producir warnings, recuperación o representación inconsistente. El HTML inicial y el estado de activación necesitan un contrato coherente; ocultar el aviso no demuestra resolver el desacuerdo.

Partial, selective e islands con contexto

Partial hydration suele señalar activación limitada a partes que la necesitan, pero el alcance varía entre fuentes. Astro Islands describe islas interactivas dentro de una página mayormente estática y control sobre su carga. Es una realización concreta; no toda activación parcial constituye islands ni requiere Astro.

React Suspense utiliza Selective Hydration como mecanismo integrado con sus boundaries y rendering de servidor. Se conserva ese término de React, sin convertirlo en sinónimo universal de partial o lazy hydration. Seleccionar cuándo activar una región y excluir otras de la activación son decisiones relacionadas pero distintas.

Estos mecanismos buscan orientar trabajo cliente; necesitan evaluar código transferido, coordinación, secuencia y experiencia real. Resumability queda fuera de esta introducción: no hace falta agregar otra categoría para comprender las decisiones centrales. Ninguno de estos nombres reemplaza explicar qué contenido llega y qué trabajo sigue pendiente.

Streaming y dependencias de datos

Streaming permite entregar output progresivamente en lugar de esperar a completar toda la representación. La API de streaming de React muestra un mecanismo concreto para enviar shell y contenido posterior. La semántica de sus boundaries pertenece a React; el principio de transmisión progresiva es más amplio.

Puede adelantar contenido útil, pero no garantiza mejor experiencia: importan servidor, red, buffering, datos y activación. Una región visible todavía puede no estar lista para interactuar. Streaming de HTML tampoco equivale al manejo asíncrono de estado cliente mediante unidirectional-data-flow.

La estrategia afecta dónde, cuándo y bajo qué contexto se cargan datos: servidor antes de representar, cliente después de carga o combinaciones paralelas e incrementales. Dependencias encadenadas pueden crear waterfalls en ambos lados. SSR no arregla automáticamente una secuencia de consultas dependientes ni toda composición incremental elimina esperas.

Navegación, ejecución y deployment

SPA y MPA describen organización y navegación, no equivalen a CSR y SSR. Una aplicación inicialmente renderizada en servidor puede continuar con navegación cliente; un sitio multipágina puede ejecutar rendering cliente dentro de cada documento. Especificar ambas dimensiones evita deducir comportamiento por un acrónimo.

execution-model permite examinar activación y duración del trabajo, pero no es otro nombre de ubicación del rendering. SSR puede operar en proceso duradero, función o runtime de plataforma. deployment examina packaging y unidades actualizables; un container no obliga a SSR y entregar archivos estáticos no define cómo se actualizará cada región interactiva.

Cambiar estrategia puede introducir artefactos y compatibilidad entre HTML, assets y datos. Si el HTML servido espera una versión de código que no está disponible, una entrega aparentemente correcta puede fallar al activar interacción. Ese riesgo pertenece a la composición concreta, no a una imposibilidad universal del rendering híbrido.

Costos, cache y contenido personalizado

Examinar trabajo cliente y servidor durante arranque, navegación e interacción, no solo tamaño del HTML. cost-efficiency conecta recursos con resultados útiles; operability incorpora diagnóstico y operación del runtime o del proceso de regeneración. Desplazar trabajo puede reducir un costo y crear otro.

Caches dependen de vigencia, variación, autorización y personalización. La guía HTTP caching de MDN distingue caches compartidas y privadas y el tratamiento de contenido personalizado. No todo HTML generado en servidor es compartible; aislar el contexto importa tanto como evitar cómputo repetido.

Personalizar puede reducir reutilización entre usuarios, pero no prohíbe todas las formas de generación previa o servidor. Un shell compartido puede combinarse con datos privados posteriores bajo contratos adecuados. SSR por request tampoco garantiza datos actuales: caches y fuentes consultadas pueden estar desactualizadas. HTML y estado cliente pueden observar momentos diferentes; rendering no resuelve consistencia distribuida.

La estrategia no define seguridad. Un servidor puede consultar con contexto autorizado y un cliente puede llamar APIs autenticadas; cualquier dato serializado y enviado al browser queda disponible allí. SSR no mantiene secreto lo que entrega en HTML o estado de activación. La elección exige conservar límites de acceso, sin convertir este canonical en tutorial de autenticación.

Descubrimiento, fallos y qualities separadas

HTML con contenido significativo puede estar disponible sin ejecutar JavaScript. Eso no significa que CSR sea imposible de indexar: Google Search documenta procesamiento y rendering de JavaScript, con condiciones y limitaciones. Otros consumidores pueden comportarse de otra manera. SSR no garantiza SEO, del mismo modo que una estrategia no garantiza accessibility: semántica y foco deben conservarse también tras activación y navegación cliente.

web-performance evalúa cuándo el resultado se vuelve útil, responde y permanece estable mediante evidencia field/lab. Aquí se conservan consecuencias de HTML inicial, trabajo servidor, JS, hydration y streaming: cambiar su ubicación no garantiza una experiencia mejor. internationalization añade contexto de locale, lenguaje y dirección a variantes servidor/static/cliente; representación inicial y activada necesitan expectativas compatibles. No inferir calidad del resultado por el lugar donde se produjo.

Los modos de fallo difieren: JS requerido que no ejecuta, renderer lento o indisponible, contenido estático vencido, regeneración fallida o desacuerdo entre servidor y cliente. Comparar capacidades afectadas y recuperación mediante trade-off-analysis, sin afirmar que una estrategia es universalmente más resiliente.

Commerce: composición por necesidad

En este ejemplo propio, una landing pública de catálogo podría generarse previamente y servirse desde cache; una página de producto podría obtener representación de servidor relacionada con datos actuales; cart y checkout podrían mantener interacción rica cliente. Son candidatos sujetos a vigencia, personalización, costo y condiciones reales, no una arquitectura recomendada para todo comercio.

Otra combinación entrega checkout inicialmente desde servidor y activa comportamiento cliente. PayRequested recorre después un flujo UDF hacia estado pendiente, efecto de pago y nueva representación. presentation-patterns organiza responsabilidades de presentación; client-state-management examina ownership, lifecycle y vigencia de los datos iniciales del cliente. Ninguna de esas preguntas queda respondida solo por elegir SSR ni la activación demuestra sincronización de todas las copias.

La estrategia puede variar por ruta o, si la plataforma permite fronteras apropiadas, por región o componente dentro de la página. Ese reparto no obliga a micro-frontends, que examina fronteras de autonomía de entrega y composición. Un runtime SSR no es automáticamente backend-for-frontend: producir representación y adaptar capacidades para una experiencia son roles diferentes, aunque un proceso reúna ambos. Offline First tampoco equivale a CSR, y rendering servidor no excluye toda capacidad offline.

Elegir requiere contenido dinámico, interacción, dispositivos, startup, caches, datos, costos y fallos relevantes. Mantener nombres de framework como ejemplos, no definiciones universales. frontend-and-client-architecture conecta estas decisiones con otras dimensiones sin imponer una única estrategia para toda aplicación ni un score de rendering.