Disabling Blazor Prerendering Cuts Server Load on ARM

by

Summary

During the development of an embedded application on Linux/ARM, a performance bottleneck was identified where the backend CPU load remained unexpectedly high despite selecting WebAssembly (WASM) render mode. The core issue stems from a misunderstanding of Blazor’s default prerendering behavior in .NET 8/9. Even when the intended target is client-side execution, the server performs an initial SSR (Server-Side Rendering) pass to generate the static HTML for the first paint. This results in double-execution of logic: once on the server to render the initial state, and once on the client via WASM to establish interactivity.

Root Cause

The root cause is the Prerendering Mechanism enabled by default in modern Blazor web apps.

  • Dual-Execution Lifecycle: When a page is requested, the server executes the component’s OnInitializedAsync and other lifecycle methods to produce a static HTML snapshot.
  • Dependency Injection (DI) Overhead: Because the server performs this initial render, all services required by the component must be registered in the server-side DI container, even if they are only intended for client-side use.
  • Resource Contention: On resource-constrained ARM hardware, the overhead of spinning up a runtime environment to perform SSR for every initial connection competes with the primary application logic.
  • False Efficiency: The developer assumed WASM mode meant “zero server-side logic,” but the “Prerender” phase creates a server-side compute spike upon every initial page load or hard refresh.

Why This Happens in Real Systems

In production environments, frameworks prioritize LCP (Largest Contentful Paint) and SEO (Search Engine Optimization).

  • User Experience vs. Server Load: Prerendering allows the user to see content immediately without waiting for the large WASM runtime to download and initialize. This creates a “fast” perception.
  • The “Hydration” Gap: There is a period between the static HTML appearing and the WASM runtime taking over. During this gap, the page is visible but non-interactive.
  • Abstraction Leakage: Frameworks often hide the complexity of the rendering pipeline. Developers assume a “Render Mode” is a binary switch (Server vs. Client), whereas it is actually a multi-stage lifecycle involving both.

Real-World Impact

  • CPU Exhaustion: On embedded systems, the burst of CPU activity required for SSR can cause latency spikes in other critical real-time processes.
  • Memory Pressure: Running the full .NET backend stack to render static HTML consumes significant RAM, which is often the tightest bottleneck on ARM devices.
  • Increased Complexity: Developers must maintain two sets of service registrations or implement complex logic to determine if code is running on the server or the client.
  • Network Inefficiency: If not managed correctly, the server might attempt to fetch data from local databases or hardware interfaces during the prerender phase that it shouldn’t even access.

Example or Code (if necessary and relevant)

@page "/hardware-status"
@rendermode InteractiveWebAssembly

@inject IHardwareService HardwareService


Status: @status


@code {
    private string status = "Loading...";

    protected override async Task OnInitializedAsync()
    {
        // This code runs TWICE:
        // 1. On the Server (Prerender)
        // 2. On the Client (WASM)
        status = await HardwareService.GetStatusAsync();
    }
}

How Senior Engineers Fix It

To minimize backend load on limited hardware, we apply the Principle of Least Work for the Server.

  • Disable Prerendering: The most direct fix is to explicitly disable prerendering in the component or the global render mode configuration. This forces the client to wait for the WASM download but drops the server CPU load to nearly zero (serving only static files).
  • Conditional Execution: Use checks to ensure heavy logic only runs on the client.
  • Service Abstraction: Implement Interface-based DI where the Server implementation is a “stub” (returning dummy data) and the WASM implementation performs the actual logic/API calls.
  • Static Asset Optimization: Ensure the WASM binaries are compressed (Brotli/Gzip) to minimize the time the client spends in the “loading” state. 
    // Implementation of disabling prerendering to save ARM CPU
@rendermode @(new InteractiveWebAssemblyRenderMode(prerender: false))

Why Juniors Miss It

  • Linear Thinking: Juniors often view “Render Mode” as a single destination. They think: “I chose WASM, therefore it is a client-side app.” They fail to realize the hybrid nature of the initial request.
  • Ignoring the Lifecycle: They focus on the OnInitializedAsync logic but don’t ask, “Where is this code currently executing?”
  • Observing Symptoms, Not Systems: A junior might see high CPU and try to optimize the algorithm inside the method, rather than realizing the entire method is being called twice by design.
  • Dependency Blindness: They may not realize that adding a service to the Program.cs on the server creates a permanent memory/CPU footprint, even if that service is “only for the client.”

Leave a Comment