Beaconry-Performance vs Site Kit, GTM und Stape: 5 KB an deinen Besucher, 30 KB bis 150 KB bei den anderen

Tracking-Plugins sind der zweitgrößte Grund, warum WordPress-Sites langsam sind, nach Bilder-Gewicht. Hier die gleiche WordPress-Installation, gleiches Theme, gleiches WooCommerce, mit vier verschiedenen Tracking-Stacks gemessen in Lighthouse 12. Beaconry liefert 5 KB an den Browser aus, die anderen 30 bis 150.

Das Setup

Eine WordPress-Installation, Astra-Theme, WooCommerce 9.x mit 50 Demo-Produkten, der Cookie-Banner identisch über Runs (Beaconrys nl-data-gate für unseren Run, Complianz für die anderen). Lighthouse 12, Mobile, gedrosselt 4G + 4× CPU-Slowdown, 5-Run-Median.

Jeder Stack so konfiguriert, dass er die äquivalente Arbeit tut: Page-View-Event an GA4 + Meta CAPI, plus WooCommerce-Purchase-Events auf der Thank-You-Page. Gleiche Conversion-Outcomes, vier verschiedene Pfade.

JavaScript an den Besucher ausgeliefert

Die einzelne folgenreichste Metrik sowohl für Lighthouse als auch für die Besucher-Erfahrung.

• Beaconry: ~5 KB. Zwei Skripte: nl-data-gate.js (Consent-Banner, ~2 KB gzip) und nl-data.js (Event-Posting + Click-ID-Capture, ~3 KB gzip). Beide deferred, nicht render-blocking.
• Site Kit by Google: ~150 KB. gtag.js (~70 KB), GTM-Container (~28 KB), AdSense-Runtime (~30 KB), Search-Console-Snippet (~10 KB), plus Init-Code. Lädt vier Google-Produkte, ob du sie nutzt oder nicht.
• GTM Server-Side: ~38 KB. gtm.js-Bootstrap lädt von deiner Custom-Subdomain, dann injected per-Tag-Skripte abhängig von Tag-Template-Konfiguration.
• Stape: ~32 KB. Gleiches gtm.js wie GTM-SS, einfach CNAME'd auf einen Stape-Worker.

Beaconry ist 6× leichter als die nächstbeste Server-Side-Option, 30× leichter als Site Kit. Der Unterschied ist strukturell: Server-Side-Dispatch braucht fast nichts im Browser, gerade genug, um Click-IDs zu fangen und Events an /wp-json zu posten.

Lighthouse-Mobile-Score

Lighthouse 12, Mobile-Profil, 5-Run-Median auf einer Single-Product-Page:

• Beaconry: 98. Nicht unterscheidbar von einer No-Tracking-Baseline. 2-Punkte-Verlust durch den deferred Parse des Consent-Banner-Skripts.
• Stape: 86. 12-Punkte-Drop von Baseline. gtm.js-Parse plus async Sub-Resource-Fetches.
• GTM Server-Side: 85. Funktional gleich wie Stape; +1 durch leicht schnelleren CNAME-Hop.
• Site Kit: 72. 26-Punkte-Drop. Multiple Google-CDN-Hits, multiple Parse-Passes, render-blockendes gtag.

LCP, die Metrik, die Conversions schadet

LCP (Largest Contentful Paint) ist das, was Googles Core-Web-Vitals-Scoreboard fürs Ranking nutzt. Der Hit, den jeder Tracking-Stack hinzufügt:

• Beaconry: + 0 ms. Alle Skripte deferred, kein Render-Blocking, LCP-Element feuert, bevor irgendein Tracking-JS läuft.
• GTM Server-Side: + 90 ms. gtm.js parsed async, verbraucht aber Main-Thread-Budget bei FCP.
• Stape: + 75 ms. Etwas weniger als GTM-SS wegen lokalem CNAME-Hop.
• Site Kit: + 380 ms. Render-blockendes gtag fügt ~280 ms hinzu, AdSense-Init ~80 ms, render-blocking-Natur potenziert die Kosten.

Für eine Site, die schon an der LCP-Schwelle liegt (2,5 s Mobile), kann Site Kits +380 ms dich in "Needs Improvement"-Territorium in der Search Console kippen, mit entsprechender Ranking-Strafe.

Sub-Resource-Requests

Jeder Request ist ein DNS-Lookup, TLS-Handshake und Cold-Connection-Cost. Adblocker zählen Requests, wenn sie entscheiden, was "tracking-heavy" ist.

• Beaconry: 2 (Consent-Skript, Tracking-Init).
• Stape: 3-4 (gtm.js + Tag-Template-Abhängige).
• GTM Server-Side: 3-5 (ähnlich).
• Site Kit: 8-12 (Google-CDN, GTM-CDN, AdSense-CDN, Search Console, plus deren jeweilige Tag-Skripte).

Client-side gesetzte Cookies

Cookie-Anzahl beeinflusst jede nachfolgende Request-Größe, weil Cookies in Headern reisen.

• Beaconry: 2 (nl_pref für Consent-Status, nl_ext für Click-IDs). Beide First-Party, consent-gated.
• GTM-SS / Stape: 3-8 abhängig von Tags.
• Site Kit: 12+ (_ga, _gid, _gat, _gcl_au, _fbp, _fbc, plus AdSense- und Search-Console-Cookies).

Bei einer Site, die bei jedem Page-Load 12+ Cookies im Request-Header sendet, schaust du auf 1-2 KB extra HTTP-Overhead pro Navigation. Akkumuliert über die Besucher-Session.

Was die Kosten dir auf jedem Stack tatsächlich kaufen

Site Kits 150 KB liefern: gtag-Dispatch (Beaconry ersetzt das server-side), GTM-Container-Management (Beaconry braucht keinen), AdSense (Beaconry hat kein Äquivalent, du würdest AdSense separat fahren), Search-Console-Verifikation (einmalig, auch via DNS-TXT machbar). Für einen Kunden, der nur Conversion-Tracking will, zahlt 80 % von Site Kits Payload für Features, die er nicht nutzt.

GTM-SS und Stapes 32-38 KB liefern: Tag-Template-Flexibilität für Nischen-Kanäle, UI-getriebene Tracking-Änderungen für Nicht-Engineers. Den Aufwand wert, wenn du diese Features brauchst. Verschwendete Bytes, wenn du die Standard-5-Kanäle trackst.

Beaconrys 5 KB liefern: Click-ID-Capture, Consent-Banner, Event-Posting. Das Minimum, das für Server-Side-Dispatch nötig ist. Nichts anderes, weil nichts anderes im Browser leben muss.

Der Core-Web-Vitals-SEO-Winkel

Googles Ranking-Algorithmus nutzt Core Web Vitals als eines von vielen Ranking-Signalen. Das Signal ist am sichtbarsten bei umkämpften Head-Tail-Keywords, in denen viele Sites technisch kompetent sind. Wenn die Site deines Wettbewerbers schneller lädt, weil er kein Site Kit fährt, bei sonst gleichen Bedingungen, rankt er über dir.

Für einen E-Commerce-Shop, der Paid-Search und SEO parallel fährt, hat ein Wechsel von Site Kit zu Beaconry einen messbaren Doppel-Effekt: SEO-Verbesserung durch das Lighthouse-Delta, plus die 25-30 % Adblock-Recovery auf Paid-Conversions. Gleiches Plugin-Install, zwei Upside-Vektoren.

Fazit

Server-Side-Dispatch ist nicht nur über Adblock-Recovery, sondern auch darüber, nicht 30-150 KB JavaScript an jeden Besucher für das Privileg, getrackt zu werden, auszuliefern. Beaconrys 5-KB-Browser-Footprint ist das, was Lighthouse 98 auf einem typischen WooCommerce-Shop ohne Tracking-Verzicht möglich macht. Site Kits All-in-one-Versprechen kostet 150 KB, von denen die meisten Shops die Hälfte nicht tatsächlich nutzen.