Veel WordPress-problemen worden op hosting geschoven en soms is dat terecht. Maar externe afhankelijkheden veroorzaken net zo goed vertragingen, en daar heeft je host vrij weinig mee te maken.
Betalingsgateways met timeout fouten, niet reagerende API’s voor verzendingen en trage analysescripts zijn allemaal storingen waar je alleen schadebeperking voor kunt uitvoeren. Dit hangt echter af van je hostinginfrastructuur en wat je op applicatieniveau kunt doen om je site draaiende te houden als afhankelijkheden falen.
Externe afhankelijkheid: de verborgen vijand van snelle WordPress sites
Een moderne WordPress site werkt zelden geïsoleerd. Denk bijvoorbeeld aan waar een WooCommerce checkout flow op een bepaald moment van afhankelijk is:
- Betalingsgateways verwerken de transactie.
- Shipping API’s berekenen live tarieven.
- Belastingservices zorgen voor naleving.
Andere sites laden misschien een analytics tracker, een CRM sync script, een live chat widget en vele andere afhankelijkheden, elk gehost op een andere externe server.
Als een van deze onderdelen vertraagt of stopt met reageren, blijft het effect niet beperkt tot die specifieke functie. In plaats daarvan verspreidt het zich door de PHP uitvoeringslaag en creëert het een probleem dat de hele site kan beïnvloeden. Dit komt doordat, wanneer WordPress een pagina serveert die een externe API respons nodig heeft, er een thread wacht voordat het verzoek wordt voltooid.
Dus een betalingsgateway die na 30 seconden een timeout krijgt, houdt één thread voor de hele duur vast en kan in de tussentijd niets anders verwerken. Als meerdere bezoekers tegelijk die trage kassa bereiken, kunnen meerdere threads het laden van pagina’s voor de hele keten vertragen. Bij gedeelde hosting delen sites een pool van threads.
De zichtbaarheidskloof: interne versus externe prestatieproblemen
Er zijn dus niet veel gelijktijdige timeouts nodig om een gedeelde pool volledig uit te putten. Zodra dat gebeurt, valt de externe API uit en krijgen je resterende bezoekers timeout-gerelateerde fouten, zoals 502 of 504, terwijl ze wachten op een vrije thread.
Een 504 fout ziet er echter precies hetzelfde uit, ongeacht de oorsprong. Voor dit soort foutreacties onderzoek je meestal eerst CPU, geheugen en infrastructuur statistieken. Dit kan eruit zien alsof hosting het probleem is, zelfs als het echte probleem een externe afhankelijkheid is.
Hoe Kinsta’s containerarchitectuur de impact van externe storingen beperkt
Bij Kinsta draait elke WordPress-site in een eigen, geïsoleerde container. Daardoor blijven problemen met externe diensten beperkt tot één omgeving, in plaats van je hele infrastructuur te raken.
Elke container heeft zijn eigen speciale pool van PHP threads waar andere sites op het platform geen toegang toe hebben. Dit betekent dat de uitputting van PHP threads binnen je container blijft zonder andere sites op dezelfde infrastructuur te beïnvloeden. Als externe API-calls alle PHP-threads van je container in beslag nemen, komen inkomende verzoeken in een wachtrij binnen Nginx en PHP-FPM in plaats van dat ze direct fouten terugsturen.
In de praktijk heeft een storing in de betalingsgateway, die elke site op een gedeelde server plat zou leggen, alleen invloed op jouw container op Kinsta. De threadpool in je container komt onder druk te staan, maar naburige sites hebben er geen last van.
Time-outlimieten voorkomen dat verzoeken blijven hangen
Als dit niet is aangevinkt, kan een PHP thread een verbinding met een falende externe API voor langere tijd vasthouden. Om dit tegen te gaan, stelt Kinsta max_execution_time in op een standaardwaarde van 300 seconden, die beperkt hoe lang een PHP script actief kan worden uitgevoerd.
Er is een aparte HTTP timeout die bepaalt wanneer de browser-naar-server verbinding het opgeeft en een 504 fout terugstuurt naar de bezoeker, die op Kinsta na 180 seconden triggert.
Samen betekenen deze limieten dat je worst-case scenario een gedefinieerd eindpunt heeft vanuit het perspectief van de bezoeker. Geen van beide limieten snijdt echter op betrouwbare wijze een geblokkeerde uitgaande API-call af. Op Linux telt de uitvoeringstimer van PHP niet de tijd die wordt besteed aan het wachten op stream operaties, wat een uitgaand HTTP verzoek via de HTTP API van WordPress is.
Een thread die geblokkeerd wordt op een antwoord van een betalingsgateway accumuleert bijna geen uitvoeringstijd vanuit PHP’s perspectief, dus het maximum van 300 seconden biedt hier minder bescherming dan het lijkt. Daarom is het instellen van expliciete timeouts in plugins via http_request_timeout de meest betrouwbare manier om een hangende externe call op applicatieniveau te beëindigen.
Wanneer een verzoek uitloopt, wordt de thread vrijgemaakt en begint de container aan een herstel dat meestal een paar minuten duurt.
Gebruik Kinsta APM om hostingproblemen van externe knelpunten te scheiden
Kinsta’s APM tool legt tijdstempelgegevens vast van PHP processen, MySQL queries en externe HTTP calls. Zo zie je direct of vertraging uit je hosting komt of door externe afhankelijkheden wordt veroorzaakt..
Je schakelt APM in vanuit de APM-sectie in MyKinsta en kiest vervolgens een monitoringvenster uit vier vooraf ingestelde opties tussen twee en 24 uur. Omdat de Kinsta APM extra server-resources gebruikt, is de juiste aanpak om het in te schakelen wanneer je vermoedt dat er een probleem optreedt of kan worden gereproduceerd.
Als de APM eenmaal draait, kun je een aantal grafieken en weergaven bekijken in vier secties: Transacties, WordPress, Database en Extern. De laatste is belangrijk om te begrijpen waar knelpunten optreden.
De Extern pagina in Kinsta APM gebruiken
Het tabblad Extern geeft een overzicht van alle externe HTTP-verzoeken die je site doet, inclusief verzoeken die worden geïnitieerd door plugins en thema’s voor betalingsverwerking, verzendberekeningen, CRM-integraties en analyses. Elk item toont de totale, maximale en gemiddelde duur, samen met het aantal aanvragen per minuut.
Een betalings-API die bijvoorbeeld bovenaan de lijst staat, met een maximale duur gemeten in meerdere seconden, geeft duidelijk aan dat de gateway de bron van het probleem is.
Transactie traceren
Door op een verzoek-URL in het tabblad Extern te klikken, wordt een lijst met transactie-samples geopend. Als je een specifiek voorbeeld selecteert, wordt de tijdlijn van de transactietrace geopend, die een volledige uitsplitsing laat zien van elk proces dat plaatsvond, waarbij elk proces wordt weergegeven als een tijdspanne.
Spans die meer dan 5% van de totale transactietijd in beslag nemen, worden oranje weergegeven; spans die meer dan 25% in beslag nemen, worden rood weergegeven.
Traces helpen je bij het prioriteren van welke afhankelijkheden je als eerste moet optimaliseren of vervangen. Als bijvoorbeeld een externe HTTP-call naar een betaal-API vijf seconden in beslag neemt van een transactie van 5,5 seconden, dan heeft de hostinginfrastructuur al het andere in een halve seconde afgehandeld.
Om de Kinsta APM te gebruiken tijdens een vermoedelijk probleem, verloopt de workflow als volgt:
- Schakel APM monitoring in en selecteer een tijdsduur waarin het probleem zeker voorkomt.
- Reproduceer het probleem als het zich op dat moment niet voordoet (of wacht tot de tool live gegevens vastlegt).
- Laat eerst voldoende data verzamelen. Open vervolgens het tabblad Extern, klik op een request en analyseer in de trace hoe lang elke stap duurt.
Als externe HTTP-calls bovenaan de resultaten verschijnen met looptijden die het grootste deel van de transactietijd beslaan, dan heb je de informatie die je nodig hebt om het probleem op te lossen.
Extra strategieën voor het beheren van externe afhankelijkheden
Containerisolatie beperkt de impact van externe fouten, maar ook hoe je externe diensten laadt en callt maakt verschil. Zelfs met sterke hosting vereisen afhankelijkheden van derden actief beheer op applicatieniveau.
Asynchrone laadpatronen voor niet-kritieke scripts
WordPress laadt scripts standaard synchroon, wat betekent dat een script in de head van het document de browser blokkeert om inhoud weer te geven totdat het klaar is met downloaden en uitvoeren. Voor analytische scripts, heatmaps en marketingautomatisering kan een trage externe server je hele pagina vertragen.
Het onderscheid dat je hier moet maken is dat laden via sync en async verschillende resultaten oplevert als een externe server traag is:
- Synchroon (blokkerend) laden stopt HTML-parsing totdat het script is gedownload en uitgevoerd. Als de externe server onder belasting staat, wacht je pagina.
- Asynchroon laden laat de browser doorgaan met HTML parsen en inhoud renderen terwijl het script op de achtergrond wordt geladen. Als de externe server traag is, wordt je pagina toch weergegeven.
WordPress heeft ingebouwde ondersteuning voor async en defer laadstrategieën via wp_enqueue_script(). Beide voorkomen dat niet-kritieke scripts het renderen van pagina’s blokkeren, maar ze gedragen zich verschillend: defer voert scripts in volgorde uit (dus goed voor scripts met afhankelijkheden), terwijl async scripts uitvoert zodra ze geladen worden, ongeacht de volgorde.
Het gebruik van async is ideaal voor standalone trackers waarbij de uitvoeringsvolgorde er niet toe doet.
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 ]
);
);Kassakritieke scripts vereisen vaak voorzichtiger laadgedrag dan analytische of marketingtags. Sommige betalingsintegraties moeten zelfs synchroon blijven of in een vaste volgorde laden om te voorkomen dat het afrekenproces breekt. Kortom: niet-kritieke scripts kunnen async of defer worden geladen, terwijl scripts die nodig zijn voor een succesvolle transactie dat niet kunnen.
Time-outconfiguratie voor externe API-calls
Kinsta’s standaard max_execution_time is lang genoeg voor complexe bewerkingen, maar veel te lang om een gebruiker te laten wachten. Daarom moet een plugin die externe API-calls doet zijn eigen timeout instellen in plaats van terug te vallen op de limiet op serverniveau.
WordPress stelt standaard een HTTP timeout van 5 seconden in voor externe verzoeken, tenzij een plugin of filter dit overschrijft. Als een plugin een andere limiet nodig heeft, dan biedt WordPress hiervoor een filter: http_request_timeout. Deze wordt uitgevoerd voordat een verzoek wordt gedaan en accepteert zowel de huidige timeoutwaarde als de doel-URL, zodat je verschillende limieten kunt instellen voor verschillende services:
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 );Dergelijke timeout-limieten zorgen ervoor dat een falende service snel een fout teruggeeft aan de gebruiker, in plaats van een PHP-thread vast te houden. Door timeouts op pluginniveau ruim onder de serverlimiet te houden, voorkom je dat één trage API een thread onnodig lang blokkeert.
Het verhogen van de timeout waarden lost echter geen trage API’s op, maar voorkomt voortijdige storingen wanneer een service werkt maar onder belasting staat. De juiste benadering is een korte timeout die snel faalt en doorschakelt naar een fallback.
Terugvalmechanismen en gracieuze degradatie
Fallbacks houden je site functioneel tijdens externe storingen in plaats van een fout weer te geven. Het patroon gebruikt WordPress transients om succesvolle API-responses in de cache op te slaan en serveert vervolgens gegevens in de cache als een live oproep mislukt.
Hier is een voorbeeld:
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 ],
];
Een 1-uurs transient zorgt voor normale caching en voorkomt onnodige API-calls. De 24-uurs transient wordt alleen vernieuwd wanneer de live API een succesvol antwoord teruggeeft, zodat de site altijd kan terugvallen op de laatst bekende goede data. Valt de API uit, dan worden bijvoorbeeld de verzendtarieven van gisteren getoond in plaats van een foutmelding.
Graceful degradation zorgt ervoor dat kernfunctionaliteit blijft werken, ook wanneer externe services niet beschikbaar zijn. Dit werkt het best in combinatie met een hostinginfrastructuur die storingen isoleert op containerniveau, zodat één falende afhankelijkheid geen systeembronnen blijft opslokken.
Je hosting moet meer doen dan je site snelheid geven
Storingen bij externe diensten zijn onvermijdelijk bij het draaien van een WordPress-site met echte afhankelijkheden. Wat je wél kunt sturen, is de impact ervan op je site – en die wordt bepaald door hoe je hostingomgeving ermee omgaat.
Pas als je infrastructuur gebruikt die containerisolatie, een speciale PHP threadpool, ingebouwde timeoutlimieten en applicatemonitoring implementeert, kun je een hostingprobleem onderscheiden van een afhankelijkheidsprobleem.
Als je klaar bent om te zien hoe de infrastructuur van Kinsta dit aanpakt voor je WordPress sites, bekijk dan de hostingpakketten van Kinsta. Je kunt ook met het team praten over hoe Kinsta jouw specifieke setup kan verbeteren.
Kinsta
Joel is een Frontend developer die bij Kinsta werkt als Technical Editor. Hij is een gepassioneerd leraar met liefde voor open source en heeft meer dan 200 technische artikelen geschreven, voornamelijk over JavaScript en zijn frameworks.
https://kinsta.com/nl/blog/wordpress-prestaties-gedeeltelijke-storingen/
