Blazor Web Apps en la práctica: Elegir y aplicar Render Modes

En el artículo anterior vimos cómo Blazor evolucionó de ser «o WebAssembly o Server» a un modelo unificado mucho más potente. Pero saber que existe no es lo mismo que saber usarlo bien.

Hoy nos vamos a ensuciar las manos con la decisión más importante que tomarás al trabajar con Blazor Web Apps en .NET 10: ¿Qué Render Mode elijo para cada parte de mi aplicación?

«El render mode no es una decisión de implementación, es una decisión de arquitectura.”»

1. Por qué los Render Modes importan (y mucho)

Imagina que estás construyendo una tienda online. No todas las pantallas tienen las mismas necesidades:

La página de inicio debe cargar en milisegundos y ser perfectamente indexable por Google (SEO).
El panel de administración necesita ser altamente interactivo y responder al instante a cada clic, sin recargas.
La herramienta de edición de fotos en el navegador requiere toda la potencia de ejecución del cliente.

Antes, esto te obligaba a combinar tecnologías diferentes (MVC + React + lo que sea). Con Blazor Web Apps, puedes tener una sola aplicación .NET donde cada sección se comporta de la forma más adecuada.

2. Los 4 modos en un vistazo

No elijas el render mode según «qué tecnología te cae mejor». Elige según el comportamiento que necesita el usuario en esa parte concreta de la app.

Modo	Cuándo usarlo	Cuándo evitarlo
Static SSR	SEO, landing pages, blogs, páginas de contenido	Cualquier cosa que requiera interacción (no hay circuito activo)
Interactive Server	Dashboards, CRMs internos, herramientas de equipo	Aplicaciones con muchísima escala (cada usuario mantiene una conexión SignalR abierta)
Interactive WebAssembly (WASM)	Editores pesados, cálculos intensivos en cliente, apps offline	Primera carga lenta (el navegador debe descargar el runtime de .NET)
Interactive Auto	La mayoría de aplicaciones interactivas modernas	Cuando necesitas control total del entorno o el componente se comporta muy distinto en servidor vs cliente

3. Interactive Auto: La coreografía inteligente entre servidor y cliente

Este es el modo que más confunde al principio, pero también el más poderoso cuando se entiende.

No es magia, es una secuencia muy bien pensada:

Prerender en el servidor: El usuario llega y recibe HTML estático casi instantáneo (como en Static SSR). La percepción de velocidad es excelente.
Interactive Server: Mientras tanto, se establece una conexión SignalR para que el usuario pueda interactuar de inmediato.
Carga de WASM en segundo plano: El navegador descarga silenciosamente los archivos .wasm mientras el usuario navega.
Handoff (traspaso): En la siguiente navegación o recarga, Blazor detecta que ya tiene todo lo necesario y pasa la ejecución completa al cliente.

«Auto no es magia: es una coreografía bien ejecutada entre servidor y cliente.»

Atención con el prerendering: Durante el paso 1, tu componente se ejecuta dos veces: una en el servidor (para generar el HTML inicial) y otra en el cliente (para activar la interactividad).

Esto significa que código con efectos secundarios en OnInitializedAsync() (como llamadas a APIs) puede dispararse dos veces. La solución recomendada es mover esa lógica a OnAfterRenderAsync(firstRender) o deshabilitar el prerendering cuando no sea necesario. Profundizaremos en este comportamiento en el próximo artículo.

4. Aplicando Render Modes con precisión

Blazor te permite ser tan granular como necesites. Puedes definir el modo globalmente en App.razor, pero mi recomendación fuerte es aplicarlo por página o por componente.

Ejemplo en una página específica:

@page "/dashboard"
@rendermode InteractiveServer

La regla de oro: Empieza con una estrategia global simple (Static SSR por defecto) y «rompe la regla» solo donde realmente necesites interactividad. Esto mantiene tu aplicación ligera y escalable.

5. El Ejemplo Real: Task Manager

Para que no quede solo en teoría, construimos una aplicación completa de gestión de tareas que combina varios modos según la necesidad de cada sección.

Registrando servicios: el detalle que suele morder

El secreto está en registrar los servicios de forma que funcionen correctamente en todos los contextos:

// Program.cs (tanto en el proyecto Server como en el Client)
builder.Services.AddSingleton<ITaskService, MockTaskService>();

Cuidado con los lifetimes en servidor: Un Singleton en el proyecto servidor se comparte entre todos los usuarios. Si el servicio maneja estado por usuario (carrito, preferencias, etc.), usa Scoped en el lado servidor. En WASM esto no es problema, porque cada pestaña del navegador es un proceso aislado.

/ (Home) → Static SSR

Página de bienvenida pura. Carga instantánea, sin WebSockets abiertos. Aquí vive el SEO.

@page "/"
<PageTitle>Home</PageTitle>
<h1>Bienvenido al Task Manager</h1>
<p>Esta página se renderiza completamente con Static SSR.</p>

/tasks → Interactive Server

Aquí gestionas las tareas: crearlas, marcarlas como completadas, etc. Todo se procesa en el servidor con respuesta inmediata gracias a SignalR.

@page "/tasks"
@rendermode InteractiveServer
@inject ITaskService TaskService

<!-- lógica de la lista de tareas -->

/analytics → Interactive Auto

Sección de métricas y gráficos. Este componente vive en el proyecto .Client. La primera visita recibe HTML del servidor, mientras WASM se descarga en segundo plano. En visitas posteriores, todo corre directamente en el cliente sin cargar el servidor.

@page "/analytics"
@rendermode InteractiveAuto
@inject ITaskService TaskService

<div class="progress">
    <div class="progress-bar" style="width: @percentage%;">@percentage%</div>
</div>

@code {
    private List<TaskItem> tasks = new();
    private double percentage;

    protected override async Task OnInitializedAsync()
    {
        tasks = await TaskService.GetTasksAsync();
        var completed = tasks.Count(t => t.IsCompleted);
        percentage = tasks.Count > 0 
            ? Math.Round((double)completed / tasks.Count * 100, 1) 
            : 0;
    }
}

La elección correcta existe, y depende de tu caso

Elegir el Render Mode correcto es el primer gran paso hacia una aplicación Blazor que sea rápida, escalable y agradable de usar. La tabla que vimos antes te servirá como referencia rápida, pero la regla práctica más útil es esta:

Empieza siempre con Static SSR y añade interactividad solo donde el usuario realmente la necesita.

Cuando combinas varios modos en una misma aplicación aparece un problema sutil pero importante: el estado puede «desaparecer» entre contextos, y algunos componentes se ejecutan más veces de las que esperas (como vimos con el prerendering en Auto).

En el próximo artículo vamos a profundizar exactamente en eso: por qué tu componente parece ejecutarse dos veces y cómo manejar el estado y el ciclo de vida cuando mezclas estos mundos sin que tu aplicación se rompa.

Mientras tanto, puedes explorar el proyecto completo que usamos como ejemplo aquí: TaskManagerApp en GitHub

¿Estás trabajando en un proyecto Blazor Web App actualmente? ¿Qué render mode estás usando más? Cuéntame en los comentarios, seguro que entre todos podemos compartir trucos útiles.