DataSag guides · Updated 27 October 2026

Load analytics without blocking rendering on Drupal Twig themes

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 Drupal Twig themes.

Start with the Drupal Twig themes installation

Use a maintained custom theme or subtheme and identify its html.html.twig document wrapper. Add the deferred tracker inside head while preserving Drupal's existing placeholders, attributes and attached assets. Rebuild the relevant caches and inspect the public rendered document. Do not edit Drupal core or replace the full wrapper with a minimal example.

The active public theme and the administration theme can differ. A node or block template is not the global document wrapper, and Ajax-rendered fragments do not represent independent document loads. Check public routes, caching and any separately configured theme before assuming complete coverage.

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 Drupal Twig themes

  1. Keep the external script deferred in the maintained public document wrapper and inspect attached libraries for duplicate loaders. Preserve core placeholders and asset output rather than bypassing Drupal's rendering structure to change one tracker.
  2. Measure a signed-out public page with normal Drupal caching and representative assets under fixed browser conditions. Compare it with the same route and cache state; authenticated Admin resources can produce a very different loading profile.
  3. Test an early primary action and a later Ajax update. A custom delayed loader may miss the first action, while a fragment behavior may accidentally reinstall tracking. Record coverage and request count together with observed timing.

Public-page timing reflects the intended cache state and one deferred loader remains stable through subsequent Ajax activity.

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 Drupal Twig themes

The shared installation belongs in the head in your custom theme html.html.twig override. 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 Drupal Twig themes guides

Full Drupal Twig themes setup guide · Search and AI visibility

References

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