Performance & Optimierung

1. Script-Größe

Barefoot CMP wurde von Anfang an auf minimale Dateigröße optimiert. Das gesamte Consent-Management – Banner-UI, Consent-Logik, Translations für 12 Sprachen, Auto-Blocking und Google Consent Mode v2 – steckt in einer einzigen Datei.

consent-manager.js: ~25 KB gzipped (unkomprimiert ~80 KB)
Keine externen Abhängigkeiten (zero dependencies)
Alles in einer einzigen Datei: Banner-UI, Consent-Logik, Translations, Auto-Blocking

Vergleich mit anderen CMPs

CMP	Script-Größe (gzipped)	Externe Requests
Barefoot CMP	~25 KB	1 (Config)
Cookiebot	~45 KB	3-5
CookieYes	~55 KB	2-4
OneTrust	~80 KB	5-8
Usercentrics	~60 KB	3-6

Barefoot CMP ist bis zu 3x kleiner als die Konkurrenz. Weniger Bytes bedeuten schnellere Ladezeiten, weniger Bandbreitenverbrauch und bessere Lighthouse-Scores – besonders auf mobilen Geräten.

2. Ladestrategie

Die Art, wie Sie das Barefoot CMP Script einbinden, beeinflusst das Ladeverhalten Ihrer Website. Es gibt drei Möglichkeiten:

2.1 async-Attribut (empfohlen)

<script src="https://cmp.barefoot-performance.com/v1/loader.js?id=DEINE_CMP_ID" async></script>

Non-blocking: Die Seite lädt weiter, während das Script geladen wird
Script wird ausgeführt, sobald es geladen ist
Beste Option für die meisten Websites

2.2 defer-Attribut

<script src="https://cmp.barefoot-performance.com/v1/loader.js?id=DEINE_CMP_ID" defer></script>

Wartet, bis DOM fertig geparst ist
Ausführung in Reihenfolge der Script-Tags
Geeignet, wenn Sie die Ausführungsreihenfolge kontrollieren möchten

2.3 Ohne Attribut (synchron)

<script src="https://cmp.barefoot-performance.com/v1/loader.js?id=DEINE_CMP_ID"></script>

Blockiert das HTML-Parsing, bis das Script geladen und ausgeführt ist
Langsamste Variante, aber garantiert früheste Ausführung

Achtung: Synchrones Laden nur verwenden, wenn Consent Mode v2 Default-Werte VOR allen Google-Tags gesetzt werden müssen. In den meisten Fällen ist dies nicht notwendig.

Empfehlung: Verwenden Sie async für die meisten Websites. Google Consent Mode v2 Default-Werte werden automatisch so früh wie möglich gesetzt – unabhängig vom Lade-Attribut.

3. CDN & Caching

Barefoot CMP wird über das Vercel Edge Network ausgeliefert – ein globales CDN mit Points of Presence in über 70 Regionen weltweit. Das minimiert Latenz und garantiert schnelle Ladezeiten.

Cache-Strategien

banner.js: Cache-Control: public, max-age=86400, s-maxage=604800 (1 Tag Browser-Cache, 7 Tage CDN-Cache)
loader.js: Cache-Control: public, max-age=300 (5 Minuten)
Config-API: Cache-Control: public, max-age=300 (5 Minuten)
CORS: Access-Control-Allow-Origin: * (für Cross-Origin-Loading)

Preconnect Hint (optional)

Für noch schnellere initiale Ladezeiten können Sie Preconnect-Hints im <head> Ihrer Seite hinzufügen:

<link rel="preconnect" href="https://cmp.barefoot-performance.com">
<link rel="dns-prefetch" href="https://cmp.barefoot-performance.com">

Dies signalisiert dem Browser, die DNS-Auflösung und den TLS-Handshake bereits durchzuführen, bevor das eigentliche Script angefordert wird. Das spart typischerweise 50–150 ms.

4. Lighthouse-Auswirkungen

Die Auswirkungen von Barefoot CMP auf die Core Web Vitals und den Lighthouse-Score sind minimal. Hier eine detaillierte Übersicht:

Metrik	Auswirkung	Details
LCP (Largest Contentful Paint)	Minimal (~0–50 ms)	async-Loading, kein Render-Blocking
FID (First Input Delay)	Minimal (~0–10 ms)	Lightweight JavaScript
CLS (Cumulative Layout Shift)	Gering (~0.01–0.05)	Banner reserviert keinen Platz im Layout
TBT (Total Blocking Time)	Minimal (~5–15 ms)	Script-Ausführung sehr schnell
SI (Speed Index)	Kein Einfluss	Banner-Overlay beeinflusst SI nicht

Ein Lighthouse-Score von 90+ ist mit Barefoot CMP problemlos erreichbar. Die Auswirkungen auf die Core Web Vitals sind minimal. Im Vergleich zu größeren CMPs wie OneTrust oder Usercentrics sparen Sie bis zu 60–80 ms Total Blocking Time.

CLS-Minimierung

Barefoot CMP wurde speziell dafür entwickelt, keinen Layout-Shift zu verursachen:

Banner ist ein Overlay (position: fixed) – kein Layout-Shift
Floating Button ist absolut positioniert – kein Layout-Shift
Kein Reservieren von Platz im normalen Seitenfluss

5. MutationObserver & Auto-Blocking

Barefoot CMP nutzt einen MutationObserver, um nachgeladene Scripts und iFrames zu überwachen. Dieser Mechanismus ermöglicht das automatische Blocking von Trackern, ohne dass Sie jeden Script-Tag manuell markieren müssen.

Neue <script>- und <iframe>-Elemente werden automatisch gegen die Blocklist geprüft
Über 30 bekannte Tracker-Patterns (Google Analytics, Facebook Pixel, TikTok, LinkedIn etc.)
Performance-Impact: Minimal – MutationObserver ist nativ im Browser implementiert und sehr effizient

Auto-Blocking deaktivieren

Wenn Performance für Ihre Website absolut kritisch ist, können Sie den MutationObserver deaktivieren:

window.ConsentManagerConfig = {
  autoBlocking: false // MutationObserver deaktivieren
};

Achtung: Ohne autoBlocking müssen Sie Scripts manuell mit dem Attribut data-consent-category markieren. Dies ist weniger komfortabel, aber marginal performanter.

6. Geo-Detection Performance

Barefoot CMP erkennt automatisch, ob sich der Besucher in der EU befindet, um das Banner nur dort anzuzeigen, wo es rechtlich erforderlich ist. Diese Geo-Detection wurde auf minimale Performance-Auswirkungen optimiert.

API-Call: /v1/geo (nur 1x pro Session)
Timeout: 500 ms
Session-Caching in sessionStorage – kein erneuter API-Call bei Seitenwechsel
Bei Timeout: Fallback greift sofort (Banner wird angezeigt)
Kein spürbarer Performance-Impact für den Endnutzer

7. Consent-Cookie

Die Consent-Entscheidung des Nutzers wird in einem kompakten Cookie gespeichert:

Cookie-Name: bf_consent
Cookie-Größe: ~200 Bytes
Cookie-Lebensdauer: 365 Tage (konfigurierbar im Dashboard)
Kein Performance-Impact auf HTTP-Requests – der Cookie wird nur an cmp.barefoot-performance.com gesendet, nicht an Ihre eigene Domain

8. Best Practices

8.1 Script-Platzierung

Im <head>, VOR Google Tag Manager und Analytics
async-Attribut verwenden
Preconnect-Hint hinzufügen (optional, siehe Abschnitt 3)

<head>
  <!-- Preconnect (optional) -->
  <link rel="preconnect" href="https://cmp.barefoot-performance.com">

  <!-- Barefoot CMP (VOR GTM!) -->
  <script src="https://cmp.barefoot-performance.com/v1/loader.js?id=DEINE_CMP_ID" async></script>

  <!-- Google Tag Manager -->
  <script>(function(w,d,s,l,i){...})(window,document,'script','dataLayer','GTM-XXXXX');</script>
</head>

8.2 Config optimieren

Geo-Targeting aktivieren: Nur EU-Besucher bekommen das Banner – weniger Banner-Anzeigen = weniger DOM-Manipulation
showFloatingButton auf false wenn nicht benötigt – spart DOM-Elemente
autoBlocking deaktivieren nur wenn Performance absolut kritisch ist

8.3 Caching

CDN-Caching nutzen (Vercel, Cloudflare) – Barefoot CMP setzt korrekte Cache-Header automatisch
Browser-Cache nicht für CMP-Requests blockieren – keine no-cache-Header für Barefoot-Domains setzen
Service Worker: Barefoot CMP Scripts NICHT cachen – Consent-Entscheidungen müssen immer aktuell sein

8.4 Bundle-Größe minimieren

Barefoot CMP hat keine Abhängigkeiten – kein Einfluss auf Ihr JavaScript-Bundle
Kein Tree-Shaking nötig – das Script ist bereits optimal
Kein Build-Step erforderlich – einfach Script-Tag einbinden und fertig

9. Troubleshooting Performance

Die häufigsten Performance-Fragen und ihre Lösungen:

Lighthouse zeigt schlechten Score nach CMP-Installation ▼

In den meisten Fällen ist Barefoot CMP nicht die Ursache. Prüfen Sie folgende Punkte:

Ist das async-Attribut gesetzt? Ohne async blockiert das Script das Rendering.
Fügen Sie einen Preconnect-Hint hinzu, um die initiale Verbindung zu beschleunigen.
Prüfen Sie andere Scripts auf Ihrer Seite – oft sind größere JavaScript-Bundles, unoptimierte Bilder oder Third-Party-Scripts die eigentliche Ursache.
Öffnen Sie den Network-Tab in den DevTools und sortieren Sie nach Größe – Barefoot CMP sollte mit ~25 KB weit unten stehen.

Banner erscheint verzögert ▼

Bei async-Loading ist eine minimale Verzögerung normal (typischerweise 100–300 ms). Das ist gewollt, damit die Seite zuerst lädt. Wenn Sie eine sofortige Anzeige benötigen:

Verwenden Sie synchrones Loading (ohne async/defer).
Beachten Sie, dass dies die Seiten-Ladezeit erhöht.
In den meisten Fällen ist die kurze Verzögerung die bessere Wahl für die User Experience.

Seite lädt langsam ▼

Langsame Ladezeiten sind meist nicht CMP-bedingt. Barefoot CMP ist mit ~25 KB gzipped eines der kleinsten Scripts auf Ihrer Seite. So finden Sie die wahre Ursache:

Öffnen Sie den Network-Tab in den DevTools (F12) und analysieren Sie die Waterfall-Ansicht.
Prüfen Sie, ob andere Scripts, große Bilder oder langsame API-Calls die Ursache sind.
Nutzen Sie Lighthouse (F12 → Lighthouse) für eine detaillierte Analyse.
Deaktivieren Sie testweise andere Plugins/Scripts, um den Verursacher zu identifizieren.

MutationObserver verbraucht CPU ▼

Der MutationObserver von Barefoot CMP ist auf minimale CPU-Last optimiert. Hoher CPU-Verbrauch tritt nur in sehr seltenen Fällen auf:

Extrem dynamische SPAs (Single Page Applications), die hunderte DOM-Änderungen pro Sekunde durchführen.
Seiten mit aggressivem Lazy-Loading von Dutzenden Scripts gleichzeitig.
Workaround: Deaktivieren Sie autoBlocking und markieren Sie Scripts manuell mit data-consent-category.