DataSag guides · Updated 27 October 2026

Load analytics without blocking rendering on Material for MkDocs

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 Material for MkDocs.

Start with the Material for MkDocs installation

Configure a local theme custom_dir and extend base.html in overrides/main.html. Add the deferred tracker inside an extrahead block while preserving parent content with super(). Merge these changes into your existing MkDocs configuration, build the site and inspect the generated document. Do not edit the installed theme package.

Material may use instant navigation, which changes the reading experience without a complete document reload. Install the global tracker once and test actual path changes. A replacement block that omits parent content can remove unrelated theme functionality.

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 Material for MkDocs

  1. Keep defer on the external script in the extrahead override and preserve the surrounding theme blocks. Inspect extra_javascript and custom lifecycle helpers for another loader before comparing any performance measurements.
  2. Measure the built site with representative navigation, search and content assets under fixed browser and network conditions. A local development refresh can include rebuilding behavior that visitors to the generated static site never encounter.
  3. Test an early download click and a later instant-navigation transition. Record when tracking is available relative to those actions. Delaying custom code until a later document lifecycle event can change coverage even if startup measurements improve.

Production-theme timing and action coverage are evaluated together without conflating development rebuild behavior with visitor performance.

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 Material for MkDocs

The shared installation belongs in an extrahead block in a theme override. Use this as the installation reference while checking the procedure above.

# Merge into mkdocs.yml:
theme:
  name: material
  custom_dir: overrides

<!-- overrides/main.html -->
{% extends "base.html" %}
{% block extrahead %}
  {{ super() }}
  <script defer src="https://www.datasag.com/tracker.js" data-datasag-key="YOUR_PUBLIC_KEY"></script>
{% endblock %}

Related Material for MkDocs guides

Full Material for MkDocs setup guide · Search and AI visibility

References

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