Guide de décision pratique Blazor
Blazor : serveur, WebAssembly ou hybride ?
Blazor est utile lorsque vous savez quel travail reste sur le serveur, quel travail est transféré dans le navigateur et quelles URL doivent exister en tant que véritables liens HTML.
Ce guide ignore la version brochure. Il se concentre sur les compromis qui surprennent généralement les équipes plus tard : mémoire du serveur, connexions en direct, latence, taille de la charge utile, référencement et routage multilingue.
Avant le choix du mode de rendu
Qu'est-ce que Blazor est réellement
Blazor est le framework de composants de Microsoft pour les applications Web .NET. Vous créez l'interface utilisateur à partir des composants Razor, écrivez la plupart des logiques d'interaction en C# et laissez ASP.NET Core restituer ces composants sur le serveur, dans WebAssembly ou dans un shell d'application natif.
Il est né d’anciennes idées ASP.NET. Web Forms a tenté de cacher le Web derrière les contrôles du serveur. MVC et Razor Pages ont créé un nettoyeur HTML de requête-réponse. Blazor ajoute des composants interactifs réutilisables, mais cela ne rend pas MVC ou Razor Pages obsolètes pour les pages de contenu et les formulaires simples.
Web Forms, MVC et Razor Pages ont résolu différents problèmes
Web Forms était productif mais lourd et dynamique. MVC et Razor Pages ont fourni un HTML plus propre et une gestion des requêtes plus simple. Ils sont toujours utiles lorsqu'une page lit principalement des données, publie un formulaire et renvoie du HTML.
Les composants maintiennent la logique de l'interface utilisateur proche du balisage
Un composant Razor peut contenir du balisage, des paramètres, des événements, une validation, des services injectés et un état local. Ceci est utile pour les tableaux de bord, les éditeurs, les assistants, les grilles et les outils dans lesquels la page change sans rechargement complet.
Modern .NET vous permet de mélanger les modes de rendu
Les applications Blazor les plus récentes peuvent combiner du HTML statique rendu par le serveur avec des composants interactifs. Cela est important car une page peut nécessiter un contenu explorable, tandis qu'une autre partie a besoin d'un composant en direct.
Table des matières
Commencez ici
La version courte utile
Blazor n'est pas une architecture. Il s'agit d'un modèle à composant unique avec plusieurs modes de rendu. Le bon choix dépend moins de la syntaxe que de l’endroit où se trouvent l’état, la latence, la mémoire et les liens explorables.
Blazor Server est avec état
Cela peut sembler rapide au premier chargement, mais le serveur maintient les circuits en direct. Planifiez la mémoire, le comportement de reconnexion et la mise à l'échelle avant que le trafic n'augmente.
WebAssembly paie d'avance
Il supprime les circuits de serveur en direct, mais la première visite télécharge le runtime et l'application. Le cache, le découpage et le pré-rendu sont importants.
L'hybride est une décision de produit
Utilisez Hybrid lorsque l’application a vraiment besoin d’un shell de bureau ou mobile. Pour le contenu public, utilisez le rendu Web et de vraies URL.
Blazor Server
Blazor Server maintient le travail en vie entre les clics
Blazor Server n'est pas une page de demande-réponse sans état normale. Un onglet de navigateur connecté obtient un circuit. Le serveur conserve l'état des composants et les services étendus pour ce circuit pendant que l'utilisateur est connecté, et souvent pendant une courte fenêtre de reconnexion après une déconnexion.
La mémoire grandit avec les circuits actifs
Chaque onglet connecté possède un circuit. L’état des composants, les services délimités, l’état de validation et le travail en attente de l’interface utilisateur peuvent rester en mémoire jusqu’à la fin du circuit. Les tests de charge doivent compter les utilisateurs actifs, pas seulement les requêtes par seconde.
La latence devient une partie de l'interface utilisateur
Un clic sur un bouton, un événement d'entrée ou une interaction avec une grille peuvent se déplacer vers le serveur et revenir. Hébergez à proximité des utilisateurs et évitez les composants bavards lorsque le public est réparti dans plusieurs régions.
La mise à l'échelle nécessite un plan
Plusieurs instances d’application nécessitent souvent des sessions persistantes, un fond de panier SignalR, un service Azure SignalR ou une conception d’état minutieuse. Sinon, les reconnexions et les circuits sous tension peuvent atterrir sur la mauvaise instance.
Bon ajustement : utilisateurs contrôlés
Blazor Server est le plus puissant pour les outils authentifiés, les écrans d'administration, les tableaux de bord et les applications internes où les utilisateurs, la latence et la capacité d'hébergement sont connus.
Blazor WebAssembly
WebAssembly déplace le coût vers le premier chargement
Blazor WebAssembly supprime les circuits de serveur, mais cela ne supprime pas les coûts. Le navigateur doit télécharger le runtime .NET, les assemblys, les ressources de localisation et les ressources de l'application pour que l'expérience soit rapide. Les visites répétées peuvent être utiles car la mise en cache est utile. Les premières visites nécessitent des soins.
Le premier chargement est la taxe
Le navigateur télécharge le runtime .NET, les assemblys d’applications, les ressources et les ressources statiques. La coupe aide. La compilation à l'avance peut améliorer les travaux gourmands en CPU, mais augmente souvent la taille du téléchargement.
Les secrets ne peuvent pas vivre chez le client
Une application WebAssembly s'exécute dans le navigateur de l'utilisateur. Traitez-le comme n'importe quelle interface publique : gardez les secrets sur le serveur, protégez les API et supposez que le code client peut être inspecté.
Le référencement a besoin de contenu rendu
Pour les articles publics, les pages de produits et les pages de destination, ne comptez pas sur un shell vierge qui ne devient utile qu'après le démarrage de WebAssembly. Utilisez le rendu côté serveur, le prérendu, le rendu statique ou un chemin de contenu distinct.
Bon ajustement : applications hors ligne ou gourmandes en clients
WebAssembly fonctionne bien lorsque les utilisateurs reviennent souvent, ont besoin d'un comportement hors ligne ou effectuent un travail lourd côté client où un aller-retour du serveur serait pire.
Hybride et WebView
L'hybride est destiné aux applications, pas aux pages de destination publiques
Blazor Hybrid est utile lorsqu'une équipe .NET souhaite réutiliser des composants dans une application de bureau ou mobile. Il s'exécute dans un shell natif via une WebView, ce qui lui permet d'être proche des fichiers locaux, des API de périphérique et du déploiement d'entreprise. Ce n'est pas un raccourci pour les sites Web axés sur le référencement.
- Utilisez Hybrid lorsque vous avez besoin d’accéder à des fichiers locaux, aux API d’appareil, à un déploiement de bureau ou à un package mobile.
- Ne choisissez pas Hybride uniquement pour réutiliser les composants Web. Le shell natif ajoute des travaux de mise à jour, de stockage, de signature et de support.
- Pour le référencement et les URL publiques partageables, l’hybride n’est généralement pas la bonne surface.
Routage multilingue
Les liens sensibles à la culture doivent être de vrais liens
Un site Blazor multilingue ne doit pas créer une navigation linguistique uniquement dans les gestionnaires de clics ou JavaScript une fois que la page est devenue interactive. Les moteurs de recherche et les utilisateurs ont besoin de véritables balises d'ancrage dans le code HTML initial, avec des valeurs href stables, des URL canoniques et des données hreflang.
- Utilisez des liens de page centrale et des assistants au lieu de chaînes construites à la main comme le chemin slash de la culture slash.
- Afficher les liens de langue sous forme de balises d'ancrage avec des valeurs href lors du rendu HTML initial.
- Synchronisez les URL canoniques, les URL hreflang et la navigation dans la langue visible.
- Évitez de cacher les liens importants derrière les gestionnaires onclick, le JavaScript retardé ou l'état Blazor interactif uniquement.
Guide de décision
Choisissez en fonction du goulot d'étranglement que vous acceptez
Chaque mode de rendu déplace la pression vers un endroit différent. Choisissez la pression que vous pouvez mesurer, héberger et expliquer à l'équipe.
Quand le premier chargement et l’intégration back-end .NET sont les plus importants
Choisissez Blazor Server pour les applications authentifiées contrôlées où la mémoire du serveur, les connexions en direct et la latence régionale constituent des coûts d'exploitation acceptables.
Quand le travail des clients et leur comportement hors ligne comptent le plus
Choisissez WebAssembly lorsque les visites répétées, la mise en cache, l'utilisation hors ligne ou le travail du processeur local sont plus importants que le plus petit premier chargement.
Quand le produit est vraiment une application native
Choisissez Hybride lorsque l’application appartient à un ordinateur de bureau ou à un mobile et nécessite davantage une intégration locale qu’une portée Web publique.
Quand le site est majoritairement constitué de documents et de formulaires
Les pages ASP.NET Core MVC ou Razor classiques sont souvent plus simples pour les sites riches en contenu, la documentation publique et les formulaires à interactivité limitée.
Section de référence
Lisez-les ensuite lorsque vous construirez cela pour de vrai
Ces références sont utiles après la décision d'architecture, car elles couvrent les éléments qui rendent une page Blazor fiable en production : métadonnées, liens linguistiques, hébergement et interface utilisateur réutilisable.
Utilisez-le lorsque chaque page nécessite un titre, une description, une sortie Open Graph, canonique et JSON-LD cohérents.
Liens langue-région SEO-friendlyUtilisez-le lorsque le routage multilingue nécessite de véritables liens explorables, des chemins de culture stables et une sortie hreflang correcte.
Hébergez Blazor sur UpCloudUtilisez-le lorsqu'une application Blazor Server a besoin d'un petit VPS, Nginx, TLS, systemd, de journaux, de sauvegardes et de déploiements reproductibles.
TablerForNetUtilisez-le lorsque la valeur est une interface d'administration, des tableaux de données, des formulaires et des écrans de tableau de bord au lieu d'une page marketing.
BlazorUtilisez le hub Blazor lorsque vous souhaitez que les guides associés se trouvent au même endroit avant de choisir le détail d'implémentation suivant.
Questions fréquentes
Pourquoi Blazor Server peut-il avoir besoin de plus de mémoire que MVC ?
MVC peut terminer une requête et libérer la plupart des états de requête. Blazor Server conserve un circuit pour chaque onglet de navigateur connecté, afin que l'état des composants et les services étendus puissent rester en vie entre les clics.
Puis-je exécuter Blazor Server sur plusieurs instances d’application ?
Oui, mais planifiez-le délibérément. Les circuits sous tension et les connexions SignalR nécessitent un routage stable, un fond de panier ou un service SignalR géré et un état d'application qui survit correctement aux reconnexions.
Blazor WebAssembly peut-il être optimisé pour le référencement ?
Oui, mais pas en expédiant une coquille vide et en espérant que le robot attende. Les pages publiques nécessitent un rendu HTML, des métadonnées, des liens canoniques et des données structurées avant ou pendant la première réponse.
Comment créer des liens Blazor multilingues ?
Utilisez des définitions d'itinéraire centrales et affichez de véritables balises d'ancrage pour chaque culture. Gardez les liens visibles, les URL canoniques et les données hreflang alignées afin que les utilisateurs et les robots d'exploration voient la même structure linguistique.