DataSag guides · Updated 27 October 2026

Load analytics without blocking rendering on Standalone Blazor WebAssembly

Use the platform's non-blocking external script mechanism and install the tracker once. Measure the published page before and after the change; script size alone cannot predict the effect on your website. This guide applies to Standalone Blazor WebAssembly.

Start with the Standalone Blazor WebAssembly installation

For a standalone Blazor WebAssembly application, add the deferred external tracker to the existing host document wwwroot/index.html, once near the end of body. Preserve the Blazor boot script, root element and base address. This guide is specifically for the standalone WebAssembly host document, not every Blazor rendering mode.

Do not insert the global tracker in a route component or HeadContent component. Component removal does not necessarily unload script listeners. Blazor Web Apps, server rendering and enhanced navigation require their own host and lifecycle assessment rather than this standalone installation recipe.

Use the public project key from the DataSag project you are inspecting. A test on a preview domain does not confirm that the production domain has the same code or settings.

Load analytics without blocking rendering in Standalone Blazor WebAssembly

  1. Keep one deferred tracker near the end of the standalone wwwroot/index.html body and preserve the Blazor boot sequence. Avoid a route component that downloads or executes the tracker on every visit.
  2. Measure the published application with fixed cache and network conditions. Include the time needed for the app to become usable and the earliest intended action, not just the external script transfer.
  3. Navigate within the running WebAssembly app and inspect execution separately from its initial boot cost. A cached framework payload and a fresh first-load payload are different baselines; record which one your timing comparison uses.

The standalone host uses one non-blocking tracker with initial WebAssembly boot and later navigation assessed as separate cases.

Complete the collection checks

  1. Record a baseline of the published page using the same browser, device emulation and network settings you will use for comparison. Include a representative content page, not only the homepage.
  2. Use defer for a normal external HTML script, or the framework-specific loading strategy shown in the installation example. Do not add a parser-blocking synchronous script as a shortcut.
  3. Keep one installation in the shared document or layout. Duplicate execution adds work even if the browser reuses the downloaded file.
  4. Inspect the Network waterfall for tracker.js and /api/track. Compare transfer size, timing and request count on a cold load and a cached load.
  5. Check that measurement still starts at the intended point. Loading only after idle or interaction can omit short visits and early clicks; performance and coverage must be evaluated together.
  6. Repeat the measurements and record variability. Report measured results for your page rather than claiming a universal speed improvement or zero performance cost.
// Browser Console, after loading the published page:
performance.getEntriesByType('resource')
  .filter(entry => entry.name.includes('/tracker.js'))
  .map(entry => ({ url: entry.name, durationMs: entry.duration }));
// Cross-origin transfer details may be unavailable.

What a successful check looks like

The script uses a non-blocking loading mechanism, appears once and records the intended visits. Any performance claim comes from repeatable measurements of the actual site.

Record the public path you tested, the browser state, the approximate time and the observed request. Check one direct page load and one later navigation so the result covers more than the homepage.

Common mistake

A faster lab result does not prove every visitor has a faster experience. Avoid mixing a warm-cache result with a cold-load baseline.

Installation snippet for Standalone Blazor WebAssembly

The shared installation belongs in the host document wwwroot/index.html in a standalone WebAssembly app. Use this as the installation reference while checking the procedure above.

<script defer src="https://www.datasag.com/tracker.js" data-datasag-key="YOUR_PUBLIC_KEY"></script>

Related Standalone Blazor WebAssembly guides

Full Standalone Blazor WebAssembly setup guide · Search and AI visibility

References

Official Standalone Blazor WebAssembly documentation covers the integration point. For DataSag data handling, read the privacy policy. Use support if a request fails after these checks.