Comment Blazor se comporte par rapport à d'autres cadres

Nous utiliserons Blazor Server, Blazor WebAssembly et une application ASP.NET Core MVC pour comparer les performances, en examinant l'activité du réseau pour la mesurer par rapport au nombre de requêtes HTTP et au temps de chargement total.

Les performances sont un facteur clé lorsque choisir un cadre d'application Web. Voici quelques facteurs de performances clés à surveiller:

• Nombre de requêtes HTTP
• Taille de chaque requête HTTP
• Temps de chargement total

Nous verrons comment Blazor fonctionne en tant que framework d'application Web. Nous utiliserons ASP.NET Core MVC, Blazor Server et Blazor WebAssembly et créerons des applications similaires dans ces frameworks pour comparer les performances.

The Experiment

Nous avons créé un exemple de blog contenant 10 000 articles. Les articles sont classés en quatre catégories, chaque article ayant une ou plusieurs catégories. Deux de ces catégories sont nommées .NET et SQL Server, et c'est ce que nous utiliserons pour notre expérience.

Pour rendre cela aussi précis et équitable que possible, chaque application Web chargera 10 articles de notre catégorie .NET à l'initialisation. Par la suite, nous cliquons sur un lien qui chargera 10 articles de notre catégorie SQL Server.

Chaque application appellera la même fonction et utilisera la même base de données pour récupérer les articles. La fonction utilisera Entity Framework Core pour renvoyer ces articles de la base de données à l'application.

Enfin, il faut noter que les applications Web et la base de données se trouveront sur localhost.

ASP.NET Core MVC Application [19659013] Tout d'abord, nous allons exécuter une application ASP.NET Core MVC pour voir à quoi Blazor est confronté. Voici l'activité réseau lorsque l'application récupère les articles de la catégorie .NET.

En plus du chargement du document HTML, le l'application a également chargé les fichiers CSS nécessaires pour styliser l'application. En termes de temps de chargement, il a fallu un peu moins de 2,8 secondes pour charger complètement la page.

Maintenant, nous allons charger les articles de notre catégorie SQL Server et voir comment cela se compare.

Comme vous vous en doutez, le temps de chargement du document HTML est nettement plus rapide. L’application a déjà été initialisée, il ne s’agit donc que de récupérer les articles. De plus, l'application a chargé les mêmes fichiers CSS, mais elle a récupéré des copies mises en cache des fichiers. Dans l'ensemble, le chargement de cette page a pris un peu plus de 150 millisecondes, bien plus rapidement que lors de l'initialisation de l'application.

Application Blazor Server

Il est maintenant temps pour Blazor Server de montrer ses performances. L'application nécessite plus de requêtes HTTP que l'application ASP.NET Core MVC lors de sa première initialisation, comme le montre cette activité réseau.

Là est une augmentation de huit requêtes HTTP par rapport à cinq par rapport à l'application ASP.NET Core MVC. Blazor Server doit établir une connexion Websocket afin que le navigateur et le serveur puissent communiquer entre eux, d'où l'augmentation.

En outre, le temps de chargement est légèrement plus long que l'application ASP.NET Core MVC. Vous pouvez voir qu'il faut près de trois secondes pour charger le document HTML. Le chargement de la connexion Websocket prend également plus de temps.

Mais, avec toutes les activités qui se produisent lors de l'initialisation, cela nécessitera moins de travail lorsque nous cliquons sur la catégorie SQL Server?

Eh bien, la réponse est oui, comme vous peut voir l'activité réseau ci-dessous.

Pour une raison quelconque, il a décidé de charger un fichier de police, mais c'est la seule requête HTTP a fait. Tout transfert de données s'effectue via notre connexion websocket, ce qui signifie que nous n'avons pas à faire de requêtes HTTP supplémentaires pour mettre à jour nos données. Cela entraînera non seulement une diminution significative du temps de chargement, mais également de la quantité de bande passante utilisée.

Il est difficile d’obtenir une synchronisation précise du temps de chargement des articles. En effet, l’activité réseau montre que le websocket fournit une connexion constante entre le navigateur et le serveur. Donc, pour contourner cela, j'ai utilisé la classe Stopwatch dans .NET pour mesurer le temps de chargement. Il a fallu 167 millisecondes pour charger les articles, ce qui est légèrement plus long que l'application ASP.NET Core.

Application Blazor WebAssembly

Notre dernière expérience est avec Blazor WebAssembly. Maintenant, Blazor WebAssembly est différent en ce que nous avons deux applications. Un pour alimenter l'application Blazor WebAssembly et un pour alimenter l'API. Pour l'API, nous avons créé une application API ASP.NET Core MVC. L'API sera utilisée pour récupérer les articles de chaque catégorie.

Voici l'activité du réseau lors de la première initialisation de l'application.

Maintenant c'est beaucoup de requêtes HTTP! Blazor WebAssembly télécharge les DLL dans le navigateur pour exécuter l'application. Le chargement de chaque DLL peut prendre plus de 500 millisecondes. De plus, le renvoi d'une réponse de l'API peut prendre plus de deux secondes.

Ensuite, il est temps de charger nos articles de catégorie SQL Server pour voir si l'activité réseau est meilleure.

La seule chose qui a changé sur la page est les données de l'article. En conséquence, le nombre de requêtes HTTP a considérablement diminué comme vous vous en doutez. En outre, l'API prend moins de 60 millisecondes pour obtenir les articles mis à jour, ce qui le rend plus rapide que l'application ASP.NET Core et l'application Blazor Server.

Ce que nous pouvons apprendre de ces résultats

Il semble que Blazor WebAssembly a beaucoup d'activité lors de son initialisation. Il existe un plus grand nombre de requêtes HTTP, ce qui augmente le temps d'initialisation. Cependant, lorsque vous effectuez un clic sur un lien, il suffit d'appeler l'API pour récupérer une liste d'articles mis à jour, ce qui en fait la plus rapide des trois applications.

Blazor Server nécessite beaucoup moins de requêtes HTTP lors de son initialisation. Cependant, cela prend un peu plus de temps que Blazor WebAssembly dans le sens de la récupération d'une liste d'articles mise à jour lors de l'exécution de clics sur les liens.

L'application ASP.NET Core MVC a le plus petit nombre de requêtes HTTP lors de l'initialisation, mais elle doit rechargez ces requêtes HTTP lors de l'exécution de clics sur les liens. Cependant, il utilise la mise en cache lors du rechargement des requêtes HTTP qu'il a précédemment chargées.

Désormais, ce test ne prend pas en compte les performances d'une application si elle était exposée à de gros volumes de trafic. Si vous vous attendez à ce que votre application reçoive de gros volumes de trafic, vous souhaiterez peut-être emprunter la route ASP.NET Core MVC. Le modèle de conception MVC existe depuis beaucoup plus longtemps que Blazor, vous vous attendez donc à ce que Microsoft ait perfectionné ses performances.

Cependant, cela ne veut pas dire que Blazor ne serait pas en mesure de faire face à de gros volumes de trafic. Blazor prend beaucoup plus de temps lors de l'initialisation, mais les performances sont assez cohérentes pour les trois applications lors de l'exécution de clics sur les liens. Blazor a l'avantage de ne pas avoir à recharger la page chaque fois qu'un clic sur un lien est effectué. Cela rendra les choses plus rapides pour l'utilisateur final.

Donc, si vous souhaitez montrer les capacités de ce qu'une application Web peut faire, Blazor serait un très bon choix.