Shrink blazor.*.js file size, SignalR Minification

[TanayParikh]

@BrennanConroy mentioned:

SignalR mangles properties with the _ prefix so the compiler can reduce property names to single or double characters in the output, but it looks like blazor consumes SignalR from source, or from a non-mangled build. Also, blazor could add the _prefix and convert any private properties to get some savings. You can do that by adding this to the optimization section of webpack.config.js

aspnetcore/src/SignalR/clients/ts/webpack.config.base.js

Line 96 in 711bdcf

regex: /^_/

This issue tracks this effort to ensure we're minifying the SignalR bits. Not sure if we'll be able to take this for 6.0 given the current stage of the release, but will dig into it once I have some time available.

[TanayParikh]

Tried this out via #42268, this doesn't seem to be immediately feasible just by mangling alone as it causes issues with Blazor._internal which is an internal type for Blazor, but we cannot let it get mangled as it's called into from .NET via JS interop.

This issue breaks down into two parts. Mangling the blazor source code, and ensuring the SignalR code we take is/becomes mangled.

The former will likely be a larger undertaking and with fairly low benefit. For instance take a look at the WASM/WebView size improvements below.

File	Current Size	Optimized Size
blazor.server.js	130 kb	122 kb
blazor.webassembly.js	60 kb	59 kb
blazor.webview.js	40.5 kb	39.8 kb

The blazor.server.js improvement is relatively larger than WASM/WebView, on account of mangling the SignalR code.

Next steps for this issue would be to figure out how we can either take the existing mangled SignalR code instead of the source code we're taking now, or how we can mangle just the SignalR code without touching the Blazor code.

I'm pushing this back into backlog at this point in time.

[ghost]

We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.

[BrennanConroy]

If _internal is the only thing that shouldn't be mangled, you can exclude it https://github.com/terser/terser#cli-mangle-options

[TanayParikh]

Not seeing any other Blazor._* usage other than Blazor._internal.

So tried that out, but still ran into other issues:

Uncaught (in promise) Error: System.ArgumentException: Property 'AssemblyName' cannot be null, empty, or whitespace. (Parameter 'assemblyKey') at Microsoft.JSInterop.Infrastructure.DotNetDispatcher.GetCachedMethodInfo(/AssemblyKey assembl…ng methodIdentifier) in /workspaces/aspnetcore/src/JSInterop/Microsoft.JSInterop/src/Infrastructure/DotNetDispatcher.cs:line 355 at Microsoft.JSInterop.Infrastructure.DotNetDispatcher.InvokeSynchronously(/JSRuntime jsRuntime…ce, String argsJson) in /workspaces/aspnetcore/src/JSInterop/Microsoft.JSInterop/src/Infrastructure/DotNetDispatcher.cs:line 167 at Microsoft.JSInterop.Infrastructure.DotNetDispatcher.BeginInvokeDotNet(/JSRuntime jsRuntime…fo, String argsJson) in /workspaces/aspnetcore/src/JSInterop/Microsoft.JSInterop/src/Infrastructure/DotNetDispatcher.cs:line 97 at Te.endInvokeDotNetFromJS (Microsoft.JSInterop.js:319:19) at Te.be (HubConnection.js:542:31) at Te.Wt (HubConnection.js:407:30) at Te.connection.onreceive (HubConnection.js:42:52) at s.onmessage (WebSocketTransport.js:81:30)

	endInvokeDotNetFromJS	@	Microsoft.JSInterop.js:319
	be	@	HubConnection.js:542
	Wt	@	HubConnection.js:407
	Te.connection.onreceive	@	HubConnection.js:42
	s.onmessage	@	WebSocketTransport.js:81

Loggers.ts:38

---

asset blazor.server.js 122 KiB [emitted] [minimized] [big] (name: blazor.server)
asset blazor.webassembly.js 59.2 KiB [emitted] [minimized] (name: blazor.webassembly)
asset blazor.webview.js 39.8 KiB [emitted] [minimized] (name: blazor.webview)
orphan modules 452 KiB [orphan] 93 modules
runtime modules 221 bytes 1 module
cacheable modules 736 KiB
./Boot.Server.ts + 72 modules 390 KiB [built] [code generated]
./Boot.WebAssembly.ts + 31 modules 200 KiB [built] [code generated]
./Boot.WebView.ts + 28 modules 146 KiB [built] [code generated]

With further tweaking, improvements in this area should definitely be possible, but based on the preliminary numbers, I don't think they are high enough relative to the overall download size to make a substantial difference in load times. We can likely revisit this later as time permits.

[ghost]

We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.