When it comes to measuring the performance of one platform against another, you can often start a religious war. Some of this is caused by the fact that performance means different things to different people or depending on the tooling, you can get results that promote falsehoods. There are many definitions of web application performance. Every organization should have a documented stance on what performance means to them. Mozilla publishes its opinion, and Google has its own as well. You can see similarities and differences even between these two powerhouses, and that's just one example.
Knowing Your Audience
One of the most critical factors, in my opinion, when it comes to performance analysis is understanding your audience. By knowing your audience, you can start to create an outline of what a well-performing website might look like to them; items to consider include.
- The user's connection speed
- The users' connection reliability
- The type of device utilized (Desktop/Tablet/Mobile)
- The frequency of application access
- The duration of application interaction
By knowing simple metrics, we can better look at the performance wins & losses for a particular platform.
Our Scenario
For this article, I wanted to share some insight from a recent deep-dive that I completed comparing the performance and feasibility of ASP.NET Core MVC vs. Blazor WASM. The client scenario had the following key audience attributes.
- A large percentage of the users can be on slow DSL or Cellular connections
- Connectivity can drop off temporarily due to poor wifi/cellular coverage
- Initial page load time is a concern that users have reported in the past with older technology
- The application will grow very large over time, with thousands of pages being created
For this analysis, we were working on comparing ASP.NET MVC vs. Blazor WASM to find a strategic direction for future development. The team desired to limit Javascript usage, so other SPA-style frameworks such as React, Vue, or otherwise were not part of the analysis.
Our Testing Strategy
We created two similar applications with the above criteria in mind, one with MVC and the other with Blazor. Each application used similar UI structures and a minimal set of application features that would mimic standard user interaction with the application. We would then focus on the single-user performance of each of these applications looking specifically at the following behaviors:
- The total number of HTTP requests needed to complete a common task
- The total amount of data transmitted over the internet to accomplish the task
- The total time spent waiting for processing using two network connections; high-speed (100mbps+), low-speed DSL (5mbps/1mbps).
All tests were completed from production environments with compression enabled, and we followed all Microsoft published best practice documentation to minimize payloads.
The Results
We quickly saw the differences when comparing the two technologies; the table below shows a few key metrics from our testing.
| Platform | # Request | KB Transferred | MB Resources | Total Time (Fast Connection) |
|---|---|---|---|---|
| WASM | 151 | 6,124 | 31.27 | 5.76 seconds |
| MVC | 228 | 600 | 8.2 | 3.45 seconds |
| Advantage WASM (33%) | Advantage MVC (90%) | Advantage MVC (73.7%) | Advantage MVC (40.1%) |
As you can see, the downloaded payload size was more than 400% greater when comparing Blazor WASM to that of MVC. However, it is essential to understand that although these numbers look incredibly poor, they are not necessarily 100% telling. Our test scenario only involved ten interactions with the application; over time, the overhead of the initial application download and the relative performance of Blazor would even out and slightly reduce the gap.
However, for our specific scenario, it was the performance of the initial download, where the WASM payload was 21.2 mb that set the final decision point. On a simulated cellular network, the initial page load time was 27 seconds; on an ATT cellular connection, it took 6.7 seconds, and with the DSL line, it was 9.8 seconds. This contrasted with the MVC load times of < 2 seconds, and then < 1 second for all other installations sealed the deal.
In Summary
I share this story not as a knock on Blazor but as a reminder to all developers of the importance of audience and tool selection. Blazor is excellent, and the end-user experience is pleasant; however, there are limitations on performance that MAY impact your organization. For our project, it did, and we will continue to monitor the great strides that not only come to benefit the Blazor community but all other technology frameworks out there. Your mileage may vary, and I look forward to the next project where Blazor WASM might be an option!