Copilot Studio gets faster with .NET 10 WASM

Copilot Studio moved its WebAssembly engine to .NET 10 and gained faster runtime performance.

Microsoft says the Copilot Studio team upgraded its browser-based .NET WebAssembly engine from .NET 8 to .NET 10, and the switch is already in production. The move mattered because Copilot Studio runs C# in the browser, where every millisecond of startup and every byte of download size affects how quickly users can work.

The company also published concrete numbers from the migration: the package grew by about 15%, the first AOT call got about 20% faster, and warm calls improved by about 5%. On the deployment side, .NET 10 removed several bits of custom plumbing the team had built around resource naming and integrity checks.

What changed in the migration

The upgrade itself was boring in the best possible way. According to the .NET Blog, the Copilot Studio team mainly updated the target framework in project files and checked that dependencies were compatible. That is the kind of migration every platform team hopes for: a version bump, a rebuild, and a production rollout without drama.

That simplicity matters because WebAssembly apps can turn into maintenance projects fast. If you have custom scripts around publishing, cache-busting, and integrity validation, each framework update risks another round of brittle fixes. Copilot Studio avoided that trap by moving to the newer defaults in .NET 10.

• The app was already running .NET 8 before the upgrade.
• The new build is now live in production.
• The team kept its existing caching logic on top of the new assets.
• The migration did not require a rewrite of the app architecture.

Automatic fingerprinting removes extra deployment work

The biggest quality-of-life improvement in .NET 10 for WebAssembly is automatic fingerprinting of published assets. In plain English, the build system now bakes a unique identifier into each filename, which helps with cache-busting and integrity checks without extra scripts.

Before this change, Copilot Studio had to read the published manifest, rename files with SHA256 hashes, and pass explicit integrity data from JavaScript when loading resources. With .NET 10, those steps disappear. Resources are imported directly from dotnet.js and the .NET WebAssembly runtime, filenames are fingerprinted automatically, and integrity is validated by the platform.

“Moving an existing .NET 8 WASM application to .NET 10 is largely a matter of updating the target framework in the .csproj files and ensuring all dependencies are compatible with the new version.” — Daniel Roth, Principal Product Manager, Microsoft

That quote is doing a lot of work here. It tells you why this upgrade matters: when the framework absorbs tasks that teams used to script by hand, the app gets easier to ship and easier to keep current.

Microsoft also notes one worker-specific detail that developers should remember. If you load the .NET WASM runtime inside a WebWorker, set dotnetSidecar = true during initialization so the runtime boots correctly in that context.

Why the AOT change matters more than the size hit

The other important .NET 10 change is that WasmStripILAfterAOT is now enabled by default for AOT builds. Once .NET methods are ahead-of-time compiled to WebAssembly, their original IL is no longer needed at runtime, so .NET 10 strips it from the output automatically.

Copilot Studio uses a mixed strategy: a JIT engine gets users interactive quickly, while an AOT engine takes over for heavier work once it is ready. That means the app gets fast startup and strong steady-state execution without forcing users to wait for the whole AOT payload before they can do anything useful.

• On .NET 8, 59 files were shared between the JIT and AOT engines.
• On .NET 10, only 22 files are shared.
• The package grew by about 15% because fewer files can be deduplicated.
• Initial interactivity stays intact because the JIT engine loads first.

The tradeoff is easy to understand. The AOT download gets a bit slower in the background, but users already have a responsive app by then. Microsoft says the AOT payload is around 6% slower to download on a fast LAN, or about 200 ms, and around 17% slower on a 4G connection, or about 5 seconds.

Those numbers are worth reading in context. If your app is used on a desktop with good connectivity, the extra payload is easy to hide. If your users are on mobile networks, the background download becomes more visible, but the app still responds before the AOT engine finishes arriving.

The performance gains are aimed at complex agent workloads

The headline result is performance, and the gains are not tiny. Microsoft says Copilot Studio saw about 20% faster execution on the first call and about 5% faster execution on later calls. The company also says the improvement is most visible in large, complex agents, the kind of workloads where AOT-compiled code does the heaviest lifting.

That detail matters because it explains why the team accepted a slightly larger package. A small size increase is easier to justify when the app is an agent platform, not a static demo. In Copilot Studio’s case, faster execution in the hot path is more valuable than shaving a few megabytes off the package.

For developers building Blazor or other WebAssembly apps, the practical advice is straightforward. Move project targets to net10.0, refresh the Microsoft.AspNetCore.*, Microsoft.Extensions.*, and System.* packages, then remove custom asset renaming and integrity code if you built any. If you AOT compile, you get the new IL stripping behavior automatically.

If you want help with a larger upgrade, Microsoft points to .NET application modernization and its GitHub Copilot-based modernization tooling. For teams with real production WASM apps, that is probably the more useful story than the benchmark itself: .NET 10 is reducing the amount of custom work you need to carry forward release after release.

What this says about WebAssembly on .NET

Copilot Studio’s upgrade is a good signal for anyone shipping serious browser-side .NET code. The framework is getting better at the unglamorous parts of deployment, and those improvements matter just as much as raw speed. When fingerprinting is built in and AOT output is trimmed by default, teams spend less time maintaining glue code and more time improving the app itself.

The next question is whether more teams follow the same path and simplify their WASM packaging before the next release cycle. If you are still maintaining custom hash scripts or manual integrity checks, this article is your cue to test .NET 10 on a staging build and measure the difference for your own app, not someone else’s benchmark.