DataSag guides · Updated 27 October 2026

Load analytics without blocking rendering on your website

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.

Before you start

Install the DataSag script once on the pages you intend to measure. Use the public key from the project you are inspecting. Publish your change, then test the public domain rather than relying on an editor preview.

Account credentials, database credentials and provider API keys do not belong in the tracking snippet. Keep existing consent controls in place. Report availability depends on your current plan and provider connections.

Load analytics without blocking rendering: step by step

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.
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.
Keep one installation in the shared document or layout. Duplicate execution adds work even if the browser reuses the downloaded file.
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.
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.
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 tested URL, date, browser state and observed request. Repeat on a nested page to check the shared installation. Keep the evidence so you can distinguish a later regression from a report-filter change.

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.