[Blazor] Serialization optimizations

[javiercn]

There are many places on the stack where we serialize payloads multiple times to/from strings.

• JSInterop
• Root component markers
• Persistent component state

While there are no functional issues with the current approach and performance is acceptable. There is an opportunity for us to reduce memory usage and improve performance on some of these APIs that get called regularly.

We know for a fact that in some cases it has a clear impact, for example in JS interop.

[ScarletKuro]

Worth adding as sub issue dotnet/maui#12767 as it's also related to the IPC serialization for blazor hybrid

[Kebechet]

One area not in the list above: the BlazorWebView render batch transport. #43867 was closed as a duplicate of this issue and was specifically about that path.

IpcSender.ApplyRenderBatch base64-encodes the binary batch into a JSON string, and WebViewIpcReceiver.ts decodes it a byte at a time:

function base64ToArrayBuffer(base64: string): Uint8Array {
  const binaryString = atob(base64);
  const result = new Uint8Array(binaryString.length);
  for (let i = 0; i < binaryString.length; i++) {
    result[i] = binaryString.charCodeAt(i);
  }
  return result;
}

RenderBatchWriter already produces binary and OutOfProcessRenderBatch already takes an ArrayBuffer, so the base64 round trip and this loop are the only text steps in the path.

I measured that loop against Uint8Array.fromBase64() on real devices: iPhone 11 on iOS 26.2 and Pixel 6 on Chrome 152. Nine interleaved A/B repeats per size, medians, iteration counts auto-calibrated, every decode verified byte-identical before timing.

Batch	iPhone 11 loop	fromBase64		Pixel 6 loop	fromBase64
2 KB	7.29 us	0.55 us	13.4x	7.00 us	2.27 us	3.1x
32 KB	109 us	5.55 us	19.7x	117 us	45.5 us	2.6x
128 KB	444 us	22.5 us	19.8x	409 us	121 us	3.4x

The loop runs at roughly the same speed on both phones (280 to 300 MB/s) and its throughput is flat across every size, which is what a per-byte loop that never vectorizes looks like. The whole difference between platforms is in the native implementations: JavaScriptCore reaches 5.6 GB/s, V8 about 1 GB/s.

Being straight about the magnitude, since it argues against overselling this: a typical few-KB batch saves single-digit microseconds, which is invisible next to webview bridge overhead of roughly 1 to 5 ms. A 128 KB batch saves 0.42 ms on the iPhone and 0.29 ms on the Pixel, real but still about 2.5% of a frame. So swapping the loop is a cheap and safe cleanup, not a fix for the gap dotnet/maui#28667 reports (Hybrid 109.6 ms against Blazor Server 82.7 ms on the same benchmark, where Server sends its batches over a network as binary).

Closing that gap needs the batch to stop being text at all. WebView2 has PostSharedBufferToScript (shared memory, presented to script as a real ArrayBuffer) and androidx.webkit has WebMessageCompat with TYPE_ARRAY_BUFFER. iOS has no binary message body type, so the portable option there is a side channel; Dioxus moved its renderer to a binary WebSocket for this reason and reported applying changes in 1/5 the time at 1/2 the latency.

Per-platform capabilities, the benchmark harness, and how Tauri, Dioxus, Electron, Wails and Capacitor handle the same problem: https://gist.github.com/Kebechet/ab72ebdaa0c79e5f5727873d5d2ee52e

Uint8Array.fromBase64() is Stage 4 / ES2026 and needs a fallback for older Android System WebView. Happy to put up a PR for it if that is useful.