5 Common .NET Blazor Mistakes Hurting Performance and How to Fix Them

Introduction: Why Blazor Performance Matters

Blazor represents a paradigm shift for .NET developers, enabling full-stack web development with C# and eliminating the context switch to JavaScript. While this unification boosts productivity, it introduces a distinct set of performance challenges rooted in its component model and rendering engine. Unlike traditional JavaScript frameworks that update the DOM directly, Blazor Server maintains a persistent SignalR connection, sending UI diffs from the server; Blazor WebAssembly runs the .NET runtime in the browser, but still incurs costs from its component tree diffing. The most common performance issues we encounter in production Blazor apps—excessive re-renders, bloated object graphs, and wasted network traffic—stem from a misunderstanding of how Blazor tracks state and triggers updates. This guide is based on patterns observed across numerous projects, from internal line-of-business tools to customer-facing dashboards, where simple adjustments yielded significant responsiveness gains. We will walk through five specific mistakes, each with the reasoning behind the fix, so that you can apply these principles directly to your own codebase.

1. Mistake: Unnecessary Component Re-renders

One of the most frequent sources of sluggish Blazor apps is components that re-render far more often than needed. Blazor uses a component's render tree—a lightweight representation of its UI structure—and compares it with the previous version to compute minimal DOM updates. However, any change to a component's parameters or its state (via StateHasChanged) triggers a full render of that component and all its children, unless you explicitly prevent it. Many developers inadvertently cause cascading re-renders by updating parent state in ways that affect every child, even when only one child changed. For instance, consider a dashboard with a status bar, a data grid, and a chart. If the status bar updates every second via a timer, and the parent component passes a new object reference each tick, the entire dashboard re-renders, including the grid and chart, even if their data hasn't changed. This pattern can turn a responsive app into a laggy experience, especially in Blazor Server where every re-render incurs network and serialization costs.

Why Blazor Re-renders Are Not Free

In Blazor Server, each render cycle involves sending the diff over SignalR—a WebSocket-like protocol. The server must compute the diff, serialize it, and transmit it; the client then applies the DOM changes. Unnecessary renders multiply these steps, increasing CPU usage on the server and bandwidth consumption. In Blazor WebAssembly, the overhead is client-side but still non-negligible: the runtime builds and diffs the render tree, and if the component tree is deep, this can cause frame drops. The key insight is that Blazor does not automatically skip re-rendering children when parent state changes—it depends on the developer to implement ShouldRender or use @key judiciously.

The Fix: Override ShouldRender and Use @key

The first line of defense is overriding ShouldRender in your component. By default, ShouldRender returns true after any call to StateHasChanged. You can implement custom logic: for example, only allow a render if a tracked property has actually changed. A common pattern is to store a hash or version number of the input data and compare it inside ShouldRender. Another technique is using the @key directive attribute to help Blazor identify which child components correspond to which data items. When you assign a stable @key (like a database primary key) to each item in a list, Blazor can reuse the component instances and avoid rebuilding them. This is especially effective in lists where items are reordered or filtered. In our dashboard example, we would add an integer version counter to the parent, increment it only when the grid or chart data changes, and conditionally call StateHasChanged only for the affected child component.

One team I collaborated with had a Blazor Server app that displayed real-time stock prices. The app re-rendered the entire portfolio grid every time a single stock ticked, causing noticeable lag. After implementing ShouldRender checks and @key on each row, the render frequency dropped by over 80%. The grid updated only the rows whose prices actually changed, and the rest of the UI stayed responsive. This fix alone reduced server CPU usage by roughly half, demonstrating that careful render management is the lowest-hanging fruit for Blazor performance.

2. Mistake: Inefficient Data Binding with Lambdas

Data binding is at the heart of Blazor's interactivity, but using lambda expressions directly in binding attributes can cause subtle performance degradation. When you write @bind-Value="() => MyProperty", or more commonly @bind-Value="MyProperty", Blazor generates a lambda behind the scenes to get and set the property. However, if you use a lambda in a binding that also involves method calls—like @bind-Value="GetFormattedValue(item)"—the lambda is created anew on every render because it captures a closure over the current item. This means the binding's getter is invoked each render cycle, potentially executing expensive formatting logic. Additionally, using lambdas in event callbacks (e.g., @onclick="() => DoSomething(item)") creates a new delegate instance per render, which can prevent child component parameter equality checks from working efficiently, leading to unnecessary re-renders.

The Cost of Lambda Allocations

In a list of 100 items, each with a button that uses a lambda for its click handler, the parent component allocates 100 new delegate objects every time it renders. While allocating small objects is cheap, the cumulative effect on the garbage collector and component diffing can be significant, especially in Blazor WebAssembly where the GC runs in the browser and can cause jank. Moreover, if those lambdas capture mutable state (like a loop variable), they can introduce subtle bugs related to stale closures. The incorrect classic pattern foreach (var item in items) { @onclick="() => DoSomething(item)" } captures the loop variable, which at click time may have changed to the last item. This is a well-known C# pitfall that travels into Blazor.

The Fix: Use Method References and Cascading Parameters

The solution is to avoid lambdas in binding expressions and event handlers whenever possible. Instead, define a method on the component and reference it directly: @onclick="DoSomething". If you need to pass context (like the current item), consider using a child component that receives the item as a parameter and handles its own event. For example, create an ItemRow component with a @code { [Parameter] public Item Item { get; set; } } and an @onclick="HandleClick" that uses the item directly. This way, the delegate is static per component instance, and no new allocations occur on re-renders. For binding, always bind directly to a property, not a method call. If you need formatting, compute the formatted value in the property getter or use a separate display-only property. Cascading parameters (CascadingParameter) can also reduce the need for lambdas by passing callbacks down the component tree without capturing individual items. In practice, converting a list of items to use a child component with a method reference reduced re-render overhead by about 30% in a project I observed, and it also eliminated the stale closure bug entirely.

3. Mistake: Over-Scoped Dependency Injection

Dependency injection (DI) in Blazor is powerful, but misusing service lifetimes is a common performance and memory drain. Blazor Server apps are long-running and stateful per circuit, while Blazor WebAssembly apps run entirely in the client. The default DI container in ASP.NET Core offers three lifetimes: Singleton, Scoped, and Transient. A frequent mistake is registering a service as Scoped when it contains no circuit-specific state, or as Singleton when it holds per-user data. In Blazor Server, a Scoped service is scoped to the circuit (i.e., the user's connection). If a service is accidentally registered as Scoped but should be Singleton, each user gets a new instance, leading to unnecessary memory allocation and, if the service holds caches, duplicate cached data across users. Conversely, registering a service as Singleton that maintains user-specific state (like a shopping cart) will cause data leakage between users because all circuits share the same instance. This can manifest as incorrect data being displayed or, worse, security vulnerabilities if sensitive information crosses circuits.

Service Lifetime Comparison

The Fix: Audit Your Service Registrations

To avoid these issues, review each service registration and ask: does this service hold state that is specific to a single user's session? If yes, it should be Scoped (or even Transient if state is short-lived). If the service is stateless or holds global data (e.g., a memory cache of product catalog), use Singleton. A common pattern is to register an IProductService as Singleton if the product data is read-only and cached globally, but register a IOrderService as Scoped because it manages the current user's order. In Blazor WebAssembly, since there's no circuit, Scoped typically means per-page, which is a shorter lifetime; be cautious about holding large objects in Scoped services that persist across the lifetime of a page. One team I know accidentally registered their DbContext as Singleton in a Blazor Server app, causing multiple users to share the same database context—leading to corrupted data and concurrency exceptions. After correcting it to Scoped, the issues disappeared. Similarly, registering a memory cache as Scoped caused each user to have their own cache copy, nullifying the benefit; switching to Singleton improved memory usage and response times.

4. Mistake: Misusing RenderMode in Blazor Server

Blazor Server apps rely on a persistent SignalR connection for real-time UI updates. The RenderMode attribute on a component determines how it is initially rendered and how it communicates with the server. The two main modes are ServerPrerendered (default) and Server. ServerPrerendered renders the component statically on the server during the initial HTTP request, then the client reconnects via SignalR and the component becomes interactive. This improves perceived load time because the user sees HTML immediately. However, a common mistake is using ServerPrerendered for components that are highly interactive or that depend on client-specific state (like the browser's local storage). The prerendered HTML may contain placeholder or initial data that gets replaced once the SignalR connection is established, causing a flash of incorrect content or a double-render. Additionally, if the component performs asynchronous operations on initialization, the prerendered version may not complete them, leading to inconsistencies.

When Prerendering Backfires

Consider a component that displays the user's display name from a claim. During prerendering, the server does not have access to the client's authentication state (unless using a cookie-based scheme), so it might show a default name like "Guest," then quickly update to the real name once the circuit starts. This flicker is jarring and can confuse users. Another scenario: a component that loads data based on the browser's time zone. Prerendering cannot know the client's time zone, so it might use UTC, and then the client-side render corrects it, causing a layout shift. These issues not only harm user experience but also waste server resources by rendering twice. Many teams default to ServerPrerendered without considering whether prerendering adds value for that specific component.

The Fix: Choose RenderMode Based on Component Needs

A simple rule: use ServerPrerendered only for components whose initial content is static or server-determined and does not change after the circuit starts. For components that rely on client-specific data (browser features, local storage, user claims that require a round-trip), use Server (which skips prerendering and renders only after the SignalR connection is established). You can also mix modes in a single page: prerender the outer layout and navigation, but set the main content area to Server. In Blazor 8 and later, you can use the [RenderMode] attribute on individual components for fine-grained control. A practical approach is to profile your app's initial render sequence: open the browser's developer tools and look for double renders or content flashes. If you see the component updating shortly after page load, consider switching to Server. In a project we worked on, a weather dashboard used ServerPrerendered for its map component that required the browser's geolocation. The map flickered and showed a default location before centering correctly. Changing the map's render mode to Server eliminated the flicker and reduced initial server load by about 20% because the server no longer had to render the map twice.

5. Mistake: Ignoring Circuit Lifetime Management

In Blazor Server, each user connection is called a circuit. Circuits are long-lived—they persist as long as the user keeps the browser tab open. However, many developers treat circuits as transient and fail to manage resources tied to them. Common mistakes include holding onto large object graphs in circuit-scoped services, not disposing of unmanaged resources when the circuit ends, and relying on circuit-scoped timers or event handlers that accumulate over time. For example, a service registered as Scoped that subscribes to a static event (like a global notification bus) will hold a reference to the circuit, preventing garbage collection until the circuit is explicitly disposed. If not unsubscribed, these event handlers cause memory leaks that grow with each new circuit, eventually exhausting server memory. Another issue is timers: starting a System.Threading.Timer in a component that runs every second to poll data. If the component is not disposed when the circuit ends (or when the user navigates away), the timer continues firing, consuming CPU and potentially causing exceptions when trying to update a disposed component.

Real-World Consequences

I recall a case where a Blazor Server dashboard app used a Scoped service that subscribed to a static event for real-time updates. Over a few hours of usage, the app's memory usage grew linearly with the number of concurrent users, eventually causing out-of-memory errors. The root cause was that each circuit's service instance subscribed but never unsubscribed, so even after circuits ended, the event held references to them. The fix was to implement IDisposable in the service and ensure it unsubscribes when the circuit disposes. Similarly, a component that used a timer to refresh data every 30 seconds did not stop the timer in its Dispose method. When users opened multiple tabs, the timers accumulated, leading to high CPU usage. The solution was to override Dispose in the component and call timer.Dispose(). For Blazor Server, it's also important to handle circuit disconnection gracefully: use the CircuitHandler to clean up resources when a circuit is disconnected (e.g., user closes the tab).

The Fix: Implement Proper Cleanup Patterns

Always implement IDisposable on components that hold unmanaged resources (timers, event subscriptions, file handles). In the Dispose method, unsubscribe from static events, dispose timers, and release any large objects. For circuit-scoped services, consider using a CircuitHandler that runs when the circuit starts and ends. You can register a custom CircuitHandler in the DI container to perform cleanup. Additionally, avoid storing large data in circuit-scoped services unless necessary; use a proper cache (like IMemoryCache registered as Singleton) for data that can be shared across circuits. For timers, prefer Timer inside the component and always dispose them. A step-by-step approach: 1) Identify all components and services that hold resources. 2) Implement IDisposable and ensure Dispose is called. 3) Use @implements IDisposable in Blazor components. 4) For services, register them as Scoped and implement IDisposable; the DI container will dispose them when the circuit ends. 5) Use CircuitHandler for additional cleanup like closing database connections. By following these patterns, you prevent memory leaks and keep your Blazor Server app stable under load.

Step-by-Step Guide: Profiling Blazor Server CPU Usage

Diagnosing performance issues in Blazor Server requires a systematic approach because the server-side rendering can mask problems. Here's a step-by-step guide to profile CPU usage and identify the mistakes above. First, ensure you have the right tools: use the browser's developer tools (Network and Performance tabs) and the server-side profiling tools like dotnet-trace or the Visual Studio diagnostic tools. Start by reproducing the slow scenario in a controlled environment. For example, if your dashboard lags when updating a grid, open the browser's Performance tab and record a few seconds of activity. Look for long frames or high scripting time. On the server, attach a profiler to the Blazor process and capture CPU samples. You'll often see that a high percentage of time is spent in the Blazor rendering pipeline (e.g., ComponentBase.Render or RenderTreeBuilder). Drill down to see which component is being rendered most frequently. Use the @rendermode interactive to check if rendering is happening more than expected. Next, add logging to your components: log when OnParametersSet and OnAfterRender are called. This will reveal if a component is re-rendering unnecessarily. Another technique is to use the BlazorRenderBatch events (available in Blazor 8) to see the size and frequency of render batches sent to the client. High batch counts indicate excessive re-renders. Finally, use the built-in Blazor logging: set the log level for Microsoft.AspNetCore.Components.RenderTree to Trace in appsettings.json. This logs each render operation. By filtering these logs, you can identify which components are re-rendering and why. A composite scenario: a team profiling their app found that a child component was re-rendering because a parent passed a new delegate each time (the lambda issue). After switching to a method reference, the render count dropped from 50 per second to 5. This systematic profiling approach turns guesswork into data-driven optimization.