Wie WP Footprint misst.

Diese Seite dokumentiert genau, was gemessen wird, wie es aggregiert wird, und wie die Bewertung A bis E berechnet wird. Die Methode ist öffentlich: Sie können sie kritisieren, prüfen, die Berechnung selbst nachvollziehen und Verbesserungen vorschlagen.

Aktive Methodik: v4.1. Bei jeder Änderung versioniert – die vollständige Historie liegt im Quellcode.

Differentialmessung: Baseline und anschließende Deaktivierung

WP Footprint misst eine Seite mehrfach mit allen aktiven Plugins (die Baseline). Anschließend spielt es für jedes Plugin und das aktive Theme dieselbe Seite erneut ab, nachdem die Komponente vorübergehend über einen MU-Loader deaktiviert wurde, und misst erneut.

Der eigene Einfluss einer Komponente ist die Differenz: delta = Median(Baseline) − Median(Baseline ohne diese Komponente). Dieser Differenzansatz neutralisiert den Effekt des Servers, des Themes und der anderen Plugins – genau das macht Vergleiche zwischen Sites legitim, ohne den PHP-Code tief instrumentieren zu müssen.

Mehrere Durchläufe, Median, Konfidenzintervall

Um das natürliche Rauschen eines Webservers (Cache, GC, DB-Latenz) auszugleichen, wird jede Messung wiederholt: bis zu 5 Baseline-Durchläufe und bis zu 3 Durchläufe pro deaktivierter Komponente. Das Plugin kann früher abbrechen – ab 3 Baseline- bzw. 2 Komponenten-Durchläufen – sobald die Stichprobe stabil ist (Spannweite unter max(50 ms; 10 % des Medians)): keine Präzisionseinbuße, nur keine überflüssigen Durchläufe. Ausreißer werden mit einem Tukey-Filter k=1.5 auf dem Interquartilsabstand entfernt, dann nehmen wir den Median der verbleibenden Werte (der Median ist robust gegenüber Ausreißern, anders als der Mittelwert).

Eine Halbweite des 95-%-Konfidenzintervalls wird über die Student-Verteilung t(0,975, n−1) berechnet – nicht über eine Gauß-Approximation, die die Unsicherheit bei kleinen Stichproben unterschätzen würde. Ein Delta, das nicht vom Rauschen zu unterscheiden ist, fließt nicht in die öffentliche Bewertung ein.

Server-Boden-Messung (host-floor)

Bei jedem Scan führt das Plugin zusätzlich 3 synthetische Durchgänge aus, in denen WordPress ohne aktive Plugins und mit einem Standard-Theme gestartet wird. Die Anfrage wird früh kurzgeschlossen (Action init Priorität 1) und gibt einen minimalen Body zurück — kein Routing, kein Post-Lookup, kein Template-Rendering. Erfasst wird die reine WP+Server-Bootzeit auf dieser Maschine.

Diese Messung ist unabhängig von der gescannten URL und reproduzierbar. Sie wird verwendet, um Bewertungen pro Host zu normalisieren: dasselbe Delta von +90 ms bedeutet auf einem Boden von 80 ms (+112 % Overhead) etwas ganz anderes als auf einem Boden von 250 ms (+36 %). Vorerst werden die Daten erhoben und archiviert; die Gewichtung folgt in einer späteren Revision der Berechnung.

Isolationsgrenzen: nicht messbare Plugins

Manche Plugins lassen sich nicht sicher deaktivieren: Ihre API wird direkt (auf PHP-Ebene) vom Theme oder anderen Plugins aufgerufen. Eine Deaktivierung würde die Anfrage abstürzen lassen und jede differentielle Messung unmöglich machen. Wenn der Scanner diesen Fall erkennt (Fatal beim ersten Durchlauf), bricht er die Wiederholungen ab, markiert die Komponente als nicht messbar und meldet sie nicht an Pulse. Die übrigen Komponenten werden normal gemessen.

Für beliebte Plugins, deren API von Themes häufig genutzt wird (ACF, Polylang, Yoast, Rank Math, Meta Box, Pods, WPML, The Events Calendar, Gravity Forms…), lädt der MU-Loader während des Durchlaufs Kompatibilitäts-Shims: Die Plugin-Funktionen bleiben definiert und liefern neutrale Werte, sodass die Seite ohne Fatal gerendert wird und der eigene Beitrag des Plugins weiterhin korrekt gemessen wird. Die Liste der abgedeckten Plugins steht in /api/v1/methodology unter pipeline.isolation.compatibility_shims.covered_slugs.

Die fünf gemessenen Metriken

Pro Durchlauf werden fünf Größen erfasst – zwei werden als Anteil der Baseline normalisiert, drei bleiben absolute Zählwerte:

• PHP-CPU – CPU-Zeit über getrusage() erfasst, ausgedrückt als Anteil der Baseline-CPU der Anfrage. Über Server hinweg selbstnormalisierend: 18 % CPU auf einem Xeon entsprechen 18 % auf Shared-Hosting.
• Speicher – zusätzlicher Speicher-Peak, als Anteil des Baseline-Speicher-Peaks. Gleiche Logik: der Anteil ist aussagekräftig, der Absolutwert hängt vom Server ab.
• Zusätzliche SQL-Abfragen – absoluter Zählwert. 1 Abfrage = 1 Abfrage, maschinenunabhängig.
• Zusätzliche Assets – von der Komponente eingereihte Skripte + Stylesheets. Absoluter Zählwert.
• Externe HTTP-Aufrufe – absoluter Zählwert ausgehender Netzwerkaufrufe.

Die Berechnung des Scores 0-100 pro Komponente

Konvention: 100 = perfekt, 0 = am schlechtesten, wie eine Schulnote. Für jede Metrik wenden wir eine lineare Rampe zwischen einem unteren Schwellenwert (darunter verliert die Komponente 0 Punkte) und einem oberen Schwellenwert (darüber verliert sie das maximale Gewicht) an. Die fünf Strafpunkte werden summiert (max. 100), dann gibt der Server Score = 100 − Strafe zurück. Der Score wird bei jeder Aufnahme aus den Rohdaten serverseitig neu berechnet – der Client wählt seine Bewertung niemals selbst.

Metrik	Unten (0 Pkt. verloren)	Oben (max. Verlust)	Max. Gewicht
CPU (% Baseline)	2 %	30 %	30 Pkt.
Speicher (% Baseline)	2 %	40 %	20 Pkt.
SQL-Abfragen	2	60	20 Pkt.
Assets	1	15	15 Pkt.
Externes HTTP	0	5	15 Pkt.

Warum CPU und Speicher als Anteil, während SQL/Assets/HTTP absolut bleiben? Die ersten beiden skalieren mit der Maschine; sie an der Baseline zu normalisieren hebt den Skalenfaktor auf. Die letzten drei sind ganzzahlige Zähler, intrinsisch skaleninvariant.

Der globale Seiten-Score

Der große Score in Ihrem Scan-Bericht spiegelt die tatsächliche Schwere der gerenderten Seite wider, nicht die Summe der zugewiesenen Komponenten-Einflüsse. Der Unterschied ist wichtig: bei ~10 oder mehr Plugins zählt die differentielle Zuordnung gemeinsam genutzte Hooks mehrfach (zwei Plugins, die sich einen Hook teilen, bekommen jeweils die vollen Kosten zugewiesen). Diese Deltas zu summieren und gegen die Baseline zu setzen ergab fast mechanisch einen auf 100 % gesättigten Anteil → 50 verlorene Punkte, bevor man überhaupt prüfte, ob die Seite langsam war. Methodik v4.0 löst das, indem sie direkt die absoluten Baseline-Werte liest.

Dieselben fünf Dimensionen, aber absolut: Server-Zeit, Speicherspitze, SQL-Abfragen, eingereihte Skripte/Stylesheets, externe HTTP-Aufrufe. Dieselben linearen Rampen wie beim Komponenten-Score, aber mit toleranteren Schwellenwerten (eine ganze Site macht mehr als ein einzelnes Plugin).

Metrik	Unten (0 Pkt. verloren)	Oben (max. Verlust)	Max. Gewicht
Server-Zeit	400 ms	3000 ms	30 Pkt.
Speicherspitze	24 MB	192 MB	20 Pkt.
SQL-Abfragen	80	1500	20 Pkt.
Skripte + Stylesheets	15	120	15 Pkt.
Externes HTTP	2	25	15 Pkt.

Vom Score zur Bewertung A–E

Der Score wird über absolute Grenzen auf der 0-100-Skala auf einen Buchstaben A bis E abgebildet. Würde sich das gesamte WordPress-Ökosystem optimieren, könnten alle Plugins ein A erreichen – das ist beabsichtigt: wir bewerten einen Einfluss, kein relatives Ranking.

A	85 – 100	Vernachlässigbarer Einfluss, sehr leichte Komponente
B	65 – 84	Mäßiger, vertretbarer Einfluss
C	45 – 64	Erheblicher Einfluss, zu beobachten
D	25 – 44	Bedeutender Einfluss, Alternative empfohlen
E	0 – 24	Sehr schwerer Einfluss, kritisch

Aggregation zwischen Sites

Wenn mehrere Sites dieselbe Version eines Plugins messen, behalten wir den Median pro (Plugin, Version, page_type) – getrennt für Homepage und Admin, die nicht vergleichbar sind. Der Median ist robuster gegen Ausreißer (falsch konfigurierte Sites, unterbrochene Messungen) als der Mittelwert.

Rohscans werden 3 Jahre lang in der Datenbank aufbewahrt. Wenn sich die Methodik weiterentwickelt, können wir jeden Score rückwirkend neu berechnen, ohne die Sites um einen erneuten Scan bitten zu müssen.

Konsolidierter Score auf der öffentlichen Seite

Der auf einer Plugin- oder Theme-Seite angezeigte Score ist über die letzten 90 Tage konsolidiert. Jeder gültige Scan in diesem Zeitfenster fließt in den Median ein, unabhängig davon, auf welcher Version er erfasst wurde. Ohne dieses gleitende Fenster würde jede neue Veröffentlichung den öffentlichen Score auf null zurücksetzen, und ein aktiv gepflegtes Plugin würde dauerhaft als „noch nicht genug Daten" erscheinen.

Das auf der Karte angezeigte Versions-Label (z. B. „v4.1.0") ist die neueste Version, die im Fenster vertreten ist – damit der Leser erkennt, welches Release gerade gemessen wird –, während der Score selbst stabil bleibt. Die Detailansicht pro Version bleibt in der Verlaufstabelle weiter unten auf der Seite zugänglich.

Schutzmechanismen vor der Veröffentlichung

Drei Filter werden angewendet, bevor ein Scan in den öffentlichen Median einfließt. Abgelehnte Scans bleiben für ein Audit erhalten, beeinflussen aber die angezeigte Bewertung nicht.

• Zu leichte Baseline: wenn die Baseline-Anfrage weniger als 50 ms CPU verbraucht, werden die Anteile extrem und verrauscht → Scan ausgeschlossen.
• Aufgeblähte Baseline: wenn die Baseline-Anfrage 3 × den globalen Median für denselben Seitentyp überschreitet, ist die Site wahrscheinlich bereits mit anderen Plugins gesättigt → Scan ausgeschlossen (sonst würde ein schweres Plugin vernachlässigbar erscheinen).
• Statistische Plausibilität: sieben metrikübergreifende Heuristiken (z. B. „50 MB allokiert ohne CPU-Verbrauch" ist physikalisch unmöglich) bewerten jeden Scan mit 0-100. Unter 40/100 wird der Scan als verdächtig abgelehnt.

Verifizierte Identität beitragender Sites

Jede beitragende Site erzeugt lokal ein Ed25519-Schlüsselpaar und signiert jede Übermittlung. Die Identität wird einmal bei der Anmeldung über eine kryptografische Challenge auf admin-ajax.php verifiziert. Kein gemeinsames Geheimnis – eine falsche Identität zu fälschen erfordert den Besitz einer echten WordPress-Domain, was eine Manipulation des Rankings wirtschaftlich unattraktiv macht. Siehe die Datenschutzrichtlinie für das, was übermittelt wird (und entscheidend, was nicht).

Aus der öffentlichen Rangliste ausgeschlossene Komponenten

Website-Betreiber können ein Plugin oder Theme — typischerweise ein hauseigenes Modul oder ein proprietäres Produkt — in den Einstellungen des WordPress-Plugins als privat markieren. Die Komponente wird dann mit einem private: true-Flag an Pulse gesendet.

Der Server berechnet und gibt die Bewertung zurück (damit der lokale Bericht vollständig ist), persistiert aber nichts: keine Zeile in plugin_scans, kein Eintrag im öffentlichen Katalog, kein Beitrag zu den Community-Medianen. Der Slug wird nur über die signierte Anfrage übertragen und dann vergessen. Diese Trennung zwischen „keine Bewertung“ und „nicht veröffentlicht“ wurde in Methodologie v3.2 eingeführt.

Veröffentlichungsschwelle

Solange eine Plugin- oder Theme-Version weniger als 15 eindeutige Scans aufweist (verschiedene verifizierte Sites), wird ihre Bewertung nicht öffentlich angezeigt. WP Footprint Pulse zeigt stattdessen „unzureichende Daten" an, um keine irreführenden Schlüsse aus einer zu kleinen Stichprobe zuzulassen.

Berechnen Sie selbst nach

Jeder oben beschriebene Schwellenwert, jedes Gewicht und jeder Schutzmechanismus wird als JSON über den öffentlichen Endpunkt https://www.wpfootprint.com/api/v1/methodology bereitgestellt, versioniert nach Methodik. Sie können den Scoring-Code auch direkt im Repository lesen – er liegt in vier Dateien mit jeweils unter 200 Zeilen.

Ehrlich benannte Grenzen

• Kein feingliedriges PHP-Tracing. Die Attribution ist differential: wenn Plugin A einen Hook auslöst, der Code von Plugin B ausführt, kann der gemessene Einfluss bei einem oder anderen landen. Das ist der Kompromiss, um nicht-intrusiv zu bleiben (kein Xdebug erforderlich).
• Verbleibender Umgebungs-Bias. CPU-/Speicheranteile heben den Server-Frequenz-Bias auf, bleiben aber empfindlich gegenüber der PHP-Hauptversion (PHP 7.4 verteilt Kosten nicht wie PHP 8.3). Stratifizierung nach PHP-Version ist für v1.1 geplant.
• Selbstselektierte Stichprobe. Sites, die WP Footprint installieren, sind wahrscheinlich technischer als der Durchschnitt. Das Ranking ist „wahr für die Sites, die scannen", nicht für ganz WordPress.
• Keine Messung des gelieferten Mehrwerts. Ein schweres Plugin, das viel tut, und ein leichtes Plugin, das wenig tut, teilen sich dieselbe Bewertung, wenn ihre Deltas übereinstimmen. Eine Kategorisierung wird helfen, das Problem aber nicht vollständig lösen.
• Asynchrone Plugins. Plugins, die den Großteil ihrer Arbeit in verzögertem Cron oder Queues verrichten (Worker, Webhooks), haben einen unterschätzten frontalen Einfluss bei einem Single-Page-Scan.
• Nicht isolierbare Plugins. Manche Plugins erzeugen einen Fatal, wenn sie deaktiviert werden, weil ihre API auf PHP-Ebene vom Theme oder einem anderen Plugin verwendet wird. Sie werden im lokalen Bericht als „nicht messbar" markiert und vom öffentlichen Ranking ausgeschlossen. Ihre Liste wird anonym übermittelt, um neue Kompatibilitäts-Shims zu priorisieren.

Anregungen und Kritik willkommen – schreiben Sie an [email protected]. Jede angenommene Verbesserung wird im Methodik-Changelog dokumentiert.