Third-party scripts — analytics, tags and the CSP

Analytics, Tag-Manager, Chat-Widgets, Consent-Banner - das gehört in deine App, nicht ins CMS.

Der Grund ist Eigentum. Ein Script-Tag ist ausführbarer Code auf jeder Seite; er wird reviewt, versioniert und deployed wie der Rest deiner App. Ihn in ein editierbares Feld zu legen macht aus „Überschrift ändern“ und „beliebiges JavaScript in Produktion ausführen“ dieselbe Berechtigung.

Analytics: nimm die offiziellen Komponenten

Für Google Analytics und Tag Manager baue kein Script-Tag von Hand. @next/third-parties liefert Komponenten, die das Skript und das Init-Snippet mit der richtigen Strategie laden:

// app/[[...path]]/layout.tsx
import { GoogleAnalytics, GoogleTagManager } from "@next/third-parties/google";

const gaId = process.env.NEXT_PUBLIC_GA_ID?.trim();
const gtmId = process.env.NEXT_PUBLIC_GTM_ID?.trim();

// ...innerhalb von <body>
{gtmId ? <GoogleTagManager gtmId={gtmId} /> : null}
{gaId ? <GoogleAnalytics gaId={gaId} /> : null}

Ein bloßes <Script src="...gtag/js?id=..."> lädt die Bibliothek, konfiguriert sie aber nie - es fehlt der inline gtag('config', id)-Aufruf. Genau solche halbfertigen Setups sollen diese Komponenten verhindern.

Die Prüfung auf die Umgebungsvariable ist keine Höflichkeit. Sie hält Analytics aus Preview-Deployments und lokaler Entwicklung heraus, damit deine Zahlen nicht deine eigenen Klicks sind.

Alles andere: next/script

Chat-Widgets, Support-Blasen, Social-Embeds und einmalige Anbieter-Tags haben keine offizielle Komponente. Die laufen über next/script:

import Script from "next/script";

<Script src="https://widget.example.com/embed.js" strategy="lazyOnload" />

Die Strategie wählen

Die Vorgabe ist selten die richtige:

afterInteractive - der Standard, richtig für Analytics und Tag-Manager. Lädt, sobald die Seite interaktiv ist.
lazyOnload - für alles, was der erste Bildschirm nicht braucht: Chat-Widgets, Support-Blasen, Social-Embeds.
beforeInteractive - nur für Skripte, die vor der Hydration laufen müssen, etwa ein Consent-Gate, das entscheidet, ob andere Skripte überhaupt laden dürfen. Es blockiert, also letzte Wahl.

Ein Chat-Widget auf afterInteractive konkurriert mit deiner eigenen Hydration um den Hauptthread. Das ist der häufigste Weg, auf dem eine schnelle cmssy-Site langsam wird - die Seiten sind statisch, die Drittanbieter-Payload nicht.

Die CSP blockiert sie

Das ist der Teil, der die meisten erwischt.

createCmssyProxy setzt eine Content Security Policy, damit der cmssy-Admin deine Site im Editor framen kann. Diese Policy regelt jedes Skript, das die Seite lädt - ein neu hinzugefügtes Drittanbieter-Skript kann also von einem Header blockiert werden, den du nicht geschrieben hast und vielleicht nicht kennst.

Das Symptom ist eindeutig: Das Skript läuft nie, im Netzwerk-Tab erscheint kein Fehler, und die Konsole zeigt einen CSP-Verstoß mit dem blockierten Origin. Wenn ein Tag in Produktion „einfach nicht auslöst“, lokal aber funktioniert: erst die Konsole prüfen, dann den Tag-Manager.

Fügst du ein Skript von einem neuen Origin hinzu, erweitere die Policy entsprechend.

Wenn du Skripte hinter Consent legst, ist das Gate ebenfalls App-Code und muss zuerst laufen. Setze die Consent-Logik auf beforeInteractive und lade die gegateten Skripte danach bedingt.

Gate nicht, indem du den Consent-Banner als CMS-Block renderst. Eine Redaktion, die diesen Block depubliziert, entfernte still den Mechanismus, nicht das Tracking - und die Site sammelte weiter Daten, ohne dass irgendetwas auf dem Bildschirm um Erlaubnis fragt.

Was stattdessen ins CMS gehört

Nicht das Skript - die Konfiguration. Eine Mess-ID, ein Kampagnen-Flag, ein Feature-Schalter sind Werte, und Werte lassen sich gefahrlos bearbeiten. Lies sie aus der Site-Config oder den Custom Fields einer Seite und reiche sie an ein Skript weiter, das deiner App gehört.

So bleibt die editierbare Fläche bei „welche ID“ statt „welcher Code“.

Nächste Schritte

Routen und Seiten - die Middleware, die die CSP setzt.
SEO - Metadaten, die Inhalt sind statt Code.
Branding - Werte auf Site-Ebene, die sich zu bearbeiten lohnen.