WordPress-Performance erkennen: Caching und CDN-Signale lesen

Ob eine WordPress-Site schnell oder langsam ist, lässt sich von außen zuverlässig einschätzen. Die entscheidenden Hinweise stecken nicht in der sichtbaren Oberfläche, sondern in den HTTP-Headern, den Ladezeiten einzelner Ressourcen und der DNS-Konfiguration. Wer diese Signale lesen kann, versteht den technischen Reifegrad einer Site auf einen Blick.

Warum Performance-Analyse für WordPress relevant ist

WordPress-Sites variieren enorm in ihrer Ladegeschwindigkeit. Dieselbe Software läuft je nach Hosting-Tier, Cache-Konfiguration und CDN-Einsatz mit Reaktionszeiten zwischen 80 ms und über 4 Sekunden. Diese Unterschiede sind messbar und für Wettbewerbsanalysen, Kundenberatung oder technische Audits wertvoll. Der Analyzer auf wordpress-analyzer.de prüft viele dieser Signale automatisch.

HTTP-Header: Das wichtigste Analysewerkzeug

Der erste Schritt ist das Auslesen der Antwort-Header. Öffne die Browser-Entwicklertools (F12), gehe auf den Netzwerk-Reiter und lade die Seite neu. Klicke auf die erste HTML-Anfrage und schaue dir die Response-Header an.

Folgende Header liefern direkte Hinweise auf den Cache-Status:

• X-Cache: HIT oder X-Cache: MISS zeigen an, ob die Antwort aus einem Cache kam oder direkt vom Server erzeugt wurde.
• Age: 1234 gibt an, wie viele Sekunden die gecachte Antwort schon im Cache liegt.
• Cache-Control: max-age=86400 definiert, wie lange Browser und Caches die Antwort speichern dürfen.
• Vary: Accept-Encoding ist ein normales Signal, kann aber auf fehlende Browser-spezifische Cache-Trennung hinweisen.

Plugin-spezifische Header

Einige WordPress-Caching-Plugins setzen eigene Header, die das Plugin direkt identifizieren:

• W3 Total Cache setzt X-Powered-By: W3 Total Cache
• WP Super Cache kommentiert im HTML-Quelltext, wann die gecachte Seite erzeugt wurde
• LiteSpeed Cache schreibt X-LiteSpeed-Cache: hit bei Cache-Treffern

CDN-Signale erkennen

Ein Content Delivery Network stellt Inhalte von geographisch verteilten Knoten bereit. Die Erkennung gelingt auf mehreren Wegen.

Cloudflare

Cloudflare ist bei WordPress-Sites marktführend. Erkennungsmerkmale:

• CF-RAY-Header in der Antwort: ein alphanumerischer String, der jeden Request durch Cloudflare identifiziert
• CF-Cache-Status: HIT oder CF-Cache-Status: MISS
• Server: cloudflare statt des echten Webservers
• IP-Adressen aus dem Cloudflare-Bereich bei einem DNS-Lookup (z.B. 104.x.x.x oder 172.67.x.x)

Fastly

Fastly erkennt man an:

• X-Served-By-Header mit einem Fastly-Hostnamen
• X-Cache: HIT, HIT für mehrstufige Cache-Treffer

Cloudfront (AWS)

Amazon Cloudfront meldet sich mit:

• X-Amz-Cf-Pop-Header, der den Edge-Standort nennt
• Via-Header mit einem AWS-Hostnamen

Server-Technologie und Hosting-Typ

Der Server-Header verrät die Webserver-Software. Bei WordPress-Managed-Hostern finden sich charakteristische Kombinationen:

• nginx und PHP-FPM-Hinweise deuten auf Performance-optimierte Setups hin, wie sie WP Engine oder Kinsta nutzen
• LiteSpeed in Kombination mit dem LSCache-Plugin ist typisch für cPanel-Hoster wie Hostinger oder A2 Hosting
• Apache ohne weitere Cache-Header zeigt oft günstiges Shared-Hosting

Einige Managed-Hoster setzen auch eigene Header: WP Engine schreibt X-Cacheable, Kinsta setzt X-Kinsta-Cache.

Ladezeit-Messung mit Bordmitteln

Neben den Headern gibt die tatsächliche Antwortzeit Aufschluss über die Performance-Situation. Im Netzwerk-Reiter der Entwicklertools zeigt das Wasserfalldiagramm:

• Time to First Byte (TTFB): Alles über 200 ms ohne Cache-HIT deutet auf fehlende serverseitige Optimierung hin
• Dateigröße der HTML-Antwort: Unkomprimierte Antworten über 100 KB weisen auf fehlendes GZIP oder Brotli hin
• Anzahl der Anfragen: Viele kleine JS- und CSS-Dateien zeigen ungünstiges Asset-Bundling

Ressourcen-Pfade als Indikator

Auch die Pfade der eingebundenen Ressourcen geben Hinweise. WordPress-Sites mit aktivem Caching-Plugin cachen Ressourcen häufig unter einem eigenen Unterordner:

• /wp-content/cache/ zeigt aktives Plugin-Caching
• Statische Dateien unter cdn.beispieldomain.de oder einem externen CDN-Hostname deuten auf Offloading hin
• Versionierungsparameter wie ?ver=6.5 bei JS-Dateien stammen direkt aus WordPress und helfen bei der Versionserkennung

Praktische Vorgehensweise

Für eine strukturierte Performance-Analyse empfiehlt sich diese Reihenfolge:

1. DNS-Lookup durchführen und IP-Adressen mit bekannten CDN-Ranges abgleichen
2. HTTP-Header der Startseite auslesen und auf Cache- und CDN-Header prüfen
3. Ressourcenpfade im Quelltext auf Cache-Verzeichnisse untersuchen
4. TTFB messen und mit einem zweiten Aufruf vergleichen (Cache-Warmup sichtbar machen)
5. Quelltext auf Plugin-Kommentare zum Caching prüfen

Grenzen der externen Analyse

Nicht alle Performance-Faktoren sind von außen sichtbar. Datenbankabfragen, PHP-Ausführungszeiten und serverseitige Optimierungen lassen sich ohne Zugriff auf das Backend nicht direkt messen. Was sich aber zuverlässig bestimmen lässt, ist der Caching-Reifegrad und die CDN-Infrastruktur. Diese beiden Faktoren entscheiden bei WordPress in der Praxis über den größten Teil der Ladezeit.