.NET › Blazor (Server & WebAssembly)

What is the performance implication of JS interop calls in Blazor Server versus Blazor WebAssembly?

Advanced

Answer

In Blazor Server, every JS interop call is a network round-trip over the SignalR connection (browser to server and back), adding real latency proportional to network conditions -- making frequent, chatty JS interop calls a potential performance bottleneck. In Blazor WebAssembly, JS interop happens entirely in-process within the browser (no network hop), making it dramatically faster, though still not free due to the WASM-to-JS marshaling overhead.

// Blazor Server: this call incurs a real network round-trip
await JS.InvokeVoidAsync("updateChart", chartData);  // browser <-> server over SignalR

// Blazor WebAssembly: same call, purely in-browser, no network latency
await JS.InvokeVoidAsync("updateChart", chartData);  // in-process WASM <-> JS marshal

Real-world example A Blazor Server app calling JS interop on every mouse-move event for a drawing feature experiences noticeable lag due to network round-trip overhead on each call, leading the team to switch that specific interactive component to WebAssembly render mode.

Common follow-ups: How would you batch multiple JS interop calls to reduce round-trips?;What is JSImport/JSExport and how does it improve WebAssembly interop performance?

Diagnostics & Performance;SignalR & Real-Time Communication