News
Blazor Guru Details Best Performance Practices
Microsoft's point man on the Blazor project -- and basically the creator of the project -- Steve Sanderson, is detailing performance best practices for the web development framework that uses C# instead of JavaScript.
It does that through the use of WebAssembly in the client-side component of the Blazor framework, aptly named Blazor WebAssembly.
Sanderson works on Microsoft's ASP.NET Core team where Blazor lives, and since basically introducing Blazor to the world back in 2017 has worked to further the project with many new innovations (including an experiment in which he replaced Blazor's renderer to render to native Flutter controls).
Among those efforts is the GitHub-based "ASP.NET Core Blazor WebAssembly performance best practices."
The site, maintained in conjunction with Pranav Krishnamoorthy, says:
Blazor WebAssembly is carefully designed and optimized to enable strong performance in almost any realistic application UI scenario. However, producing the best results depends on developers using the right patterns and features. Two aspects to consider are:
- Startup time. Your application needs to transfer a .NET runtime into the browser, so it's important to use features that minimize the application download size.
- Runtime throughput. Your .NET code runs on an interpreter within the WebAssembly runtime, so CPU throughput is limited, and in demanding scenarios you will benefit from optimizing rendering speed.
It goes on to discuss in detail several best practices having to do with:
-
Optimizing rendering speed including:
- Avoid unnecessary rendering of component subtrees
- Virtualization
- Creating lightweight, optimized components
- Don't trigger events too rapidly
-
Optimizing JavaScript interop speed, including:
- Avoid excessively fine-grained calls
- Consider making synchronous calls
- Consider making unmarshalled calls
-
Minimizing application download size, including:
- Intermediate Language (IL) trimming
- Intermediate Language (IL) linking
- Use System.Text.Json
- Lazy load assemblies
- Compression
- Disable unused features
The UK-based developer today (Sept. 30) tweeted about the project:
[Click on image for larger view.] Blazor Performance Tweet (source: Steve Sanderson/Twitter).
The specific technique that he said many people don't know about concerns Defining reusable RenderFragments in code.
It reads in part: "You may be factoring out child components purely as a way of reusing rendering logic. If that's the case, it is still possible to do that even without declaring actual components. For example, in any .razor component's @code block, you can define a RenderFragment that emits UI and can be called from anywhere."
The tip received kudos from several developers and followers of the Blazor guru, including:
Wow & thank you. I love this type of documents. Lot's of info with small practical examples. And you're right, I didn't know I could define reusable RenderFragments in code. I start always without using any component (made by myself) and only refactor it in a separate component
In response to another developer who asked if the tip applied equally to the server-side component -- aptly named Blazor Server -- Sanderson said, "Yes, but not as much because it’s running on the full CoreCLR with JIT, so is way less CPU bound."
The GitHub project has received more than 7,900 stars as of this writing, being forked some 19,800 times.
For more information, Sanderson's own GitHub site is here, while his personal blog is here -- although he tweets more than he blogs, as the most recent blog post was from January, titled "Using gRPC-Web with Blazor WebAssembly."
About the Author
David Ramel is an editor and writer at Converge 360.