Die meisten WordPress-Leistungsprobleme werden auf die Hosting-Umgebung zurückgeführt, was manchmal auch die richtige Diagnose ist. Abhängigkeiten von Drittanbietern lösen jedoch die gleichen Alarmglocken aus, obwohl sie außerhalb der Kontrolle des Hosters liegen.
Zeitlich begrenzte Zahlungsgateways, nicht reagierende Versand-APIs und langsame Analyseskripte sind allesamt Ausfälle, für die du nur Schadensbegrenzung betreiben kannst. Das hängt jedoch von deiner Hosting-Infrastruktur ab und davon, was du auf der Anwendungsebene tun kannst, damit deine Website auch dann funktioniert, wenn Abhängigkeiten ausfallen.
Warum Abhängigkeiten von Drittanbietern zu kaskadierenden WordPress-Ausfällen führen
Eine moderne WordPress-Website läuft selten isoliert. Denke zum Beispiel daran, wovon ein WooCommerce-Kassenvorgang zu einem bestimmten Zeitpunkt abhängt:
- Zahlungs-Gateways verarbeiten die Transaktion.
- Versand-APIs berechnen die aktuellen Tarife.
- Steuerdienste kümmern sich um die Einhaltung von Vorschriften.
Andere Websites laden vielleicht einen Analyse-Tracker, ein CRM-Synchronisationsskript, ein Live-Chat-Widget und viele andere Abhängigkeiten, die jeweils auf einem anderen externen Server gehostet werden.
Wenn eine dieser Komponenten langsamer wird oder nicht mehr reagiert, bleibt der Effekt nicht auf diese spezielle Funktion beschränkt. Stattdessen breitet es sich über die PHP-Ausführungsebene aus und verursacht ein Problem, das die gesamte Website beeinträchtigen kann. Wenn WordPress eine Seite aufruft, die eine externe API-Antwort benötigt, wartet ein Thread, bevor er die Anfrage abschließt.
Ein Zahlungsgateway, das nach 30 Sekunden eine Zeitüberschreitung verursacht, bindet also einen Thread für die gesamte Dauer und kann in der Zwischenzeit nichts anderes verarbeiten. Wenn mehrere Besucher gleichzeitig auf diese langsame Kasse zugreifen, können mehrere Threads das Laden der Seite für die gesamte Kette verzögern. Beim Shared Hosting teilen sich die Websites einen Pool von Threads.
Die Sichtbarkeitslücke: Interne vs. externe Leistungsprobleme
Es braucht also nicht viele gleichzeitige Timeouts, um einen gemeinsam genutzten Pool vollständig zu erschöpfen. Wenn das passiert, kommt es zu einer Zeitüberschreitung bei der externen API, und deine verbleibenden Besucher erhalten Timeout-Fehler, wie 502 oder 504, während sie auf einen freien Thread warten.
Ein 504-Fehler sieht jedoch unabhängig von der Herkunft genau gleich aus. Bei dieser Art von Fehlermeldungen untersuchst du in der Regel zuerst die CPU-, Speicher- und Infrastruktur-Metriken. Dies kann den Anschein erwecken, dass das Problem beim Hosting liegt, auch wenn es sich in Wirklichkeit um eine externe Abhängigkeit handelt.
Wie die Container-Architektur von Kinsta die Auswirkungen von Fehlern Dritter begrenzt
Kinsta betreibt jede WordPress-Website in einem eigenen, isolierten Container, der den „Explosionsradius“ bestimmt, wenn ein Drittanbieterdienst ausfällt.
Jeder Container verfügt über einen eigenen Pool von PHP-Threads, auf die andere Websites auf der Plattform nicht zugreifen können. Das bedeutet, dass die Erschöpfung von PHP-Threads innerhalb deines Containers bleibt, ohne dass andere Websites auf derselben Infrastruktur betroffen sind. Wenn externe API-Aufrufe alle PHP-Threads deines Containers belegen, werden eingehende Anfragen in die Warteschlange von Nginx und PHP-FPM gestellt und nicht sofort als Fehler zurückgegeben.
In der Praxis betrifft ein Ausfall des Zahlungsgateways, der jede Website auf einem gemeinsam genutzten Server lahmlegen würde, nur deinen Container auf Kinsta. Der Thread-Pool innerhalb deines Containers wird belastet, aber die benachbarten Websites sind davon nicht betroffen.
Timeout-Limits für Anfragen verhindern unendliches Blockieren
Ein PHP-Thread kann eine Verbindung zu einer fehlgeschlagenen externen API über einen längeren Zeitraum aufrechterhalten, wenn er nicht kontrolliert wird. Um dem entgegenzuwirken, setzt Kinsta die max_execution_time auf einen Standardwert von 300 Sekunden, der begrenzt, wie lange ein PHP-Skript aktiv ausgeführt werden kann.
Es gibt ein separates HTTP-Timeout, das bestimmt, wann die Verbindung zwischen Browser und Server abbricht und dem Besucher einen 504-Fehler zurückgibt.
Zusammengenommen bedeuten diese Grenzen, dass dein Worst-Case-Szenario aus Sicht des Besuchers einen definierten Endpunkt hat. Keines der beiden Limits unterbricht jedoch einen blockierten ausgehenden API-Aufruf zuverlässig von selbst. Unter Linux zählt der PHP-Ausführungstimer nicht die Zeit, in der auf Stream-Operationen gewartet wird, eine ausgehende HTTP-Anfrage über die HTTP-API von WordPress stellt eine solche jedoch dar.
Ein Thread, der für die Antwort eines Zahlungsgateways blockiert wird, benötigt aus PHP-Sicht fast keine Ausführungszeit, so dass die 300-Sekunden-Grenze hier weniger Schutz bietet, als es den Anschein hat. Aus diesem Grund ist das Setzen expliziter Timeouts in Plugins über http_request_timeout die zuverlässigste Methode, um einen hängenden externen Aufruf auf Anwendungsebene zu beenden.
Wenn eine Anfrage eine Zeitüberschreitung erfährt, wird der Thread freigegeben und der Container beginnt mit einer Wiederherstellung, die in der Regel ein paar Minuten dauert.
Verwendung von Kinsta APM zur Unterscheidung von Engpässen beim Hosting und bei Dritten
Das APM-Tool von Kinsta erfasst mit Zeitstempeln versehene Daten zu PHP-Prozessen, MySQL-Abfragen und externen HTTP-Aufrufen. So kannst du den Leistungsunterschied zwischen deinem Hosting und den Abhängigkeiten von Drittanbietern überwachen.
Du aktivierst APM im APM-Bereich in MyKinsta und wählst dann ein Überwachungsfenster aus vier voreingestellten Optionen zwischen zwei und 24 Stunden. Da das Kinsta APM zusätzliche Server-Ressourcen verbraucht, solltest du es erst aktivieren, wenn du ein Problem vermutest oder es reproduzieren kannst.
Sobald die APM läuft, kannst du dir eine Reihe von Diagrammen, Grafiken und Anzeigen in vier Bereichen ansehen: Transaktionen, WordPress, Datenbank und Extern. Letzteres ist wichtig, um zu verstehen, wo Engpässe auftreten.
Verwendung des Bildschirms Extern in Kinsta APM
Die Registerkarte Extern listet alle externen HTTP-Anfragen auf, die deine Website stellt, einschließlich der Aufrufe, die von Plugins und Themes für die Zahlungsabwicklung, Versandberechnungen, CRM-Integrationen und Analysen ausgelöst werden. Jeder Eintrag zeigt die Gesamt-, Maximal- und Durchschnittsdauer sowie die Anfragerate pro Minute an.
Wenn zum Beispiel eine Zahlungs-API ganz oben in der Liste steht und die maximale Dauer in mehreren Sekunden gemessen wird, ist das ein deutlicher Hinweis darauf, dass das Gateway die Ursache des Problems ist.
Transaktionsverfolgung
Wenn du in der Registerkarte Extern auf eine Anfrage-URL klickst, öffnet sich eine Liste mit Transaktionsbeispielen. Wenn du ein bestimmtes Beispiel auswählst, öffnet sich die Zeitleiste der Transaktionsverfolgung, die eine vollständige Aufschlüsselung aller aufgetretenen Prozesse zeigt, wobei jeder Prozess als Zeitspanne dargestellt wird.
Zeitspannen, die mehr als 5 % der gesamten Transaktionszeit beanspruchen, erscheinen in orange; solche, die mehr als 25 % beanspruchen, erscheinen in rot.
Traces helfen dir dabei, Prioritäten zu setzen, welche Abhängigkeiten du zuerst optimieren oder ersetzen musst. Wenn zum Beispiel ein externer HTTP-Aufruf an eine Zahlungs-API fünf Sekunden einer 5,5-Sekunden-Transaktion beansprucht, hat die Hosting-Infrastruktur alles andere in einer halben Sekunde erledigt.
Um die Kinsta APM bei einem vermuteten Problem zu nutzen, läuft der Workflow wie folgt ab:
- Aktiviere die APM-Überwachung und wähle eine Dauer, die das Problemfenster abdeckt.
- Reproduziere das Problem, wenn es nicht gerade auftritt (oder warte, bis das Tool Live-Daten erfasst).
- Lasse die Daten sammeln, öffne dann die Registerkarte Extern, klicke auf eine externe Anfrage, um die Transaktionsspur zu öffnen, und untersuche die Zeitspannen.
Wenn externe HTTP-Aufrufe ganz oben in den Ergebnissen auftauchen und die Dauer den größten Teil der Transaktionszeit ausmacht, hast du die Informationen, die du brauchst, um das Problem zu beheben.
Operative Strategien zur Verwaltung von Abhängigkeiten von Drittanbietern
Die Isolierung von Containern begrenzt den Schaden durch externe Ausfälle, aber das gilt auch für die Art und Weise, wie du externe Dienste lädst und aufrufst. Selbst wenn du ein gut ausgebautes Hosting hast, müssen die Abhängigkeiten von Drittanbietern proaktiv auf Anwendungsebene verwaltet werden.
Asynchrone Lademuster für unkritische Skripte
WordPress lädt Skripte standardmäßig synchron, d. h. ein Skript im Dokumentenkopf blockiert die Anzeige von Inhalten im Browser, bis es vollständig heruntergeladen und ausgeführt wurde. Für Analyseskripte, Heatmapping-Tools und Marketing-Automatisierung bedeutet das, dass ein langsamer Drittserver deine gesamte Website aufhält.
Es ist wichtig zu verstehen, dass das Laden über sync und async zu unterschiedlichen Ergebnissen führt, wenn ein externer Server langsam ist:
- Beim synchronen (blockierenden) Laden wird die HTML-Analyse angehalten, bis das Skript heruntergeladen und ausgeführt wurde. Wenn der externe Server unter Last steht, kann deine Website nicht angezeigt werden.
- Beim asynchronen Laden kann der Browser mit dem Parsen von HTML und dem Rendern von Inhalten fortfahren, während das Skript im Hintergrund geladen wird. Wenn der externe Server langsam ist, wird deine Website trotzdem gerendert.
WordPress bietet mit wp_enqueue_script() native Unterstützung für async und defer Laden. Beide verhindern, dass unkritische Skripte das Rendering der Seite blockieren, aber sie verhalten sich unterschiedlich: defer führt Skripte in der Reihenfolge aus (daher ist es gut für Skripte mit Abhängigkeiten), während async Skripte unabhängig von der Reihenfolge ausführt, sobald sie geladen werden.
Die Verwendung von async ist ideal für eigenständige Tracker, bei denen die Reihenfolge der Ausführung keine Rolle spielt.
add_action( 'wp_enqueue_scripts', function() {
// Analytics — deferred so it doesn't block the critical path.
wp_enqueue_script(
'google-analytics',
'https://www.googletagmanager.com/gtag/js?id=G-XXXXXXXX',
[],
null,
[ 'strategy' => 'defer', 'in_footer' => false ]
);
// Marketing script — async because execution order doesn't matter.
wp_enqueue_script(
'hotjar',
'https://static.hotjar.com/c/hotjar-XXXXXX.js',
[],
null,
[ 'strategy' => 'async', 'in_footer' => false ]
);
} );Checkout-kritische Skripte brauchen jedoch oft ein vorsichtigeres Ladeverhalten als Analytics- oder Marketing-Tags, und manche Zahlungsintegrationen müssen blockiert oder geordnet bleiben, damit der Checkout nicht unterbrochen wird. Kurz gesagt, nicht-kritische Skripte, die ausfallen können, ohne die Seite abzubrechen, werden async oder defer; Skripte, die der Nutzer zum Abschluss einer Transaktion benötigt, nicht.
Timeout-Konfiguration für externe API-Aufrufe
Die von Kinsta voreingestellte max_execution_time ist lang genug für komplexe Vorgänge, aber viel zu lang, um einen Nutzer warten zu lassen. Daher sollte ein Plugin, das externe API-Aufrufe tätigt, seine eigene Timeout-Grenze festlegen, anstatt auf das Limit auf Serverebene zurückzugreifen.
WordPress gibt standardmäßig ein 5-Sekunden-HTTP-Timeout für externe Anfragen vor, es sei denn, ein Plugin oder ein Filter setzt dieses Limit außer Kraft. Wenn ein Plugin ein anderes Limit benötigt, bietet WordPress dafür einen Filter: http_request_timeout. Er wird ausgeführt, bevor eine Anfrage gestellt wird, und akzeptiert sowohl den aktuellen Timeout-Wert als auch die Ziel-URL, so dass du unterschiedliche Limits für verschiedene Dienste festlegen kannst:
add_filter( 'http_request_timeout', function( $timeout, $url ) {
if ( str_contains( $url, 'api.example.com' ) ) {
return 10; // Don't wait longer than 10 seconds.
}
return $timeout;
}, 10, 2 );Diese Art von Obergrenze bedeutet, dass ein fehlgeschlagener Dienst deinem Benutzer schnell einen Fehler zurückgibt, anstatt einen PHP-Thread zu belegen. Wenn du die Timeouts auf Plugin-Ebene deutlich unter der Server-Obergrenze hältst, verhindert dies, dass eine einzelne langsame API einen Thread für eine unangemessen lange Zeit in Anspruch nimmt.
Eine Erhöhung der Timeout-Werte behebt jedoch keine langsamen APIs, sondern verhindert vorzeitige Ausfälle, wenn ein Dienst zwar funktioniert, aber unter Last steht. Der richtige Ansatz ist ein kurzes Timeout, das schnell ausfällt und an einen Fallback weitergibt.
Fallback-Mechanismen und graceful degradation
Fallbacks sorgen dafür, dass deine Website auch bei externen Ausfällen funktioniert, anstatt einen Fehler anzuzeigen. Das Muster verwendet WordPress Transients, um erfolgreiche API-Antworten zwischenzuspeichern, und liefert dann die zwischengespeicherten Daten, wenn ein Live-Aufruf fehlschlägt.
Hier ist ein Beispiel:
function get_shipping_rates_with_fallback( $package ) {
$cache_key = 'live_shipping_rates_' . md5( serialize( $package ) );
$backup_key = 'backup_shipping_rates_' . md5( serialize( $package ) );
// Return fresh cached rates if they're available.
$cached = get_transient( $cache_key );
if ( $cached !== false ) {
return $cached;
}
// Attempt the live API call with a short timeout.
$response = wp_remote_post( 'https://api.example.com/rates', [
'timeout' => 8,
'body' => [
'destination' => $package['destination'],
'weight' => $package['contents_weight'],
],
] );
// On success: cache the result and update the longer-lived backup.
if ( ! is_wp_error( $response ) && wp_remote_retrieve_response_code( $response ) === 200 ) {
$rates = json_decode( wp_remote_retrieve_body( $response ), true );
set_transient( $cache_key, $rates, HOUR_IN_SECONDS );
set_transient( $backup_key, $rates, DAY_IN_SECONDS );
return $rates;
}
// On failure: serve stale backup rates rather than an error.
$backup = get_transient( $backup_key );
if ( $backup !== false ) {
return $backup;
}
// No cached data at all: return a flat-rate fallback.
return [
[ 'id' => 'fallback_flat', 'label' => 'Standard Shipping', 'cost' => 9.99 ],
];
}Der einstündige Transient übernimmt das normale Caching, um unnötige API-Aufrufe zu vermeiden. Der 24-Stunden-Transient wird nur aktualisiert, wenn die Live-API eine erfolgreiche Antwort zurückgibt, damit deine Website auf die letzte erfolgreiche Antwort zurückgreifen kann. Wenn die API ausfällt, zeigt deine Website die Versandpreise von gestern anstelle einer Fehlermeldung an.
Graceful Degradation sorgt dafür, dass deine Kernfunktionen auch dann weiterlaufen, wenn externe Dienste nicht verfügbar sind. Es funktioniert am besten in Verbindung mit einer Hosting-Infrastruktur, die Ausfälle auf die Containerebene beschränkt, damit ein einziges Abhängigkeitsproblem nicht die Ressourcen aufbraucht.
Dein Hosting sollte mehr tun, als nur die Geschwindigkeit deiner Website zu erhöhen
Ausfälle von Drittanbietern sind Teil des Betriebs einer WordPress-Website mit realen Abhängigkeiten. Was du kontrollieren kannst, ist, wie viel von deiner Website damit zu tun hat, und das hängt davon ab, wie deine Hosting-Umgebung darauf reagiert.
Mit einer Infrastruktur, die Container-Isolierung, einen dedizierten PHP-Thread-Pool, eingebaute Timeout-Limits und Anwendungsüberwachung implementiert, kannst du ein Hosting-Problem von einem Abhängigkeitsproblem unterscheiden.
Wenn du wissen willst, wie die Kinsta-Infrastruktur dies für deine WordPress-Websites handhabt, schau dir die Hosting-Angebote von Kinsta an. Oder sprich mit unserem Team darüber, wie Kinsta für dich von Nutzen sein kann.
Joel ist Frontend-Entwickler und arbeitet bei Kinsta als Technical Editor. Er ist ein leidenschaftlicher Lehrer mit einer Vorliebe für Open Source und hat über 200 technische Artikel geschrieben, die sich hauptsächlich um JavaScript und seine Frameworks drehen.
