Server‑Side Blazor on .NET 8 with Azure Static Web Apps: Offline‑First PWA Guide

Why Server‑Side Blazor Meets Offline‑First Demands

Imagine a corporate dashboard that continues to display cached data even when the Wi‑Fi drops at a remote site. Server‑Side Blazor, combined with progressive web app (PWA) techniques, can deliver that reliability while keeping the familiar .NET development model. Unlike client‑side WebAssembly, the server renders UI updates over SignalR, which means the same component logic works both online and offline once the service worker has cached the necessary assets.

Prerequisites and System Requirements

Before you start, make sure you have .NET 8 SDK (released November 2023), Azure CLI version 2.45+, and a GitHub repository for continuous deployment. A minimum of 2 GB RAM and a modern browser that supports service workers (Chrome 80+, Edge 80+, Firefox 72+) are required for testing. Azure Static Web Apps offers a free tier that includes up to 100 GB bandwidth per month, which is sufficient for most proof‑of‑concept projects.

Creating a .NET 8 Server‑Side Blazor Project

Open a terminal, navigate to your development folder, and run the template command. The --framework net8.0 flag ensures the project targets the latest runtime, giving you access to minimal APIs and improved performance counters.

dotnet new blazorserver -o BlazorOfflineApp --framework net8.0

After the scaffold finishes, restore packages and launch the app locally with dotnet run. You should see the default counter page at https://localhost:5001, confirming the server‑side rendering pipeline works.

Configuring the App as a Progressive Web App

To turn the Blazor server app into an offline‑first PWA, add a manifest file and register a service worker. Place manifest.json in the wwwroot folder and reference it from _Host.cshtml.

<!-- wwwroot/manifest.json --> { "name": "Blazor Offline App", "short_name": "BlazorPWA", "start_url": ".", "display": "standalone", "background_color": "#ffffff", "theme_color": "#0d6efd", "icons": [ { "src": "icon-192.png", "sizes": "192x192", "type": "image/png" }, { "src": "icon-512.png", "sizes": "512x512", "type": "image/png" } ] }

Next, create service-worker.js that caches static files and the Blazor server hub endpoint. Register it in _Host.cshtml with a small script block that checks for navigator.serviceWorker. This script enables the browser to serve the UI from the cache when the network is unavailable, while SignalR automatically reconnects when connectivity returns.

Deploying to Azure Static Web Apps

Azure Static Web Apps can host a Server‑Side Blazor app by using the built‑in Azure Functions proxy for SignalR. First, publish the project to the publish folder, then run the Azure CLI command below. The --output-location points to the published output, and the --branch main tells the service to watch the default branch for updates.

az staticwebapp create \\  --name BlazorOfflineSW \\  --resource-group MyResourceGroup \\  --location eastus \\  --source . \\  --output-location \"./bin/Release/net8.0/publish\" \\  --branch main

After the deployment finishes, Azure provides a live URL (e.g., https://blazoroftlinesw.azurestaticapps.net). Open it in Chrome, press F12 → Application → Service Workers, and you’ll see the PWA registered and ready to serve offline content.

Testing Offline Behavior

Use Chrome’s “Offline” throttling mode to simulate a lost connection. Navigate to a page that loads data from an API endpoint (for example, a weather widget). The first request hits the server, but subsequent visits load the cached JSON from the service worker’s CacheStorage. You can verify that UI updates still flow when the network returns because SignalR automatically re‑establishes the hub connection.

Performance Tips for Server‑Side Blazor in a PWA Context

1. Reduce round‑trip latency by enabling HTTP/2 on the Azure Front Door tier; Azure Static Web Apps supports it out of the box. 2. Use RenderMode.ServerPrerendered for the initial page load so the user sees static HTML instantly, then let Blazor take over. 3. Limit the size of the cached assets to under 5 MB to stay within the service worker storage quota on most mobile browsers. 4. Monitor SignalR reconnection events in the browser console; adding exponential back‑off logic can prevent rapid reconnect loops on flaky networks.

Sources

Microsoft Docs – Blazor Server; Azure Static Web Apps documentation; PWABuilder guide on service worker configuration.

Author: Mahmut Sarıkaya — sarikayadev.com