Guía práctica de decisiones de Blazor
Blazor: ¿servidor, WebAssembly o híbrido?
Blazor es útil cuando sabes qué trabajo permanece en el servidor, qué trabajo se mueve al navegador y qué URL deben existir como enlaces HTML reales.
Esta guía omite la versión del folleto. Se centra en las compensaciones que suelen sorprender a los equipos más adelante: memoria del servidor, conexiones en vivo, latencia, tamaño de la carga útil, SEO y enrutamiento multilingüe.
Antes de la elección del modo de renderizado
Qué es Blazor en realidad
Blazor es el marco de componentes de Microsoft para aplicaciones web .NET. Usted construye la interfaz de usuario a partir de componentes de Razor, escribe la mayor parte de la lógica de interacción en C# y deja que ASP.NET Core represente esos componentes en el servidor, en WebAssembly o dentro de un shell de aplicación nativa.
Surgió de ideas antiguas de ASP.NET. Web Forms intentó ocultar la web detrás de los controles del servidor. MVC y Razor Pages hicieron que el HTML de solicitud-respuesta fuera más limpio. Blazor agrega componentes interactivos reutilizables, pero no hace que MVC o Razor Pages queden obsoletos para formularios y páginas de contenido simple.
Web Forms, MVC y Razor Pages resolvieron diferentes problemas
Web Forms era productivo pero pesado y con estado. MVC y Razor Pages proporcionaron un HTML más limpio y un manejo de solicitudes más sencillo. Siguen siendo buenos cuando una página lee principalmente datos, publica un formulario y devuelve HTML.
Los componentes mantienen la lógica de la interfaz de usuario cerca del marcado
Un componente Razor puede contener marcas, parámetros, eventos, validación, servicios inyectados y estado local. Esto es útil para paneles, editores, asistentes, cuadrículas y herramientas donde la página cambia sin una recarga completa.
El .NET moderno te permite mezclar modos de renderizado
Las aplicaciones Blazor más nuevas pueden combinar HTML estático renderizado en servidor con componentes interactivos. Esto es importante porque una página puede necesitar contenido rastreable, mientras que otra parte necesita un componente activo.
Índice
Empieza aquí
La útil versión corta
Blazor no es una arquitectura. Es un modelo de un componente con varios modos de renderizado. La elección correcta depende menos de la sintaxis y más de dónde se encuentran el estado, la latencia, la memoria y los enlaces rastreables.
Blazor Server tiene estado
Puede parecer rápido en la primera carga, pero el servidor mantiene los circuitos activos. Planifique la memoria, reconecte el comportamiento y escale horizontalmente antes de que aumente el tráfico.
WebAssembly paga por adelantado
Elimina los circuitos del servidor activo, pero la primera visita descarga el tiempo de ejecución y la aplicación. Caché, recorte y renderizado previo son importantes.
Híbrido es una decisión de producto.
Utilice Hybrid cuando la aplicación realmente necesite un shell de escritorio o móvil. Para contenido público, utilice renderizado web y URL reales.
Blazor Server
Blazor Server mantiene vivo el trabajo entre clics
Blazor Server no es una página normal de solicitud y respuesta sin estado. Una pestaña del navegador conectada recibe un circuito. El servidor mantiene el estado de los componentes y los servicios de alcance para ese circuito mientras el usuario está conectado y, a menudo, durante un breve período de reconexión después de una desconexión.
La memoria crece con circuitos activos.
Cada pestaña conectada tiene un circuito. El estado de los componentes, los servicios con alcance, el estado de validación y el trabajo pendiente de la interfaz de usuario pueden permanecer en la memoria hasta que finalice el circuito. Las pruebas de carga deben contar los usuarios activos, no solo las solicitudes por segundo.
La latencia se convierte en parte de la interfaz de usuario
Un clic en un botón, un evento de entrada o una interacción con la cuadrícula pueden viajar al servidor y regresar. Realice el hospedaje cerca de los usuarios y evite los componentes conversadores cuando la audiencia esté repartida por regiones.
El escalamiento horizontal necesita un plan
Varias instancias de aplicaciones a menudo necesitan sesiones fijas, un plano posterior de SignalR, el servicio Azure SignalR o un diseño de estado cuidadoso. De lo contrario, los circuitos activos se vuelven a conectar y pueden aterrizar en la instancia equivocada.
Buen ajuste: usuarios controlados
Blazor Server es más potente para herramientas autenticadas, pantallas de administración, paneles y aplicaciones internas donde se conocen los usuarios, la latencia y la capacidad de alojamiento.
Blazor WebAssembly
WebAssembly traslada el costo a la primera carga
Blazor WebAssembly elimina los circuitos del servidor, pero no elimina el costo. El navegador debe descargar el tiempo de ejecución, los ensamblados, los recursos de localización y los activos de la aplicación .NET antes de que la experiencia se sienta rápida. Las visitas repetidas pueden ser buenas porque el almacenamiento en caché ayuda. Las primeras visitas necesitan atención.
La primera carga es el impuesto.
El navegador descarga el tiempo de ejecución de .NET, los ensamblados de aplicaciones, los recursos y los activos estáticos. Recortar ayuda. La compilación anticipada puede mejorar el trabajo que requiere mucho uso de la CPU, pero a menudo aumenta el tamaño de la descarga.
Los secretos no pueden vivir en el cliente.
Una aplicación WebAssembly se ejecuta en el navegador del usuario. Trátelo como cualquier interfaz pública: mantenga secretos en el servidor, proteja las API y asuma que el código del cliente puede ser inspeccionado.
El SEO necesita contenido renderizado
Para artículos públicos, páginas de productos y páginas de destino, no confíe en un shell en blanco que sólo resulta útil después de que se inicia WebAssembly. Utilice renderizado del lado del servidor, renderizado previo, renderizado estático o una ruta de contenido independiente.
Buena opción: aplicaciones sin conexión o con muchos clientes
WebAssembly funciona bien cuando los usuarios regresan con frecuencia, necesitan un comportamiento fuera de línea o realizan un trabajo pesado del lado del cliente donde un viaje de ida y vuelta al servidor sería peor.
Híbrido y WebView
Híbrido es para aplicaciones, no para páginas de destino públicas
Blazor Hybrid es útil cuando un equipo .NET desea reutilizar componentes dentro de una aplicación móvil o de escritorio. Se ejecuta en un shell nativo a través de WebView, por lo que puede estar cerca de archivos locales, API de dispositivos e implementación empresarial. No es un atajo para sitios web centrados en SEO.
- Utilice Hybrid cuando necesite acceso a archivos locales, API de dispositivos, implementación de escritorio o paquetes móviles.
- No elija Híbrido solo para reutilizar componentes web. El shell nativo agrega trabajo de actualización, almacenamiento, firma y soporte.
- Para SEO y URL públicas que se pueden compartir, Hybrid suele ser la superficie incorrecta.
Enrutamiento multilingüe
Los vínculos culturales deben ser vínculos reales
Un sitio Blazor multilingüe no debe crear navegación de idiomas solo en controladores de clics o JavaScript después de que la página se vuelva interactiva. Los motores de búsqueda y los usuarios necesitan etiquetas de anclaje reales en el HTML inicial, con valores href estables, URL canónicas y datos hreflang.
- Utilice enlaces de páginas centrales y ayudas en lugar de cadenas construidas a mano como la ruta de barra de cultura de barra.
- Represente enlaces de idioma como etiquetas de anclaje con valores href durante la representación HTML inicial.
- Mantenga sincronizadas las URL canónicas, las URL hreflang y la navegación en idiomas visibles.
- Evite ocultar enlaces importantes detrás de controladores onclick, JavaScript retrasado o estado Blazor solo interactivo.
Guía de decisión
Elige según el cuello de botella que aceptes
Cada modo de renderizado mueve la presión a un lugar diferente. Elija la presión que pueda medir, albergar y explicar al equipo.
Cuando la primera carga y la integración del backend .NET son más importantes
Elija Blazor Server para aplicaciones autenticadas controladas donde la memoria del servidor, las conexiones en vivo y la latencia regional sean costos operativos aceptables.
Cuando el trabajo del cliente y el comportamiento fuera de línea son más importantes
Elija WebAssembly cuando las visitas repetidas, el almacenamiento en caché, el uso sin conexión o el trabajo de la CPU local sean más importantes que la primera carga más pequeña.
Cuando el producto es realmente una aplicación nativa
Elija Híbrido cuando la aplicación pertenezca a una computadora de escritorio o móvil y necesite más integración local que alcance web público.
Cuando el sitio se compone principalmente de documentos y formularios.
Las páginas clásicas de ASP.NET Core MVC o Razor Pages suelen ser más sencillas para sitios con mucho contenido, documentación pública y formularios con interactividad limitada.
Sección de referencia
Lea esto a continuación cuando construya esto de verdad.
Estas referencias son útiles después de la decisión de arquitectura, porque cubren las partes que hacen que una página Blazor sea confiable en producción: metadatos, enlaces de idiomas, alojamiento y interfaz de usuario reutilizable.
Úselo cuando cada página necesite un título, descripción, Open Graph, canónico y salida JSON-LD consistentes.
Enlaces culturales optimizados para SEOUtilícelo cuando el enrutamiento multilingüe necesite enlaces rastreables reales, rutas culturales estables y una salida hreflang correcta.
Hospeda Blazor en UpCloudÚselo cuando una aplicación Blazor Server necesite un VPS pequeño, Nginx, TLS, systemd, registros, copias de seguridad e implementaciones repetibles.
TablerForNetÚselo cuando el valor sea una interfaz de administración, tablas de datos, formularios y pantallas de panel en lugar de una página de marketing.
BlazorUtilice el centro de Blazor cuando desee tener las guías relacionadas en un solo lugar antes de elegir el siguiente detalle de implementación.
FAQ
Preguntas frecuentes
Respuestas a preguntas comunes sobre Blazor
¿Por qué Blazor Server puede necesitar más memoria que MVC?
MVC puede finalizar una solicitud y liberar la mayoría de los estados de la solicitud. Blazor Server mantiene un circuito para cada pestaña del navegador conectada, de modo que el estado de los componentes y los servicios con alcance puedan permanecer activos entre clics.
¿Puedo ejecutar Blazor Server en varias instancias de aplicaciones?
Sí, pero planifíquelo deliberadamente. Los circuitos activos y las conexiones de SignalR necesitan un enrutamiento estable, un backplane o un servicio SignalR administrado y un estado de la aplicación que sobreviva a las reconexiones correctas.
¿Blazor WebAssembly puede ser compatible con SEO?
Sí, pero no enviando un caparazón vacío y esperando que el rastreador espere. Las páginas públicas necesitan HTML renderizado, metadatos, enlaces canónicos y datos estructurados antes o durante la primera respuesta.
¿Cómo se deben crear enlaces Blazor multilingües?
Utilice definiciones de ruta centrales y represente etiquetas de anclaje reales para cada cultura. Mantenga alineados los enlaces visibles, las URL canónicas y los datos hreflang para que los usuarios y los rastreadores vean la misma estructura de lenguaje.