Performance-Säule

5,5 KB minifiziert.
2,4 KB gzipped.

Ein Tracker, der so klein ist, dass Ihre Besucher nicht bemerken, dass er geladen wurde. Geringster LCP-Overhead von 8 von uns getesteten WordPress-Analytics-Plugins. sendBeacon-Transport. Der Inline-Core-Stub (~0,9 KB gzipped) erfasst den Seitenaufruf, bevor der asynchrone Tracker geladen wird.

k6 + Chromium • einmaliger synthetischer Test • kein Page-Caching • Ergebnisse sind richtungsweisend, keine Garantie für Produktion

LCP-Overhead unter Last (niedriger ist besser)

Statnive
+260ms
Independent Analytics
+566ms
Jetpack
+776ms
MonsterInsights (GA4)
+964ms
WP Slimstat
+1030ms
WP Statistics
+1424ms
Koko Analytics
+2278ms
Burst Statistics
+3592ms
~7KB Tracker-Größe 1,7 KB inline + 5,5 KB async (unkomprimiert)
async Laden WP 6.3+ Strategie-API
0,00 CLS-Wert Kein Layout-Shift
Beacon Transport Nicht-blockierender sendBeacon
Direktvergleich

Synthetischer Stresstest – Ergebnisse

Wir haben jedes Plugin isoliert auf derselben WooCommerce-Site aktiviert und Core Web Vitals mit echten Chromium-Browsern gemessen, während 50 gleichzeitige HTTP-Nutzer den Server belasteten. Kein Page-Caching. Die Zahlen zeigen den LCP-/TTFB-/FCP-Overhead gegenüber einer Baseline ohne Analytics in einem einzigen Lauf. Dies sind richtungsweisende Ergebnisse, keine Produktions-Garantien — siehe Abschnitt zu Limitierungen unten.

Plugin LCP Δ TTFB Δ FCP Δ Impact Typ
#1 Statnive +260ms +290ms +256ms 6.7 Selbst gehostet
#2 Independent Analytics +566ms +568ms +574ms 14.2 Selbst gehostet
#3 Jetpack +776ms +785ms +784ms 19.5 Remote (WP.com)
#4 MonsterInsights (GA4) +964ms +963ms +964ms 24.1 Remote (Google)
#5 WP Slimstat +1030ms +1005ms +1010ms 25.4 Selbst gehostet
#6 WP Statistics +1424ms +1446ms +1432ms 35.9 Selbst gehostet
#7 Koko Analytics +2278ms +2229ms +2238ms 56.3 Selbst gehostet
#8 Burst Statistics +3592ms +3572ms +3576ms 89.6 Selbst gehostet

Baseline (ohne Analytics) unter Last: TTFB 2927 ms, FCP 3030 ms, LCP 3038 ms. Test: 10 Chromium-Browser-VUs + 50 HTTP-Protokoll-VUs pro Plugin, ~150 Samples pro Konfiguration, einzelner Lauf auf einem Entwickler-Rechner (Local by Flywheel, macOS). Der Impact-Score ist ein zusammengesetzter Wert (0 = kein Einfluss, 100 = maximal). Diese Zahlen stammen aus einem einzigen synthetischen Stresstest und repräsentieren keine Produktionsbedingungen — siehe Abschnitt zu Methodik und Limitierungen unten.

Ehrliche Offenlegung

Was dieser Test zeigt und was nicht

Ein vertrauenswürdiger Benchmark legt seine Grenzen offen. Hier ist genau, was unsere Zahlen bedeuten — und was nicht.

Was er zeigt

Richtungsweisende Unterschiede darin, wie die Architektur jedes Plugins den vollständigen WordPress-PHP-Pfad unter gleichzeitiger Last ohne Page-Caching handhabt. Nützlich, um zu verstehen, welche Plugins den kritischen Rendering-Pfad freihalten und welche zusätzliche Server-Arbeit pro Anfrage hinzufügen.

Was er nicht zeigt

Echte Produktionsleistung. Die meisten WordPress-Sites verwenden einen Page-Cache (W3TC, WP Rocket, Cloudflare), der PHP für gecachte Seiten vollständig umgeht. Mit Caching schrumpft der Abstand zwischen den meisten Plugins drastisch.

Einzelner Lauf, einzelne Maschine

Ergebnisse stammen aus einem ~50-minütigen Lauf auf einem MacBook über Local by Flywheel. Wir haben keine mehrfachen Iterationen zur Messung der Varianz durchgeführt und auch nicht auf einem dedizierten Produktions-Server getestet. Ein zweiter Lauf könnte Positionen verschieben.

Reihenfolgeeffekte nicht kontrolliert

Die Plugins wurden in einer festen Reihenfolge getestet. Der Server-Zustand (MySQL-Verbindungspool, PHP-Speicher, OPcache) driftet während eines langen Laufs, was später getestete Plugins benachteiligen kann. Ein ordentlicher Benchmark würde die Reihenfolge über mehrere Läufe randomisieren.

Selbsttest-Bias

Wir haben das Test-Framework gebaut, und wir haben Statnive gebaut. Wir glauben, fair vorgegangen zu sein, aber unabhängige Verifikation wäre vertrauenswürdiger als alles, was wir selbst veröffentlichen. Das Framework ist Open Source — bitte führen Sie es auf Ihrer eigenen Site aus und veröffentlichen Sie, was Sie finden.

Warum wir trotzdem veröffentlichen

Auch mit diesen Einschränkungen sind die architektonischen Muster relevant. Inline-Core-Tracker, asynchrones Laden, Beacon-API-Transport und nebenläufigkeitssichere REST-Endpunkte sind dokumentierte Best Practices. Die konkreten Zahlen variieren; die Richtung ist konsistent damit, wie jede Architektur entworfen ist.

Engineering

Wie wir einen schnellen Tracker gebaut haben

Drei architektonische Entscheidungen halten Statnives Performance-Einfluss gering — gestützt auf veröffentlichte Forschung von Google, WordPress Core und web.dev.

Inline-Core

~1,7 KB unkomprimiert / 0,9 KB gzipped

Ein winziger Inline-Bootstrap erfasst den Seitenaufruf sofort. Kein externes Skript für den kritischen Treffer erforderlich.

Asynchrones Laden

Nicht-blockierend

Der vollständige Tracker lädt mit der async-Strategie über die WordPress 6.3+ Skript-API. Blockiert niemals das Rendering.

Idle-Callback

Null INP

Engagement-Tracking und Event-Listener werden über requestIdleCallback verzögert. Die Interaktionen Ihrer Besucher haben Vorrang.

Warum es wichtig ist

Langsame Analytics kosten Sie Geld

SEO-Rankings

Google verwendet Core Web Vitals als Ranking-Signal. Ein langsames Analytics-Skript drückt Ihren LCP über die „gut"-Schwelle von 2,5 s und schadet Ihrer Position in den Suchergebnissen.

Konversionsrate

Jede zusätzliche Sekunde Ladezeit reduziert Konversionen um bis zu 7 %. Ein Analytics-Overhead von 300 ms auf jeder Seite summiert sich über Ihren gesamten Funnel.

Datenschutz-Bonus

Selbst gehostete Analytics bedeutet null externe Netzwerkanfragen an Server von Drittanbietern. Schnelleres Laden und DSGVO-Konformität in einer Architekturentscheidung.

Methodik

Wie wir getestet haben

Volle Transparenz. Jede Zahl auf dieser Seite stammt aus reproduzierbaren automatisierten Tests.

Werkzeug

k6 mit Browser-Modul (echtes Chromium, kein simuliertes HTTP)

Last

10 Browser-VUs zur Messung der Vitals + 50 HTTP-VUs zur Erzeugung realistischen Server-Drucks

Isolation

Jedes Plugin allein über die WordPress REST API aktiviert. Alle anderen deaktiviert.

Seiten

Startseite, Blog-Post, WooCommerce-Shop + Produktseiten

Samples

~150 Seitenladevorgänge pro Plugin-Konfiguration mit Cache-Vorbefüllung vor der Baseline

Metriken

TTFB, FCP, LCP, CLS, INP über die PerformanceObserver-API erfasst

Tracken, ohne langsamer zu werden

Installieren Sie Statnive in unter einer Minute. Dauerhaft kostenlos auf WordPress.org.

Statnive kostenlos herunterladen