Performance Monitoring für Enterprise WordPress: APM, Alerts und Core Web Vitals

Ein langsamer Checkout oder ein steigender Interaction to Next Paint (INP) auf der Website eines einzelnen Marktes kostet Umsatz und Sichtbarkeit in der Suche, lange bevor jemand ein Ticket schreibt. Moderne WordPress-Installationen verteilen sich auf CDN, PHP-Worker, Datenbank, Object Cache und manchmal ein separates Frontend, deshalb ist “läuft der Server?” seit Jahren keine nützliche Frage mehr. Dieser Leitfaden beschreibt einen Monitoring-Stack für solche Setups. Jeder Schwellenwert und jede Einstellung stammt aus der im Text verlinkten Dokumentation des Herstellers oder des Standards.

#RUM oder synthetisches Monitoring für WordPress

Für ein vollständiges Bild Ihres Systems brauchen Sie zwei Perspektiven. Sie konkurrieren nicht: Jede sieht etwas, das die andere nicht sehen kann.

#Real User Monitoring (RUM)

RUM erfasst die Erfahrung jedes einzelnen Besuchers, auf seinem Gerät und in seinem Netz.

• Geräte-Fragmentierung: wie Ihre Website auf einem neuen iPhone im Vergleich zu einem Android-Mittelklassegerät mit überlasteter Mobilfunkverbindung abschneidet.
• Interaktivität: jede Interaktion, die in den INP einfließt, damit Sie die konkreten Oberflächenelemente finden, die sich für Nutzer langsam anfühlen.
• Edge-Performance: die tatsächliche Latenz zwischen einem Besucher und dem nächsten CDN-Standort, pro Land.

Ein Durchschnitt über die ganze Website verdeckt das meiste, was zählt. Teilen Sie die RUM-Daten nach Geräteklasse, Verbindungstyp, Land, Template (Beitrag, Archiv, Produkt, Warenkorb) sowie Erst- und Wiederholungsbesuch auf. Berichten Sie das 75. Perzentil, denn mit diesem Wert bewertet Google die Core Web Vitals. Der web.dev-Artikel zu Web Vitals formuliert die Messregel so:

“das 75. Perzentil der Seitenaufrufe, aufgeteilt nach Mobil- und Desktopgeräten”

Quelle: Web Vitals, web.dev (eigene Übersetzung)

#Synthetisches Monitoring und Uptime-Checks

Synthetische Tests laden Ihre Seiten mit skriptgesteuerten Browsern unter kontrollierten Bedingungen.

• CI/CD-Integration: ein Lighthouse-Lauf bei jedem Push, mit dem ein Entwickler Theme- oder Plugin-Code ändert.
• Uptime- und Journey-Checks: skriptgesteuerte Durchläufe der Pfade, die Umsatz bringen (“In den Warenkorb”, “Kontaktformular senden”), aus den Regionen, in denen Sie verkaufen, in festem Takt.

Synthetische Checks sehen keine echten Nutzer und ersetzen RUM deshalb nie. Ihre Stärke: Die Testbedingungen bleiben konstant. Verschlechtert sich ein synthetisches Ergebnis, liegt die Ursache im Code oder in der Infrastruktur und nicht darin, wer an diesem Tag die Website besucht hat.

#Core Web Vitals mit der web-vitals Bibliothek erfassen

Für den Einstieg brauchen Sie kein schweres Drittanbieter-Skript. Googles web-vitals Bibliothek beschreibt sich selbst als winzige, modulare Bibliothek (etwa 3K, mit Brotli komprimiert) und misst jede Metrik so, wie Googles eigene Werkzeuge sie berichten. Sie liest die Performance-APIs des Browsers auf der Seite und übergibt jedes Ergebnis an einen Callback; navigator.sendBeacon schickt den Wert dann an Ihren Collector. Laut README der Bibliothek funktioniert diese Methode auch, während die Seite gerade entladen wird.

import { onCLS, onINP, onLCP } from 'web-vitals';

function sendToTelemetry(metric) {
  const body = JSON.stringify({
    name: metric.name,
    value: metric.value,
    rating: metric.rating,
    delta: metric.delta,
    id: metric.id,
    page: window.location.pathname
  });

  if (navigator.sendBeacon) {
    navigator.sendBeacon('/api/telemetry/vitals', body);
  } else {
    fetch('/api/telemetry/vitals', { body, method: 'POST', keepalive: true });
  }
}

onCLS(sendToTelemetry);
onINP(sendToTelemetry);
onLCP(sendToTelemetry);

Das Beispiel überträgt nur pathname, ohne Query-String. Diese Entscheidung ist für den Datenschutz wichtig, dazu unten mehr.

Der Attribution-Build derselben Bibliothek macht aus einer schlechten Zahl ein Ticket, das jemand bearbeiten kann. Für LCP liefert er den Selektor des LCP-Elements (target), die Bild-URL, falls vorhanden, die Time to First Byte, Verzögerung und Dauer des Ressourcen-Ladens sowie die Render-Verzögerung des Elements. Für INP liefert er das Element, mit dem der Nutzer interagiert hat, Input Delay, Verarbeitungsdauer und Presentation Delay, dazu longAnimationFrameEntries, die Long-Animation-Frame-Einträge, die sich mit der Interaktion überschnitten haben, in Browsern, die diese API unterstützen. Aus “INP ist auf Produktseiten schlecht” wird “der Variantenwähler verbringt die meiste Zeit in einem bestimmten Skript”.

#Warum Search Console und PageSpeed Insights nicht reichen

Search Console und PageSpeed Insights zeigen Felddaten aus dem Chrome UX Report (CrUX). Die Dokumentation der CrUX API beschreibt diese Daten als gleitenden 28-Tage-Durchschnitt aggregierter Metriken, täglich gegen 04:00 UTC aktualisiert. Eine heute Morgen ausgerollte Regression bewegt diesen Durchschnitt nur langsam, Sie erfahren davon also Tage oder Wochen nach ihrem Beginn.

Die Abdeckung ist die zweite Grenze. Nach der CrUX-Methodik muss eine Seite oder ein Origin öffentlich auffindbar und ausreichend populär sein, um im Datensatz zu erscheinen, und Daten liefern nur Chrome-Nutzer, die zugestimmt haben, auf Desktop und Android. Chrome unter iOS, Apps mit Android WebView und andere Chromium-Browser wie Edge liefern keine Daten. Ein B2B-Portal hinter einem Login, eine Länderseite mit wenig Traffic oder ein Publikum, das überwiegend iPhones nutzt, zeigt womöglich kaum oder gar keine CrUX-Daten.

CrUX bleibt die richtige Referenz für SEO, weil Google die Core Web Vitals aus diesem Datensatz berichtet. Für die Reaktion am Tag des Deployments brauchen Sie einen eigenen RUM-Datenstrom ohne Mittelungsfenster.

#RUM und DSGVO: was der Beacon übertragen darf

Jeder RUM-Beacon ist eine Anfrage aus dem Browser des Besuchers an Ihren Collector. Enthält er IP-Adresse, Session-ID oder die vollständige URL mit Query-Parametern (etwa eine E-Mail-Adresse aus einem Newsletter-Link), verarbeiten Sie personenbezogene Daten nach DSGVO. Für das Speichern und Auslesen von Informationen auf dem Endgerät, also Cookies oder localStorage, gilt zusätzlich § 25 TDDDG, das frühere TTDSG. Zuständig sind die Datenschutzbehörden der Länder; ihre gemeinsamen Positionen veröffentlicht die Datenschutzkonferenz (DSK).

Halten Sie den Beacon schlank:

• Metrik statt Person: Metrikname, Wert, Seitentyp, Land, Geräteklasse. Für das 75. Perzentil des LCP braucht niemand eine IP-Adresse.
• Query-Strings vor dem Versand entfernen und nur den Pfad behalten.
• Kein Cookie nur zum Verknüpfen von Besuchen. Die Unterscheidung zwischen neuen und wiederkehrenden Sitzungen fällt weg, dafür hängt die Telemetrie nicht mehr an der Einwilligung für den Gerätezugriff.
• Den Collector so konfigurieren, dass IP-Adressen gar nicht erst gespeichert oder beim Eingang gekürzt werden.
• Speichert Ihr Anbieter Daten in den USA, prüfen Sie, ob eine EU-Datenregion verfügbar ist und ein Auftragsverarbeitungsvertrag unterschrieben ist, und dokumentieren Sie die Übermittlungsgrundlage im Verzeichnis der Verarbeitungstätigkeiten.

Das ist keine Rechtsberatung. Wo die Grenze in Ihrem Setup verläuft, klärt der Datenschutzbeauftragte.

#Langsame Releases mit Lighthouse CI blockieren

Lighthouse CI führt Lighthouse in Ihrer Pipeline gegen Preview- oder Staging-URLs aus und vergleicht die Ergebnisse mit Assertions, die Sie festlegen. Standardmäßig startet lhci collect Lighthouse dreimal pro URL (numberOfRuns), was einzelne verrauschte Läufe glättet. Jede Assertion hat eine Stufe: warn gibt das Ergebnis aus, ohne zu scheitern, error beendet den Befehl mit einem Exit-Code ungleich null, und genau das lässt den Build fehlschlagen.

Das Preset lighthouse:recommended ist ein sinnvoller Startpunkt. Laut Dokumentation von Lighthouse CI prüft es, dass jedes Audit außerhalb der Performance die volle Punktzahl erreicht, und warnt, wenn Metrikwerte unter einen Score von 90 fallen. Audits, die nicht zum Projekt passen, schalten Sie einzeln ab. Ergänzen Sie explizite Limits für das, was Ihr Team direkt steuert, etwa das Gesamtgewicht von JavaScript und CSS auf den umsatzrelevanten Templates.

Lighthouse läuft im Labor, seine Zahlen stimmen also nicht mit CrUX überein. Nutzen Sie es, um einen Build unter gleichen Bedingungen mit dem vorherigen zu vergleichen, nicht um Felddaten vorherzusagen.

#Visuelle Regressionstests mit Playwright

Performance heißt auch Stabilität. Ein Plugin-Update, das auf Mobilgeräten plötzlich das Layout verschiebt, schadet CLS und Conversions zugleich.

Playwright bringt diese Prüfung als Assertion toHaveScreenshot mit. Beim ersten Lauf erzeugt sie Referenz-Screenshots, spätere Läufe vergleichen dagegen. Nach einer gewollten Designänderung erzeugen Sie die Baseline mit npx playwright test --update-snapshots neu. Die Option maxDiffPixels legt fest, wie viele Pixel abweichen dürfen, bevor der Test fehlschlägt. Die Playwright-Dokumentation warnt außerdem, dass das Rendering je nach Betriebssystem, Browserversion, Einstellungen und Hardware variiert. Erzeugen Sie Baselines deshalb in derselben Umgebung, in der die Tests laufen, meist im CI-Container und nicht auf dem Laptop eines Entwicklers.

Das praktische Setup ist überschaubar: Screenshots der umsatzrelevanten Templates (Startseite, Kategorie, Produkt, Warenkorb, Checkout) in drei Viewport-Breiten. Kleine Abweichungen innerhalb der Toleranz gehen durch, größere warten im Pull-Request auf eine menschliche Entscheidung.

#Query Monitor und Website-Zustand für die WordPress-Diagnose nutzen

Query Monitor von John Blackbourn ist das Standard-Diagnose-Plugin für einen einzelnen Request. Pro Seitenaufruf listet es die Datenbankabfragen und markiert langsame, doppelte oder fehlerhafte, zeigt PHP-Fehler mit verantwortlicher Komponente und Call Stack und listet HTTP-API-Anfragen mit Antwortcode, verantwortlicher Komponente und Dauer. Dazu kommen Hooks und Actions, die Template-Hierarchie, eingebundene Skripte und Styles sowie Transient-Updates. Standardmäßig sehen die Ausgabe nur Administratoren auf Einzelseiten und Super-Admins im Multisite; ein Authentifizierungs-Cookie kann den Zugriff auf andere Nutzer erweitern.

Wir setzen Query Monitor auf Staging zur Diagnose ein, nicht als dauerhaftes Produktions-Monitoring: Es erklärt einen Request in der Tiefe, ein APM-Agent aggregiert alle.

Der Website-Zustand (Werkzeuge, Website-Zustand) ergänzt eine kostenlose Frühwarnschicht. Sein Status-Tab gruppiert die Befunde in kritische Probleme, empfohlene Verbesserungen und bestandene Tests. Seit WordPress 6.6 meldet der Website-Zustand ein kritisches Problem, wenn die Gesamtgröße der automatisch geladenen Optionen 800 KB übersteigt, wie die Entwicklernotiz zu WordPress 6.6 über Autoload-Optionen beschreibt. Dieselbe Version lädt einzelne Optionen über 150.000 Bytes standardmäßig nicht mehr automatisch, eine separate Grenze, die der Filter wp_max_autoloaded_option_size steuert. Aufgeblähte Autoload-Daten werden bei jedem Request geladen, deshalb lohnt der Blick auf diese Prüfung nach jedem Plugin-Audit.

#WordPress-APM mit dem New Relic PHP-Agenten

Ein APM-Agent zeichnet in der Produktion jeden Request auf und zeigt, wohin die Zeit geflossen ist. Die WordPress-Unterstützung des New Relic PHP-Agenten ist ein gutes Beispiel für WordPress-bewusste Instrumentierung:

• newrelic.framework.wordpress.hooks ist ab Agent-Version 5.3 standardmäßig aktiv; mit false schalten Sie die WordPress-spezifischen Metriken ab.
• Hook-Metriken zeigen die Zeit innerhalb jedes WordPress-Hooks, gemessen ab apply_filters, apply_filters_ref_array, do_action und do_action_ref_array.
• Plugin- und Theme-Metriken zeigen die Zeit innerhalb jedes Plugins und Themes und beantworten damit “welches Plugin hat diese Seite langsam gemacht” ohne Raten.
• Seit Agent 10.16 steuert newrelic.framework.wordpress.hooks.options, wie viel aufgezeichnet wird. Im Modus threshold erfasst der Agent nur Hooks, die langsamer sind als newrelic.framework.wordpress.hooks.threshold, standardmäßig 1 ms. Das hält Overhead und Datenmenge auf stark besuchten Websites klein.

Datadog, Tideways (der PHP-Profiler aus Deutschland) und Blackfire decken mit eigenen Agenten ähnliches Terrain ab. Die Wahl hängt meist davon ab, was der Rest der Organisation schon einsetzt, denn ein Werkzeug für alle Dienste schlägt ein besseres Werkzeug, das sonst niemand liest.

#WordPress mit OpenTelemetry PHP tracen

OpenTelemetry ist die herstellerneutrale Option: Dieselben Traces können an Grafana Tempo, Jaeger oder ein kommerzielles Backend gehen. Die Dokumentation zur PHP-Auto-Instrumentierung setzt PHP 8.0 oder höher und die mit pecl install opentelemetry installierte Extension voraus. Konfiguriert wird über Umgebungsvariablen:

OTEL_PHP_AUTOLOAD_ENABLED=true
OTEL_SERVICE_NAME=wordpress-shop
OTEL_TRACES_EXPORTER=otlp
OTEL_EXPORTER_OTLP_ENDPOINT=http://collector:4318

Für WordPress gibt es ein eigenes Paket, open-telemetry/opentelemetry-auto-wordpress, installiert mit composer require open-telemetry/opentelemetry-auto-wordpress. Der WordPress-Kern nutzt kein Composer, deshalb zeigt das README des Pakets, wie der Composer-Autoloader vor dem Start von WordPress geladen wird, zum Beispiel mit php_value auto_prepend_file /var/www/vendor/autoload.php unter Apache. Mit OTEL_PHP_DISABLED_INSTRUMENTATIONS=wordpress lässt sich die Instrumentierung wieder abschalten.

Für einmaliges Profiling auf der Kommandozeile braucht der WP-CLI-Befehl wp profile kein Plugin. Sie installieren ihn mit wp package install wp-cli/profile-command; danach misst wp profile stage die Phasen Bootstrap, Main Query und Template, wp profile hook Actions und Filter und wp profile queries die Datenbankabfragen. Das funktioniert auch auf Servern, auf denen Sie kein Plugin installieren dürfen. Xdebug liefert das detaillierteste Profil von allen, ist wegen des Overheads aber nur etwas für lokale Rechner.

#Welche Datenbank- und Object-Cache-Metriken Sie überwachen sollten

Das MySQL Slow Query Log ist standardmäßig deaktiviert. Es protokolliert Statements, die länger als long_query_time Sekunden dauern und mindestens min_examined_row_limit Zeilen prüfen. Der Standardwert von long_query_time beträgt 10 Sekunden, viel zu großzügig für einen Web-Request; das Minimum ist 0, und der Wert akzeptiert Mikrosekunden-Auflösung. Jeder Eintrag enthält Query_time, Lock_time, Rows_sent und Rows_examined. Eine große Lücke zwischen geprüften und gesendeten Zeilen ist das klassische Zeichen für einen fehlenden Index, typischerweise auf wp_postmeta hinter Produktfiltern. log_queries_not_using_indexes nimmt Abfragen ohne Index ins Log auf, log_throttle_queries_not_using_indexes begrenzt, wie schnell sie geschrieben werden. mysqldumpslow fasst die Logdatei zusammen. Wie Sie beheben, was das Log findet, beschreibt unser Leitfaden zur WordPress-Datenbankoptimierung.

Für einen Redis Object Cache liefert der Befehl INFO die Rohzähler:

• keyspace_hits und keyspace_misses: erfolgreiche und fehlgeschlagene Schlüssel-Lookups. Die Hit Ratio ist Treffer geteilt durch Treffer plus Fehlschläge.
• evicted_keys: Schlüssel, die wegen des maxmemory-Limits entfernt wurden. Ein steigender Wert bedeutet, dass der Cache für das Working Set zu klein ist.
• mem_fragmentation_ratio: das Verhältnis zwischen used_memory_rss und used_memory.

Eine allgemein “gute” Hit Ratio gibt es nicht, denn sie hängt davon ab, wie viel der Website cachebar ist. Halten Sie nach einem sauberen Deployment Ihre eigene Baseline fest und alarmieren Sie bei einem anhaltenden Rückgang: Meist umgeht dann ein neues Plugin den Cache, eine Konfiguration hat sich geändert oder der Traffic ist auf ungecachte Seiten gewandert.

#Headless WordPress mit verteiltem Tracing überwachen

Läuft WordPress nur noch als Content-API hinter einem Astro- oder Next.js-Frontend, gibt es zwei Systeme zu beobachten. Im Backend zählen Antwortzeit und 5xx-Quote der REST-API- oder WPGraphQL-Endpunkte. Im Frontend kommen Build-Dauer, Regenerierungszeit einzelner Seiten und der Hydration-Aufwand im Browser hinzu.

Verbunden werden beide durch einen verteilten Trace. Die Empfehlung W3C Trace Context definiert die Header traceparent und tracestate, die eine Trace-ID vom Frontend bis zur WordPress-API tragen, und OpenTelemetry unterstützt sie für die Kontextweitergabe. Eine einzelne Anfrage wird dann über CDN, Frontend, WordPress-API, MySQL und Redis hinweg sichtbar. Ohne diese Klammer sieht jedes Team nur sein eigenes Teilstück, und jede langsame Anfrage wirkt wie das Problem der Nachbarschicht.

#Anomalieerkennung im Website-Monitoring

Feste Grenzwerte wie “Alarm bei LCP über 2,5 Sekunden” schlagen entweder zu spät an oder produzieren Fehlalarme in Lastspitzen. Dynamische Baselines lernen, was zu welcher Stunde und an welchem Wochentag normal ist, und melden Abweichungen, bevor ein harter Grenzwert erreicht ist. Die meisten APM- und Observability-Plattformen bieten das an; die Einstellung ist weniger wichtig als der Kontext daneben.

Eine Anomalie hilft nur, wenn Sie sehen, was sich daneben geändert hat. Deployments, Plugin-Updates und Kampagnenstarts gehören als Markierung in dieselbe Zeitleiste wie die Metriken: Grafana nutzt dafür Annotations, New Relic Deployment-Marker. Ein TTFB-Sprung direkt neben einem Plugin-Update beendet die Fehlersuche, bevor sie beginnt.

#Performance-Budget für Core Web Vitals festlegen

Ein Budget ist eine Reihe von Obergrenzen, deren Überschreitung eine vorab vereinbarte Folge hat. Die “guten” Schwellenwerte von Google im 75. Perzentil sind die Untergrenze: LCP bis 2,5 Sekunden, INP bis 200 Millisekunden, CLS bis 0,1, laut web.dev. Enterprise-Teams setzen meist strengere Ziele pro Projekt und ergänzen Limits für ausgeliefertes JavaScript und CSS, die im Lighthouse-CI-Gate geprüft werden.

Ein Budget ohne Verantwortlichen verwässert. Benennen Sie eine Person, die den Trend wöchentlich prüft, entscheidet, ob ein Schwellenwert noch sinnvoll ist, und ein Release stoppen darf. Leiten Sie Alarme außerdem nach Schweregrad weiter: Ein kaputter Checkout weckt die Bereitschaft, ein langsam steigender TTFB geht in einen Team-Channel, kleine Abweichungen warten auf den Wochenbericht. Wenn jeder Alarm jemanden weckt, liest nach einem Monat niemand mehr einen.

#Wie Ladezeit die Conversion Rate beeinflusst

Die nützliche Frage für das Management lautet nicht “wie viele Millisekunden”, sondern “was kostet uns eine langsamere Seite”. Beantworten Sie sie mit eigenen Daten statt mit einer Prozentzahl aus der Fallstudie eines anderen Unternehmens. Schicken Sie die RUM-Werte in denselben Analytics-Speicher wie Ihre Conversion-Events, gruppieren Sie die Sitzungen nach LCP- oder INP-Band und vergleichen Sie die Conversion pro Gruppe. Das Ergebnis gilt für Ihr Publikum und Ihren Checkout, und diese Version akzeptiert ein Finanzvorstand, wenn Sie einen Performance-Sprint beantragen.

#Was ein WordPress-Monitoring-Service umfasst

Bei WPPoland umfasst Monitoring-Arbeit drei Dinge.

1. Full-Stack-Monitoring-Design: RUM, synthetische Checks und APM oder OpenTelemetry-Traces in einer gemeinsamen Ansicht, sodass ein Vorfall vom Browser bis zur SQL-Abfrage sichtbar ist.
2. Regressionsschutz: die Gates mit Lighthouse CI und Playwright, die langsame oder kaputte Templates stoppen, bevor sie die Produktion erreichen.
3. Berichte, mit denen man handeln kann: Metriken, übersetzt in die Entscheidungen, die das Management treffen muss, mit einem Verantwortlichen für jedes Budget.

Werkzeuge und Umsetzung kalkulieren wir individuell, weil die Kosten von der Zahl der Websites, dem Traffic-Volumen und dem gewählten Anbieter abhängen. Unser Team für WordPress-Entwickler unterstützt bei Konzeption, Tool-Integration und laufender Optimierung.

#Wo Sie mit WordPress-Performance-Monitoring anfangen

Fangen Sie klein und in der richtigen Reihenfolge an. Zuerst Felddaten echter Nutzer mit der web-vitals Bibliothek, weil sie zeigen, was Besucher tatsächlich erleben, und Query Monitor auf Staging. Danach Lighthouse CI und Playwright-Checks in der Pipeline, dazu synthetische Journey-Checks aus den Regionen, in denen Sie verkaufen. Dann APM oder OpenTelemetry-Traces und das Slow Query Log für die Endpunkte, auf die die ersten beiden Schichten zeigen. Jede Schicht beantwortet eine Frage, die die vorherige aufwirft, und ein Alarm ohne Verantwortlichen ist Rauschen.

Sobald das Monitoring zeigt, wohin die Zeit fließt, folgen die Korrekturen. Unser Leitfaden zur WordPress-Geschwindigkeitsoptimierung behandelt Server, Caching und Frontend, der Leitfaden zur INP-Optimierung geht tiefer in die Interaktivitätsmetrik. Ergänzend lesen Sie, wie man eine WordPress-basierte Website beschleunigen kann.