Blazor WASM PWA

[magiccodingman]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

The default template provided by Blazor WASM PWA has a service worker with this on install code:

const cacheNamePrefix = 'offline-cache-';
const cacheName = `${cacheNamePrefix}${self.assetsManifest.version}`;
const offlineAssetsInclude = [/\.dll$/, /\.pdb$/, /\.wasm/, /\.html/, /\.js$/, /\.json$/, /\.css$/, /\.woff$/, /\.png$/, /\.jpe?g$/, /\.gif$/, /\.ico$/, /\.blat$/, /\.dat$/];
const offlineAssetsExclude = [/^service-worker\.js$/];

async function onInstall(event) {
    console.info('Service worker: Install');

    // Fetch and cache all matching items from the assets manifest
    const assetsRequests = self.assetsManifest.assets
        .filter(asset => offlineAssetsInclude.some(pattern => pattern.test(asset.url)))
        .filter(asset => !offlineAssetsExclude.some(pattern => pattern.test(asset.url)))
        .map(asset => new Request(asset.url, { integrity: asset.hash, cache: 'no-cache' }));
    await caches.open(cacheName).then(cache => cache.addAll(assetsRequests));
}

The issue is that the default template of the csproj doesn't show but does default with:

<BlazorCacheBootResources>true</BlazorCacheBootResources>

This means the "dotnet-resource" cache created by the cache boot resource stores a bunch of framework folder dll's and more, while the service worker creates "offline-cache" cache with identical files.

This caused me a lot of grief for years until I realized this was the issue. The additional 10-20 MB of storage that's cached by the cache boot resource on top of it re-caching the same thing again with the service worker makes the cache not only very large. But it has caused me headache on Safari or other browsers that have very limited browser cache available.

I posted in more detail the issue originally on reddit:
https://www.reddit.com/r/Blazor/comments/1ivnuss/blazor_wasm_pwa_is_doublecaching_by_default_heres/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button

Expected Behavior

There's various solutions I can think of. I developed a solution in full on my app by turning the cache boot resource to false since the service worker handles the issue:

<BlazorCacheBootResources>false</BlazorCacheBootResources>

But by turning this to false, I have had to resolve race condition issues and more when other files try to call "invokeMethodAsync" or other blazor methods prior to the main framework js file from being fully initiated. In which the cache boot resource being independent served it so fast prior that it wasn't an issue beforehand.

The other fix could be making the service worker simply skip the framework files by specifically choosing which ones should not be part of the service workers caching mechanism.

There's answers between both as well. There's a few ways this could be resolved.

Steps To Reproduce

Simply download the default Blazor WASM standalone app with visual studios and choose for the app to be PWA.

After publishing where the published service worker is active. Open the app after it loads/installs. Then open the debug settings with F12 and go to the applications tab. Under Cache storage, you'll be able to note both in the "offline-cache" and the "dotnet-resource" that there will be identical files that was cached in both. Thus doubling the total caching done by the app and taking away preciously needed space as the framework files are not small in the first place.

Exceptions (if any)

No response

.NET Version

9,8,7,6 (all of them)

Anything else?

No response

[javiercn]

@magiccodingman thanks for contacting us.

We are hopefully planning to get rid of the local cache as we now fingerprint everything and can rely on the browser cache.