La maggior parte dei problemi di prestazioni di WordPress viene ricondotta all’ambiente di hosting, che a volte è la diagnosi giusta. Tuttavia, le dipendenze di terze parti fanno scattare gli stessi campanelli d’allarme, ma non sono controllabili dall’host.
I gateway di pagamento che si bloccano, le API di spedizione che non rispondono e gli script di analisi lenti sono tutti guasti per i quali puoi solo cercare di limitare i danni. Tuttavia, questo dipende dalla tua infrastruttura di hosting e da ciò che puoi fare a livello di applicazione per mantenere il tuo sito funzionante quando le dipendenze falliscono.
Perché le dipendenze di terze parti creano guasti a cascata su WordPress
Un sito WordPress moderno raramente funziona in modo isolato. Ad esempio, pensa a ciò da cui dipende un flusso di checkout di WooCommerce in un determinato momento:
- I gateway di pagamento elaborano la transazione.
- Le API di spedizione calcolano le tariffe in tempo reale.
- I servizi fiscali si occupano della conformità.
Altri siti potrebbero caricare un tracker analitico, uno script di sincronizzazione CRM, un widget di live chat e molte altre dipendenze, ognuna ospitata su un server esterno diverso.
Quando una di queste rallenta o smette di rispondere, l’effetto non rimane circoscritto a quella specifica funzione. Al contrario, si diffonde attraverso il livello di esecuzione PHP e crea un problema che può interessare l’intero sito. Infatti, quando WordPress serve una pagina che necessita di una risposta API esterna, un thread attende prima di completare la richiesta.
Quindi, un gateway di pagamento che va in timeout dopo 30 secondi impegna un thread per l’intera durata e non può elaborare nient’altro nel frattempo. Se diversi visitatori raggiungono il checkout lento in una sola volta, diversi thread possono ritardare il caricamento della pagina per l’intera catena. Con l’hosting condiviso, i siti condividono un pool di thread.
Il divario di visibilità: problemi di performance interni ed esterni
Per questo motivo, non sono necessari molti timeout simultanei per esaurire completamente un pool condiviso. Una volta che ciò accade, l’API esterna va in timeout e i visitatori rimanenti ricevono errori legati al timeout, come 502 o 504, in attesa di un thread libero.
Tuttavia, un errore 504 ha sempre lo stesso aspetto, indipendentemente dall’origine. Per questo tipo di risposte di errore, in genere si analizzano prima le metriche di CPU, memoria e infrastruttura. In questo modo si può pensare che il problema sia l’hosting, anche quando il vero problema è una dipendenza esterna.
Come l’architettura a container di Kinsta limita l’impatto dei guasti di terze parti
Kinsta gestisce ogni sito WordPress nel proprio contenitore isolato, che determina l’entità del danno quando un servizio di terze parti si guasta.
Ogni container ha un proprio pool dedicato di thread PHP a cui gli altri siti della piattaforma non possono accedere. Ciò significa che l’esaurimento dei thread PHP rimane all’interno del container senza influenzare altri siti sulla stessa infrastruttura. Inoltre, quando le chiamate API esterne occupano tutti i thread PHP del container, le richieste in arrivo vengono messe in coda all’interno di Nginx e PHP-FPM invece di restituire immediatamente errori.
In pratica, un’interruzione del gateway di pagamento, che potrebbe mettere fuori uso tutti i siti su un server condiviso, colpisce solo il tuo container su Kinsta. Il pool di thread all’interno del tuo container viene messo sotto stress, ma i siti vicini non ne risentono affatto.
I limiti di timeout delle richieste impediscono un blocco indefinito
Se non viene controllato, un thread PHP potrebbe mantenere una connessione a un’API esterna in errore per un periodo prolungato. Per ovviare a questo problema, Kinsta imposta un max_execution_time di 300 secondi, che limita il tempo di esecuzione attiva di uno script PHP.
Esiste un timeout HTTP separato che determina il momento in cui la connessione tra browser e server cede e restituisce un errore 504 al visitatore, che su Kinsta scatta dopo 180 secondi.
Insieme, questi limiti significano che lo scenario peggiore ha un punto finale definito dal punto di vista del visitatore. Tuttavia, nessuno dei due limiti interrompe in modo affidabile una chiamata API in uscita bloccata. Su Linux, il timer di esecuzione di PHP non tiene in conto il tempo trascorso in attesa di operazioni di flusso, che è ciò che rappresenta una richiesta HTTP in uscita attraverso l’API HTTP di WordPress.
Un thread bloccato sulla risposta di un gateway di pagamento non accumula quasi nessun tempo di esecuzione dal punto di vista di PHP, quindi il limite di 300 secondi offre meno protezione di quanto possa sembrare. Ecco perché l’impostazione di timeout espliciti all’interno dei plugin tramite http_request_timeout è il modo più affidabile per terminare una chiamata esterna sospesa a livello di applicazione.
Quando una richiesta va in timeout, il thread si libera e il contenitore inizia un recupero che in genere richiede un paio di minuti.
Usare Kinsta APM per distinguere i colli di bottiglia dell’hosting da quelli di terze parti
Lo strumento APM di Kinsta acquisisce i dati con data e ora dei processi PHP, delle query MySQL e delle chiamate HTTP esterne. È il modo per monitorare il divario di prestazioni tra l’hosting e le dipendenze di terze parti.
L’APM si attiva dalla sezione APM di MyKinsta, quindi si sceglie una finestra di monitoraggio tra quattro opzioni predefinite comprese tra due e 24 ore. Poiché l’APM di Kinsta utilizza risorse aggiuntive del server, l’approccio giusto è quello di attivarlo quando si sospetta che si stia verificando un problema o che questo possa essere riprodotto.
Una volta che l’APM è in funzione, puoi osservare una serie di grafici, diagrammi e visualizzazioni in quattro sezioni: Transazioni, WordPress, Database ed Esterne. Quest’ultima è fondamentale per capire dove si verificano i colli di bottiglia.
Usare la schermata “Esterne” in Kinsta APM
La scheda Esterne elenca tutte le richieste HTTP esterne che esegue il tuo sito, comprese le chiamate avviate da plugin e temi per l’elaborazione dei pagamenti, il calcolo delle spedizioni, le integrazioni CRM e le analisi. Ogni voce mostra la durata totale, massima e media, oltre alla velocità di richiesta al minuto.
Ad esempio, un’API di pagamento che compare in cima all’elenco, con una durata massima misurata in più secondi, indica chiaramente che il gateway è la fonte del problema.
Tracciamento delle transazioni
Cliccando sull’URL di una richiesta nella scheda Esterne si apre un elenco di campioni di transazioni. Selezionando un campione specifico, si apre la cronologia del tracciamento delle transazioni, che mostra una ripartizione completa di tutti i processi che si sono verificati, con ogni processo visualizzato come un intervallo di tempo.
Gli intervalli che consumano più del 5% del tempo totale della transazione appaiono in arancione; quelli che consumano più del 25% appaiono in rosso.
Le tracce aiutano a stabilire le priorità delle dipendenze da ottimizzare o sostituire per prime. Ad esempio, se una chiamata HTTP esterna a un’API di pagamento occupa cinque secondi di una transazione di 5,5 secondi, l’infrastruttura di hosting gestisce tutto il resto in mezzo secondo.
Per utilizzare Kinsta APM durante un problema sospetto, il flusso di lavoro da svolgere è il seguente:
- Abilita il monitoraggio APM e seleziona una durata che copra la finestra del problema.
- Riproduci il problema se non si sta verificando (o aspetta che lo strumento acquisisca dati in tempo reale).
- Lascia che i dati si accumulino, poi apri la scheda Esterne, clicca su qualsiasi richiesta esterna per aprire la traccia della transazione ed esamina le durate dell’intervallo.
Se le chiamate HTTP esterne appaiono in cima ai risultati con durate che rappresentano la maggior parte del tempo della transazione, hai le informazioni necessarie per iniziare a risolvere il problema.
Strategie operative per la gestione delle dipendenze di terze parti
L’isolamento dei container limita i danni dei guasti esterni, ma anche il modo in cui carichi e chiami i servizi esterni. Anche con un hosting ben strutturato, le dipendenze di terze parti devono essere gestite in modo proattivo a livello di applicazione.
Modelli di caricamento asincrono per gli script non critici
WordPress carica gli script in modo sincrono per impostazione predefinita, il che significa che uno script nell’heading del documento blocca il browser dalla visualizzazione del contenuto finché non termina il download e l’esecuzione. Per gli script di analisi, gli strumenti di heat mapping e l’automazione del marketing, ciò significa che un server di terze parti lento blocca l’intera pagina.
La distinzione da capire è che il caricamento tramite sync e async produce risultati diversi quando un server esterno è lento:
- Il caricamento sincrono (bloccante) blocca l’analisi dell’HTML finché lo script non viene scaricato ed eseguito. Se il server esterno è sotto carico, la pagina rimane in attesa.
- Il caricamento asincrono permette al browser di continuare ad analizzare l’HTML e a renderizzare i contenuti mentre lo script si carica in background. Se il server esterno è lento, la pagina viene visualizzata comunque.
WordPress supporta in modo nativo le strategie di caricamento async e defer attraverso wp_enqueue_script(). Entrambe impediscono agli script non critici di bloccare il rendering della pagina, ma si comportano in modo diverso: defer esegue gli script in ordine (quindi va bene per gli script con dipendenze), mentre async esegue gli script non appena vengono caricati, indipendentemente dall’ordine.
L’uso di async è ideale per i tracker standalone in cui l’ordine di esecuzione non ha importanza.
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 ]
);
} );Tuttavia, gli script critici per il checkout spesso necessitano di un comportamento di caricamento più attento rispetto ai tag analitici o di marketing, e alcune integrazioni di pagamento potrebbero dover rimanere bloccate o ordinate per evitare di interrompere il checkout. In breve, gli script non critici che possono fallire senza interrompere la pagina possono essere async o defer; gli script di cui l’utente ha bisogno per completare una transazione no.
Configurazione del timeout per le chiamate API esterne
Il max_execution_time predefinito di Kinsta è abbastanza lungo per operazioni complesse, ma troppo lungo per far aspettare un utente. Per questo motivo, un plugin che effettua chiamate API esterne dovrebbe impostare il proprio limite di timeout piuttosto che affidarsi al limite a livello di server.
WordPress ha come impostazione predefinita un timeout HTTP di 5 secondi per le richieste esterne, a meno che un plugin o un filtro non lo sovrascriva. Se un plugin ha bisogno di un limite diverso, WordPress fornisce un filtro per questo: http_request_timeout. Viene eseguito prima che venga effettuata una richiesta e accetta sia il valore di timeout corrente che l’URL di destinazione, in modo da poter impostare limiti diversi per servizi diversi:
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 );Questo tipo di limite significa che un servizio che fallisce restituisce un errore all’utente in modo rapido, invece di occupare un thread PHP. Mantenere i timeout a livello di plugin ben al di sotto del limite massimo del server impedisce a una singola API lenta di consumare un thread per un tempo irragionevole.
Tuttavia, aumentare i valori di timeout non risolve le API lente, ma previene i guasti prematuri quando un servizio funziona ma è sotto carico. L’approccio giusto è quello di un timeout breve che fallisce rapidamente e passa a un fallback.
Meccanismi di fallback e graceful degradation
I fallback mantengono il sito funzionante durante i guasti esterni, invece di mostrare un errore. Il modello utilizza i transient di WordPress per memorizzare nella cache le risposte API che hanno avuto successo, quindi serve i dati memorizzati nella cache quando una chiamata live fallisce.
Ecco un esempio:
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 ],
];
}Il transient di un’ora gestisce la normale cache per evitare chiamate API non necessarie. Il transient di 24 ore si aggiorna solo quando l’API live restituisce una risposta di successo, consentendo al tuo sito di tornare alla risposta di successo più recente. Quando l’API non funziona, il sito mostra le tariffe di spedizione del giorno prima invece di un errore.
Il Graceful Degradation consente di mantenere le funzionalità principali anche quando i servizi esterni non sono disponibili. Funziona meglio con un’infrastruttura di hosting che limita i guasti a livello di container, in modo che un problema di dipendenza non consumi risorse.
Il tuo hosting deve fare di più che dare velocità al tuo sito
I guasti di terze parti sono parte integrante della gestione di un sito WordPress con dipendenze reali. Quello che puoi controllare è la quantità di sito che viene utilizzata, che è determinata da come risponde l’ambiente di hosting.
L’utilizzo di un’infrastruttura che implementa l’isolamento dei container, un pool di thread PHP dedicato, limiti di timeout integrati e il monitoraggio delle applicazioni permette di distinguere un problema di hosting da un problema di dipendenze.
Se vuoi scoprire come l’infrastruttura di Kinsta gestisce questo aspetto per i siti WordPress, dai un’occhiata ai piani di hosting di Kinsta. In alternativa, parla con il team di Kinsta per capire come Kinsta può essere utile alla tua configurazione specifica.
