So laden Sie Axeptio schneller (ohne die Einwilligung zu gefährden)

Über eine schnelle Büroverbindung erscheint das Axeptio-Banner fast sofort. Auf einem Smartphone unterwegs lesen, scrollen und tippen Besucher, bevor es erscheint, manchmal lange nach der Seite selbst. Währenddessen warten Ihre Tags auf eine Einwilligung, die noch gar nicht abgefragt wurde, und das Banner legt sich über eine Seite, die der Besucher bereits nutzt.

Axeptio ist selten allein schuld. Was es verzögert, ist sein Platz in der Warteschlange. Dieser Leitfaden zeigt, was das Banner braucht, bevor es erscheinen kann, was eine echte Seite mit dieser Kette macht und welche Hebel es nach vorne holen, ohne anzutasten, was die Einwilligung verlangt.

Was Axeptio lädt, bevor das Banner erscheint

Das Banner ist der letzte Schritt einer kurzen Kette, und jeder Schritt wartet auf den vorherigen:

1. Die Einstellungen: ein kleines Inline-Skript, das window.axeptioSettings deklariert (Ihre Projekt-ID und die Cookie-Version) und das SDK einbindet.
2. Das SDK, ein Skript, ausgeliefert von static.axept.io.
3. Die Projektkonfiguration: Texte, Anbieter und Design, die das SDK abruft, sobald es läuft.
4. Die Styles und die Schrift des Widgets, darunter ein Webfont-Stylesheet von fonts.axept.io.
5. Das Banner, gerendert, sobald all das da ist.

Keine dieser Dateien ist schwer. Das Problem: Auf einer vollen Seite werden sie angefragt, während bereits Dutzende anderer Dateien laden, und bei einer langsamen mobilen Verbindung kostet jede Anfrage in der Warteschlange einen Roundtrip.

Ein Praxisbeispiel: 16 Sekunden bei Slow 4G

Wir haben eine echte WordPress-Landingpage gemessen, gebaut mit einem Page Builder, rund 150 Anfragen, mit installiertem Axeptio. Protokoll: Smartphone-Emulation mit 390 × 844 Pixeln, Browser-Cache deaktiviert, kein Consent-Cookie, keine Interaktion, fünf Durchläufe pro Netzwerk, jeweils der Median.

• Ungedrosselt: erste Darstellung nach 0,57 s, Banner steht nach 1,42 s.
• Fast 4G: erste Darstellung nach 1,32 s, Banner steht nach 3,12 s.
• Slow 4G: erste Darstellung nach 5,72 s, Banner steht nach 15,98 s.

Im langsamen Profil hatte der Besucher zehn Sekunden Seite vor sich, bevor er überhaupt gefragt wurde. Jedes Tag, das auf die Einwilligung wartete, wartete mit ihm.

Eine abgespeckte Version derselben Seite mit rund 80 statt 150 Anfragen hatte ihr Banner bei Slow 4G nach 5,8 s stehen. Diese Version hat auch die Darstellung des Banners verändert, der Vergleich liefert also eine Größenordnung statt eines exakten Gewinns. Genau um die Größenordnung geht es: Die Konkurrenz zu halbieren hat die Wartezeit um rund zwei Drittel verkürzt.

Hebel 1: verringern, was mit dem Banner konkurriert

Das ist der größte Hebel, und er hat nichts mit den Axeptio-Einstellungen zu tun. Sehen Sie sich das Network-Panel in einem gedrosselten Mobilprofil an und listen Sie auf, was vor dem Banner lädt: Page-Builder-Stylesheets, die auf anderen Templates genutzt werden, ein Slider-Skript für einen Slider unterhalb des sichtbaren Bereichs, ein Chat-Widget, mehrere Marketing-Pixel, Bilder in voller Größe weit unten auf der Seite.

• Verzögern Sie die Skripte, die beim Laden nicht gebraucht werden (Chat, Pop-ups, Slider unterhalb des sichtbaren Bereichs), und lassen Sie das Consent-Tool dabei außen vor (Hebel 2).
• Laden Sie keine Assets mehr auf Templates, die sie nicht nutzen.
• Laden Sie die Bilder unterhalb des sichtbaren Bereichs per Lazy Loading, nie das Hauptbild oben.
• Kürzen Sie das CSS auf das, was die Seite nutzt, damit weniger und kleinere Stylesheets in der Warteschlange stehen.

Jede Anfrage, die Sie vom Beginn des Ladens entfernen, ist ein Platz, den die Axeptio-Kette früher bekommt.

Hebel 2: das Consent-Tool nie verzögern

Performance-Tools, die JavaScript bis zur ersten Interaktion aufschieben, sind ein häufiger Grund für ein Banner, das erst nach einem Scrollen oder Tippen erscheint. Sind die Inline-Einstellungen oder das SDK verzögert, wartet das Banner darauf, dass der Besucher sich bewegt, und die Einwilligung wird erst im Nachhinein abgefragt.

Fügen Sie beide den Ausnahmen Ihres Verzögerungstools hinzu: das Inline-Skript, das Sie über axeptioSettings erfassen können, und das SDK, das Sie über axept.io erfassen können. Prüfen Sie dann das Ergebnis: in einem privaten Fenster neu laden, nichts berühren, und das Banner muss von selbst erscheinen. Die allgemeine Methode, um herauszufinden, was eine Verzögerung kaputt gemacht hat, steht in unserem Leitfaden zur JavaScript-Verzögerung.

Hebel 3: die Kette früh starten

Platzieren Sie das Axeptio-Snippet weit oben im <head>, nicht im Footer und nicht hinter einem anderen Skript, das selbst wartet. Wärmen Sie dann die Verbindung zum SDK-Host vor, damit die erste Anfrage nicht zusätzlich zu ihrem Platz in der Warteschlange noch für DNS und TLS bezahlt:

<link rel="preconnect" href="https://static.axept.io">

Beschränken Sie die Hints auf die Hosts, die Sie im Network-Panel tatsächlich für Axeptio sehen, und auf ein oder zwei insgesamt: Jedes Preconnect öffnet eine Verbindung, die ebenfalls konkurriert.

Hebel 4: die Schrift, die niemand sieht

Das Widget bindet ein Stylesheet für seine eigene Webfont ein. Ist Ihr Banner in der Schrift Ihrer Website gestaltet, ist diese Anfrage reine Verschwendung: eine Datei mehr in der Warteschlange, und jedes Skript, das auf document.fonts.ready wartet, wartet auch auf sie. Auf der gemessenen Seite verlor eine Banner-Einblendung, die auf die Schriften wartete, bei Slow 4G 600 ms an eine Schrift, die nie angezeigt wurde.

Wenn, und nur wenn, Ihr Banner diese Schrift nicht nutzt, können Sie das Stylesheet entfernen, sobald es eingefügt wird:

// Entfernt das Webfont-Stylesheet des Widgets, sobald es eingefügt wird.
// Nur wenn das Banner mit Ihrer eigenen Schrift gestaltet ist.
(function () {
  function drop(node) {
    if (node.nodeType !== 1) return;
    if (node.tagName === 'LINK' && /fonts\.axept\.io/.test(node.getAttribute('href') || '')) { node.remove(); return; }
    if (node.querySelectorAll) node.querySelectorAll('link[href*="fonts.axept.io"]').forEach(function (l) { l.remove(); });
  }
  new MutationObserver(function (mutations) {
    mutations.forEach(function (m) { m.addedNodes.forEach(drop); });
  }).observe(document.documentElement, { childList: true, subtree: true });
})();

Prüfen Sie im Network-Panel, dass keine Anfrage an fonts.axept.io übrig bleibt und dass der Bannertext in Ihrer Schrift dargestellt wird. Schreibt Ihr Verzögerungstool Inline-Skripte um, nehmen Sie auch dieses aus.

Wenn Sie das Banner anpassen

Viele Websites gestalten das Banner passend zu ihrer Marke um. Drei Regeln sorgen dafür, dass diese Anpassung Sie später nichts kostet:

• Zielen Sie auf stabile Ankerpunkte. Die Klassennamen des Widgets werden generiert und ändern sich zwischen Versionen. Zielen Sie auf IDs wie #axeptio_btn_acceptAll oder auf einen Container über seinen Inhalt (zum Beispiel div:has(> #axeptio_btn_acceptAll)), nie auf eine generierte Klasse.
• Belassen Sie die Texte im Axeptio-Backoffice. Was angezeigt wird, muss dem entsprechen, was Axeptio als dem Besucher angezeigt speichert. Werden die Texte per JavaScript umgeschrieben, laufen Bildschirm und Einwilligungsnachweis auseinander.
• Reagieren Sie über das SDK auf die Wahl, nicht über das Markup. Die Elemente des Banners können nach der Antwort des Besuchers in der Seite bleiben, das Warten auf ihr Verschwinden kann also ewig dauern. Hören Sie stattdessen auf das SDK:

// Läuft, sobald der Besucher eine Wahl getroffen hat.
window._axcb = window._axcb || [];
window._axcb.push(function (sdk) {
  sdk.on('cookies:complete', function (choices) {
    // choices enthält die vom Besucher akzeptierten Anbieter.
  });
});

Und wenn Sie den schwebenden Cookie-Button ausblenden, geben Sie Besuchern einen anderen Weg zurück zu ihrer Auswahl, der nur angezeigt wird, wenn das SDK ihn bereitstellt:

<a href="#" id="manage-cookies" hidden>Manage cookies</a>
<script>
  window._axcb = window._axcb || [];
  window._axcb.push(function () {
    var link = document.getElementById('manage-cookies');
    if (typeof window.openAxeptioCookies !== 'function' || !link) return;
    link.hidden = false;
    link.addEventListener('click', function (e) { e.preventDefault(); window.openAxeptioCookies(); });
  });
</script>

So messen, wie ein neuer Besucher es erlebt

• Ein privates Fenster, damit kein Consent-Cookie gesetzt ist; mit Cookie erscheint das Banner nie und Sie messen nichts.
• DevTools mit deaktiviertem Cache und einem gedrosselten Mobilprofil, Slow 4G eingeschlossen.
• Nichts berühren und notieren, wann das Banner auf dem Bildschirm steht, zum Beispiel mit den Screenshots des Performance-Panels.
• Fünf Durchläufe pro Profil und der Median, wie in unserem Leitfaden zu Labor- und Felddaten erklärt.
• Testen Sie auch mit einem Inhaltsblocker: Wird Axeptio blockiert, muss die Seite nutzbar bleiben und darf nie auf ein Banner warten, das nicht kommt.

Mit Mantys Core

Zusammenfassung

• Das Axeptio-Banner ist das Ende einer Kette kleiner Anfragen, und auf einer vollen Seite wartet diese Kette, bis sie an der Reihe ist.
• Auf der gemessenen Seite brauchte das Banner bei Slow 4G 16 s; mit halb so vielen Anfragen unter 6 s.
• Verringern Sie die Konkurrenz, verzögern Sie nie das Consent-Tool, laden Sie es weit oben im Head und lassen Sie die Schrift weg, die Sie nicht anzeigen.
• Passen Sie über stabile IDs und das Backoffice an und reagieren Sie über das SDK auf die Wahl.
• Messen Sie wie ein neuer Besucher: privates Fenster, Cache aus, gedrosseltes Mobilprofil, keine Interaktion, mehrere Durchläufe.