Scenario contact: @javiercn
Scenario
This scenario validates a deliberate behavior change, not a bug fix.
When a page contains an InteractiveWebAssembly component, Blazor's ResourcePreloader emits <link rel="preload"> elements in <head> for the WebAssembly framework files. In .NET 10 it did that on every server-rendered response, including the ones served as an enhanced navigation. Two things went wrong as a result: the WebAssembly runtime does not restart on an enhanced navigation, so the hints were redundant after the first page, and the DOM merge added and removed the <link> elements in an unstable order, which made some browsers issue extra preload requests.
In .NET 11 ResourcePreloader emits nothing when the response is an enhanced navigation. Three things are deliberately unchanged, and each is a check in its own right:
- The first page load still emits preload hints.
- A full page reload still emits them.
- Pages without an
InteractiveWebAssembly component never emitted them and still do not.
Minimum build
.NET 11 Preview 7 or later.
Configurations to cover
Only InteractiveWebAssembly is ticked because it is the only render mode that ever emitted these hints. The framework checks for it explicitly, and the check excludes Interactive Auto, so an Auto page produces nothing to observe. Static SSR and Interactive Server pages are still needed in the app, as places to navigate from, but they are not what is being measured.
Also exercise
Published output matters because the preload list is built from static web asset metadata, and published assets are fingerprinted, so the set of URLs differs from a development build.
Setup
Have the same app on .NET 10 and on .NET 11, so you can compare directly. The .NET 10 build is what shows you the hints that used to be emitted; without it you are only confirming an absence.
What to build
Create a Blazor Web App with dotnet new blazor -int Auto, interactivity per page, and add:
| Route |
Render mode |
Why |
/ |
none, statically rendered |
Somewhere to navigate from |
/wasm |
@rendermode InteractiveWebAssembly |
The page that emits preload hints |
/auto |
@rendermode InteractiveAuto |
Control: should emit nothing, before or after |
/server |
@rendermode InteractiveServer |
Control: should emit nothing |
Put links to all four in the nav menu, and keep the interactive components trivial.
You are looking for <link rel="preload"> elements in <head> whose href points at _framework/ files, such as dotnet.js and the .wasm payload. Inspect the live <head> in developer tools rather than the original page source, because enhanced navigation patches the DOM after the fact.
Things to try
Keep the network tab open, and inspect <head> in the elements panel after each step.
- Load
/wasm directly as the first page, and look at the preload links in <head>. They should be there.
- From
/, click the nav link to /wasm. This is the changed behavior.
- Do a full browser reload on
/wasm. The hints should return.
- Navigate
/ to /auto and / to /server, confirming neither produces preload links either way.
- Navigate back and forth between
/ and /wasm several times, counting requests for _framework/ files in the network tab.
- Repeat the whole sequence on .NET 10 and compare.
- Repeat against the published app, where the asset URLs are fingerprinted.
Expected behavior
Preload hints appear on a first load and a full reload, and not on an enhanced navigation, and the WebAssembly app works the same either way.
Must hold
- Loading
/wasm directly emits <link rel="preload"> elements for _framework/ assets in <head>.
- Reaching
/wasm by clicking a nav link emits no such elements.
- A full browser reload of
/wasm emits them again.
/auto and /server emit no WebAssembly preload links, on first load or on navigation.- The WebAssembly component on
/wasm becomes interactive and works when reached by navigation, exactly as when loaded directly. The runtime is not re-fetched on the second and later navigations.
- Navigating between
/ and /wasm repeatedly issues no duplicated requests for _framework/ files, and the count does not grow with each round trip.
- On .NET 10 the same navigation does emit the hints, confirming your setup reproduces the old behavior.
Expected differences between configurations
- Published output uses fingerprinted asset URLs, so the
href values differ from a development build. Whether the hints are present should not.
Evidence to capture
The <head> markup from developer tools in three states: /wasm on first load, /wasm reached by nav link, and /wasm after a full reload. Plus the network tab filtered to _framework/ for a round trip between / and /wasm, on both .NET 10 and .NET 11.
Documentation to use
What to report
Report results using the format described in the validation testing manual. Include link to a repository with the test app.
Scenario contact: @javiercn
Scenario
This scenario validates a deliberate behavior change, not a bug fix.
When a page contains an
InteractiveWebAssemblycomponent, Blazor'sResourcePreloaderemits<link rel="preload">elements in<head>for the WebAssembly framework files. In .NET 10 it did that on every server-rendered response, including the ones served as an enhanced navigation. Two things went wrong as a result: the WebAssembly runtime does not restart on an enhanced navigation, so the hints were redundant after the first page, and the DOM merge added and removed the<link>elements in an unstable order, which made some browsers issue extra preload requests.In .NET 11
ResourcePreloaderemits nothing when the response is an enhanced navigation. Three things are deliberately unchanged, and each is a check in its own right:InteractiveWebAssemblycomponent never emitted them and still do not.Minimum build
.NET 11 Preview 7 or later.
Configurations to cover
Only
InteractiveWebAssemblyis ticked because it is the only render mode that ever emitted these hints. The framework checks for it explicitly, and the check excludes Interactive Auto, so an Auto page produces nothing to observe. Static SSR and Interactive Server pages are still needed in the app, as places to navigate from, but they are not what is being measured.Also exercise
Published output matters because the preload list is built from static web asset metadata, and published assets are fingerprinted, so the set of URLs differs from a development build.
Setup
Have the same app on .NET 10 and on .NET 11, so you can compare directly. The .NET 10 build is what shows you the hints that used to be emitted; without it you are only confirming an absence.
What to build
Create a Blazor Web App with
dotnet new blazor -int Auto, interactivity per page, and add://wasm@rendermode InteractiveWebAssembly/auto@rendermode InteractiveAuto/server@rendermode InteractiveServerPut links to all four in the nav menu, and keep the interactive components trivial.
You are looking for
<link rel="preload">elements in<head>whosehrefpoints at_framework/files, such asdotnet.jsand the.wasmpayload. Inspect the live<head>in developer tools rather than the original page source, because enhanced navigation patches the DOM after the fact.Things to try
Keep the network tab open, and inspect
<head>in the elements panel after each step./wasmdirectly as the first page, and look at the preload links in<head>. They should be there./, click the nav link to/wasm. This is the changed behavior./wasm. The hints should return./to/autoand/to/server, confirming neither produces preload links either way./and/wasmseveral times, counting requests for_framework/files in the network tab.Expected behavior
Preload hints appear on a first load and a full reload, and not on an enhanced navigation, and the WebAssembly app works the same either way.
Must hold
/wasmdirectly emits<link rel="preload">elements for_framework/assets in<head>./wasmby clicking a nav link emits no such elements./wasmemits them again./autoand/serveremit no WebAssembly preload links, on first load or on navigation./wasmbecomes interactive and works when reached by navigation, exactly as when loaded directly. The runtime is not re-fetched on the second and later navigations./and/wasmrepeatedly issues no duplicated requests for_framework/files, and the count does not grow with each round trip.Expected differences between configurations
hrefvalues differ from a development build. Whether the hints are present should not.Evidence to capture
The
<head>markup from developer tools in three states:/wasmon first load,/wasmreached by nav link, and/wasmafter a full reload. Plus the network tab filtered to_framework/for a round trip between/and/wasm, on both .NET 10 and .NET 11.Documentation to use
What to report
Report results using the format described in the validation testing manual. Include link to a repository with the test app.