Transparenzbericht

SDK-Performance Transparenz

Kunden sollten alles wissen: SDK-Größe, Ladezeit, Auswirkung auf die Seitengeschwindigkeit, API-Latenz. Keine versteckten Zahlen.

Zuletzt aktualisiert: 31 Mayıs 2026 · Nächste Überprüfung: 31 Ağustos 2026

Hinweis zur Branchentransparenz: Die meisten unserer Wettbewerber (inländische und internationale Consent- und a11y-SDK-Anbieter) legen diese Metriken nicht öffentlich offen; hinter den verborgenen Zahlen stecken meist entweder aufgeblähte Bundles oder ungetestete Behauptungen. Wir haben einen anderen Weg gewählt: Wir teilen die realen Zahlen, die wir haben, und was wir nicht messen können, kennzeichnen wir klar als "Messung ausstehend" .

SDK-Dateigrößen

1. SDK-Dateigrößen

Die SDK-Größe bezeichnet die zusätzlichen Bytes, die der Browser Ihrer Besucher herunterlädt. Weniger ist besser; jedoch "die komprimierte Brotli-Zahl, um kleiner zu wirken" mit "die reale minifizierte Bruttogröße" unterscheiden sich. Nachfolgend geben wir alle drei Messwerte zugleich an.

SDK	Brutto (min)	Gzip	Brotli
Cookie-SDK `consent.js`	Messung ausstehend	Messung ausstehend	Messung ausstehend
Accessibility-SDK `accessibility.js`	Messung ausstehend	Messung ausstehend	Messung ausstehend
Loader `/sdk/consent.js`, versionslose Weiterleitung	< 1 KB	< 0,5 KB	< 0,4 KB

Warum "ausstehend"? Unsere Production-Build-Pipeline (minify + tree-shake + brotli precompress) wird nach der Integration der Phasen 12-15 neu aufgesetzt. Die ersten offiziellen Messwerte veröffentlichen wir in Q3 2026. Wir lassen das Feld lieber leer, als eine Schätzung anzugeben.

Ladestrategie

2. Ladestrategie

Egal wie klein ein SDK ist, wenn es falsch geladen wird, beeinträchtigt es trotzdem die Seitengeschwindigkeit. cerez.io SDK wurde mit den folgenden Techniken so konzipiert, dass es nicht render-blocking ist.

Async Loading

Unser Embed-Code verwendet <script async> . Während das SDK heruntergeladen wird, rendert der Browser die Seite weiter, es gibt kein Render-Blocking.

Versionsloser Loader

Den Websites wird /sdk/consent.js bereitgestellt; auf dem Server wird per 302 zur aktuellen Version weitergeleitet. Bei einem Versionsupdate muss der Website-Betreiber keinen Code ändern.

Serverseitiger Cache

Die Banner-Einstellungen werden 5 Minuten lang in Redis zwischengespeichert. Tausende Besucher innerhalb derselben Minute lösen eine einzige DB-Abfrage aus.

sessionStorage-Cache

Die Banner-Entscheidung wird 1 Stunde lang im Browser gespeichert. Öffnet derselbe Nutzer einen neuen Tab, ruft das SDK die API gar nicht erst auf.

Shadow-DOM-Isolation

Das Banner und das a11y-Widget werden im Shadow DOM gerendert. Die Style-Recompute-Kosten des Browsers bleiben minimal und das CSS der Host-Website wird nicht beeinträchtigt.

Lazy a11y-Panel

Das Accessibility Widget lädt seine volle Last von 40+ Funktionen erst, wenn der Auslöser-Button gedrückt wird. Beim Aufruf der Seite befindet sich nur der Button selbst im DOM.

Auswirkung auf Core Web Vitals

3. Auswirkung auf die Seitengeschwindigkeit, Core Web Vitals

Unsere offizielle Lighthouse-Messung ist derzeit nicht verfügbar. Viele Wettbewerber teilen Zahlen wie "<5ms Auswirkung", ohne anzugeben, in welcher Testumgebung, mit welchem Netzwerkprofil oder auf welchem Seitentyp gemessen wurde. Statt voreilig zu sprechen, beauftragen wir in Q3 2026 eine unabhängige Drittmessung und veröffentlichen den Bericht hier zusammen mit HAR-Datei und Screenshots.

Die folgenden Metriken spiegeln unsere repräsentativen Erwartungen wider, die sich aus der technischen Architektur ergeben; sie sind keine Messergebnisse. Die realen Werte werden nach einem unabhängigen Audit auf dieser Seite aktualisiert.

<50ms

LCP-Auswirkung, Async Loading, kein Render-Blocking

0

CLS (Layout Shift), Shadow DOM löst keinen Reflow aus

<10ms

TBT, Main-Thread frei, worker-friendly

defer

Bundle-Strategie, Ausführung nach DOMContentLoaded

Repräsentative / Beispielmetriken. Messung ausstehend. Anders als die "0ms Auswirkung"-Behauptungen der Wettbewerber sprechen wir auf einer Baseline aus Mittelklasse-Mobilgerät + 4G-Netz.

Lokales Hosting · sichere Infrastruktur

4. Hosting & CDN

Von wo die SDK-Dateien physisch ausgeliefert werden, ist für öffentliche Einrichtungen und auf KVKK-Compliance fokussierte Kunden entscheidend.

Lokales Hosting in der Türkei Alle Anwendungsserver, die Banner-Config-DB, die Consent-Log-DB und die API-Endpunkte werden in Rechenzentren innerhalb der Grenzen der Türkei gehalten. In Bezug auf KVKK Artikel 9 (Beschränkung der Übermittlung ins Ausland) ist dies einwandfrei.
Static-Asset-Cache-Header Den SDK-Dateien werden Cache-Control: public, max-age=300 + ETag + Last-Modified Header zugewiesen. Bei wiederholten Besuchen erhält der Browser ein 304 Not Modified und lädt null Bytes herunter.
CDN-Integration wird geprüft Eine Cloudflare-Integration ist geplant; voraussichtlich Q3-Q4 2026. Lokale Edge-Nodes (Istanbul, Ankara, Izmir) werden einstellige ms-Latenz bieten. Derzeit werden statische Dateien direkt vom Server ausgeliefert.
HTTP/2 + TLS 1.3 + brotli Der gesamte SDK-Traffic wird mit TLS 1.3, HTTP/2 und Brotli-Komprimierung ausgeliefert.

API-SLA-Ziele

5. API-Performance, Ziel-SLA

Während das SDK läuft, führt es drei Arten von Backend-Aufrufen durch: das Abrufen der Banner-Config, das Speichern des Consents und Heartbeat. Die folgenden Zahlen sind die SLA-Werte, die wir anstreben; sie werden in der Produktion kontinuierlich überwacht und lösen bei einer Verletzung einen Alarm aus.

Endpoint	P50 (Median)	P95	Rate Limit
`GET /banner/{api_key}` Banner-Config (5 Min. Cache)	< 100ms	< 300ms	500/dk
`POST /consent/log` Consent-Speicherung (async write)	< 80ms	< 200ms	500/dk
`POST /heartbeat` Pageview-Zähler	< 50ms	< 150ms	500/dk

Eine Status-Seite ist in Vorbereitung. In Q3 2026 status.cerez.io veröffentlichen wir auf der Subdomain ein Echtzeit-Dashboard für Uptime + Latenz. Jede SLA-Verletzung wird dort automatisch aufgeführt.

Verpflichtung

6. Prozesstransparenz

Performance ist keine einmalige Messung, sondern eine fortlaufende Verpflichtung.

Versions-Log

Jedes SDK-Release wird in den GitHub-Release-Notes und auf der /docs/changelog Seite veröffentlicht. Das öffentliche Changelog wird in Q3 2026 freigeschaltet.

Ankündigung von Breaking Changes

Eine rückwärtsinkompatible Änderung an der SDK-API wird mindestens 90 Tage im Voraus per E-Mail + Admin-Panel-Banner + Changelog angekündigt.

Deprecation-Policy

Bevor ein API-Endpunkt oder ein SDK-Parameter entfernt wird, gilt eine Deprecation-Frist von mindestens 6 Monaten. Während dieser Zeit funktioniert die alte Version weiter.

Vierteljährlicher Performance-Bericht

Wir planen, vierteljährlich einen aggregierten Performance-Bericht zu veröffentlichen: durchschnittliche LCP-Auswirkung, P99-Latenz, Uptime-Prozentsatz, Anzahl behobener Fehler.

Häufige Fragen

7. Offene Fragen

Wann kommen die echten Lighthouse-Messungen?

Wir streben Q3 2026 an. Wir werden eine unabhängige Drittprüfungsfirma beauftragen; der Bericht wird zusammen mit HAR-Dateien + Screenshots + Rohdaten veröffentlicht. Statt eine Schätzung zu teilen, bevorzugen wir einen Ansatz, der auf den gemessenen realen Wert wartet.

Die SDK-Größe ist für mich entscheidend, kann ich eine exakte Zahl bekommen?

Wir veröffentlichen die exakte Zahl nach dem Production-Build auf dieser Seite. Bis dahin teilen wir für Unternehmenskunden auf Anfrage über die Kontaktseite den aktuellen Messwert aus dem bestehenden Build individuell mit Ihnen.

Verlassen meine Daten die Türkei?

Nein. SDK-Traffic, Banner-Config, Consent-Logs und API-Endpunkte werden auf Servern innerhalb der Grenzen der Türkei verarbeitet und gespeichert. Nach der CDN-Integration kann nur die statische SDK-JS-Datei von Edge-Nodes ausgeliefert werden; diese Dateien enthalten keine personenbezogenen Daten.

Wettbewerber sagen "0ms Auswirkung", warum sind Ihre anders?

Jedes asynchron geladene Drittanbieter-Skript hat einen Aufwand größer als null; das ist ein physikalisches Gesetz. Wer "0ms" sagt, teilt entweder seine Messmethodik nicht oder misst unter idealen Bedingungen auf einer leistungsstarken Maschine. Wir sprechen auf einer Baseline aus Mittelklasse-Mobilgerät und 4G-Netz und sind dabei transparent.

Ist die Status-Seite live?

Noch nicht. status.cerez.io Sie wird in Q3 2026 starten. Bis dahin versenden wir bei ungeplanten Ausfällen Benachrichtigungen über destek@cerez.io .