2x Microsoft MVP, Google Developer Expert, and Twilio Champion who works in DevRel at Microsoft. International speaker, blogger, open source contributor, and approachable developer community advocate.
Location
Milwaukee, WI
Education
Bachelor of Science, Computer Information Systems - Engineering
Thank you @shaijut
- Depending on the hosting model, initial loading speed can vary - that is true. With Blazor Wasm it's very similar to the initial page load speed of other SPAs, such as Angular and React. However, there are optimizations being built out to provide "assembly trimming", pre-rendering, compression, etc. It's only going to get better With Blazor Server, it's much faster. If this is the only issue you have, I'll take that as a success. 😬
Have there been any more recent work on performance? I know it's been a WIP but I've never seen anything really benchmark as slow as Blazor WASM. Some WASM technology is starting to comparable to JavaScript for DOM rendering so I've been wondering if improvements been made.
Rust WASM is 4th(albeit with no framework abstraction, fastest Rust framework is like 30th), Blazor is 2nd to last.
Not that I have any attachment to Rust just that I've heard hype but everything I've seen suggests completely the opposite.
I was trying to profile the realworld demo about 6 months ago: blazor-conduit.netlify.app/
And I got one of the highest scores I'd seen a 99. But then I realized it was because it took so long on the loading screen Chrome Lighthouse that it was done loading right at the start. Things have gotten better since then and I'm getting actual scores in the 30s.
While that is the official listing on codebase.show/projects/realworld I assume there are probably issues with it. Those 2 are just the place that people commonly go to look at JavaScript frameworks. Are there any better performance comparisons?
I write code for a living and maintain a Twitch channel where I host a live coding show called #FritzAndFriends building applications and talking with viewers about software development technology
Location
Valley Forge, PA
Education
BS in Management Sciences and Information Systems from Penn State
2x Microsoft MVP, Google Developer Expert, and Twilio Champion who works in DevRel at Microsoft. International speaker, blogger, open source contributor, and approachable developer community advocate.
Location
Milwaukee, WI
Education
Bachelor of Science, Computer Information Systems - Engineering
I agree with Jeff Fritz, these are dated but to your point Ryan - we should do a better job of actively benchmarking the performance of things like DOM rendering, initial payload, and all of the metrics that Lighthouse offers (first contentful paint, time to interactive, total blocking time, speed index, etc.). I'll ask around, and can only assume that this is something that Steve Sanderson already has on his radar. Thank you
It in no way shape or form even competes with load speed, first render, etc on those frameworks unless you have an incredibly poorly engineered TradSPA(tm).
But don't take my word for it, here's a near-hello-world James Newton-King put together on the latest recently for serialization testing that takes 8-13s to first contentful paint on a fast connection with low latency, even with brotli compression:
For ref: That's 60s on fast 3g, with a whopping 23mb into cache (literally as much as youtube's landing page).
The other thing to note is that there's typically an ~1s gap between the completion of dotnet.wasm download and the actual page render, so the first render after a massive download is another 800-1000ms.
Our performance budget is application-related downloads need to be < 200ms on a 1mbps connection, and first contentful paint should be shortly after that (500ms).
Server side rendering: I can't share how I feel about "just throw a fleet of servers at it and it gets way faster," on this site. We're doing 1M requests/s with dotnet core apis on an EKS setup with just a few small nodes and an Angular application that meet our perf budget. All I see at build/etc is Blazor, blazor, blazor, but it's not a realistic option for anything at this point in time compared to tech that's already standard in the dotnet community.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Thank you @shaijut - Depending on the hosting model, initial loading speed can vary - that is true. With Blazor Wasm it's very similar to the initial page load speed of other SPAs, such as Angular and React. However, there are optimizations being built out to provide "assembly trimming", pre-rendering, compression, etc. It's only going to get better With Blazor Server, it's much faster. If this is the only issue you have, I'll take that as a success. 😬
Have there been any more recent work on performance? I know it's been a WIP but I've never seen anything really benchmark as slow as Blazor WASM. Some WASM technology is starting to comparable to JavaScript for DOM rendering so I've been wondering if improvements been made.
Source: github.com/krausest/js-framework-b...
Current Results: krausest.github.io/js-framework-be...
Rust WASM is 4th(albeit with no framework abstraction, fastest Rust framework is like 30th), Blazor is 2nd to last.
Not that I have any attachment to Rust just that I've heard hype but everything I've seen suggests completely the opposite.
I was trying to profile the realworld demo about 6 months ago:
blazor-conduit.netlify.app/
And I got one of the highest scores I'd seen a 99. But then I realized it was because it took so long on the loading screen Chrome Lighthouse that it was done loading right at the start. Things have gotten better since then and I'm getting actual scores in the 30s.
While that is the official listing on codebase.show/projects/realworld I assume there are probably issues with it. Those 2 are just the place that people commonly go to look at JavaScript frameworks. Are there any better performance comparisons?
Both of the sample apps you link to were written more than a year ago and are not using current versions or even RTM versions of the framework.
Let’s update them to .NET 5 and perhaps even take a look at the numbers in a current .NET 6 preview to see how they perform
I agree with Jeff Fritz, these are dated but to your point Ryan - we should do a better job of actively benchmarking the performance of things like DOM rendering, initial payload, and all of the metrics that Lighthouse offers (first contentful paint, time to interactive, total blocking time, speed index, etc.). I'll ask around, and can only assume that this is something that Steve Sanderson already has on his radar. Thank you
It in no way shape or form even competes with load speed, first render, etc on those frameworks unless you have an incredibly poorly engineered TradSPA(tm).
But don't take my word for it, here's a near-hello-world James Newton-King put together on the latest recently for serialization testing that takes 8-13s to first contentful paint on a fast connection with low latency, even with brotli compression:
grpcblazorperf.azurewebsites.net/
For ref: That's 60s on fast 3g, with a whopping 23mb into cache (literally as much as youtube's landing page).
The other thing to note is that there's typically an ~1s gap between the completion of dotnet.wasm download and the actual page render, so the first render after a massive download is another 800-1000ms.
Our performance budget is application-related downloads need to be < 200ms on a 1mbps connection, and first contentful paint should be shortly after that (500ms).
Server side rendering: I can't share how I feel about "just throw a fleet of servers at it and it gets way faster," on this site. We're doing 1M requests/s with dotnet core apis on an EKS setup with just a few small nodes and an Angular application that meet our perf budget. All I see at build/etc is Blazor, blazor, blazor, but it's not a realistic option for anything at this point in time compared to tech that's already standard in the dotnet community.