WordPress e le API di terze parti: come evitare i blackout

A fine luglio 2026 ho ricevuto la chiamata che ogni gestore di e-commerce odia fare: "il checkout ogni tanto impiega trenta secondi, e alcuni clienti vedono una pagina di errore". Non sempre. Non per tutti. A intermittenza, il caso peggiore da diagnosticare. Il sito girava su un buon hosting, il TTFB medio era sotto i 300 millisecondi, la cache funzionava. Eppure, due o tre volte al giorno, tutto si fermava.

Dopo due ore di log ho trovato il colpevole: non era il server, non era WordPress. Era il gateway di pagamento che, in certi momenti della giornata, rispondeva in 20-25 secondi. E ogni volta che lo faceva, un processo PHP del mio cliente restava lì, fermo, ad aspettare.

Un articolo pubblicato da Kinsta a fine agosto 2026 — How WordPress hosting handles partial failures — mette a fuoco esattamente questo problema, che secondo me è uno dei più sottovalutati della gestione WordPress: le dipendenze esterne. In questa guida lo rileggo con un'ottica operativa: come riconoscere il problema, come distinguerlo da un vero problema di hosting, e soprattutto come difendere il sito con interventi a livello applicativo.

Perché un'API esterna può bloccare un intero sito WordPress

Un sito WordPress moderno non vive mai isolato. Pensiamo a cosa dipende da un checkout WooCommerce in un dato momento: il gateway elabora il pagamento, un'API di spedizione calcola le tariffe live, un servizio fiscale gestisce la conformità. E se usciamo dall'e-commerce, la lista si allunga: script di analytics, sincronizzazione CRM, widget di chat live, feed di affiliate marketing. Ognuno vive su un server esterno che non controlliamo.

Il punto tecnico è questo: quando WordPress serve una pagina che deve aspettare una risposta esterna, un thread PHP resta bloccato fino alla fine della richiesta. Non fa nient'altro. Se il gateway risponde in 30 secondi, quel thread è sequestrato per 30 secondi interi.

Il meccanismo: thread PHP in attesa

Se un solo visitatore incappa in un gateway lento, il danno è contenuto. Ma mettiamo il caso che cinque utenti arrancano insieme sul checkout: cinque thread sequestrati. Su un hosting condiviso, dove più siti dividono lo stesso pool di PHP worker, basta questo per esaurire le risorse disponibili. A quel punto gli altri visitatori non vedono il sito lento: vedono un errore 502 o 504 in attesa di un thread libero.

È la differenza tra "il mio sito è lento" e "il mio sito è giù". E la seconda, come ho scritto più volte, costa molto di più in termini di reputazione e conversioni.

Il gap di visibilità: 502 e 504 che sembrano colpa dell'hosting

Qui sta la trappola diagnostica. Un errore 504 ha sempre lo stesso aspetto, qualunque sia l'origine. La reazione naturale — mia inclusa, i primi tempi — è aprire il pannello dell'hosting e guardare CPU, memoria, metriche infrastrutturali. E magari tutto sembra normale, perché il problema non è lì.

Kinsta lo chiama "visibility gap": i fallimenti parziali delle dipendenze esterne generano gli stessi sintomi di un problema infrastrutturale, ma vivono fuori dal controllo dell'host. Se non sai dove guardare, passi ore a incolpare il fornitore sbagliato. Ho visto clienti cambiare hosting due volte in sei mesi per un problema che avrebbe risolto un timeout di otto secondi configurato in un plugin.

Come capire se il problema è tuo o del fornitore

La prima domanda da farsi quando il sito rallenta a intermittenza non è "cos'ha il server?" ma "chi aspetta il server?". La risposta sta nel tracciamento delle chiamate HTTP in uscita.

Tracciare le chiamate esterne

Gli strumenti giusti dipendono dall'hosting: se usi Kinsta, l'APM integrato ha una sezione "External" che elenca ogni richiesta HTTP in uscita con durata totale, massima, media e frequenza al minuto. Con New Relic o Query Monitor ottieni informazioni analoghe: l'importante è avere una vista esplicita di cosa il sito aspetta da chi.

Il workflow che uso quando sospetto un problema è semplice:

1. Attivo il monitoring su una finestra che copra il periodo in cui il problema si è manifestato
2. Riproduco il problema, o aspetto che i dati si accumulino
3. Apro la lista delle chiamate esterne e ordino per durata massima
4. Se una chiamata occupa la maggior parte del tempo di transazione, ho trovato il colpevole

Il valore di questo approccio è che converte una sensazione ("il sito ogni tanto si blocca") in un dato ("il gateway X risponde in 12 secondi medi, picchi a 28"). Con il dato, puoi intervenire.

I numeri che guardo io

Nelle manutenzioni mensili che eseguo per i clienti, per ogni chiamata esterna critica tengo d'occhio tre soglie: la media sopra il secondo è un campanello, il massimo oltre i cinque secondi è un problema, la frequenza di errore sopra l'1% è un'emergenza. Sono soglie mie, non standard ufficiali, ma in otto anni di assistenza WordPress mi hanno evitato più di un blackout.

Le cinque contromisure a livello applicativo

L'hosting può limitare i danni — l'isolamento a container di cui parla l'articolo Kinsta è un esempio — ma la vera difesa si costruisce a livello applicativo. Queste sono le cinque misure che applico sistematicamente.

1. Timeout espliciti su ogni chiamata critica

Questa è la scoperta più importante dell'articolo Kinsta, e vale la pena spiegarla bene. Su Linux, il timer di esecuzione PHP non conta il tempo speso in attesa su operazioni di stream, ed è esattamente quello che fa una richiesta HTTP in uscita. Un thread bloccato su un gateway che non risponde accumula quasi zero tempo di esecuzione dal punto di vista di PHP: il tetto di max_execution_time che pensavi fosse la tua protezione, qui non protegge quasi niente.

La soluzione affidabile è impostare timeout espliciti a livello di richiesta HTTP. WordPress lo consente con il filtro http_request_timeout:

// Timeout globale di cortesia: nessuna chiamata esterna oltre 10 secondi.
add_filter( 'http_request_timeout', function() {
    return 10;
} );

// Per le chiamate fatte con wp_remote_get / wp_remote_post,
// meglio ancora un timeout esplicito per ogni chiamata:
$response = wp_remote_post( $gateway_url, [
    'timeout'    => 8,
    'blocking'   => true,
    'sslverify'  => true,
] );

Otto o dieci secondi sono più che sufficienti per qualsiasi API ben fatta: se un gateway impiega di più, stai già vivendo un degrado, e meglio fallire in otto secondi che sequestrare un thread per trenta. Il fallback lo decidi tu: messaggio all'utente, tentativo con un gateway alternativo, o accodamento dell'ordine con conferma differita.

2. Async e defer per gli script non critici

Il secondo fronte sono gli script esterni lato browser: analytics, heatmap, chat, pixel di marketing. Caricati in modo sincrono, bloccano il parsing dell'HTML: se il server dello script è lento, la tua pagina aspetta lui.

Dalla versione 6.3 WordPress supporta nativamente le strategie async e defer in wp_enqueue_script(). La differenza è sottile ma importante: defer esegue gli script in ordine, ed è adatto quando ci sono dipendenze; async esegue appena possibile, ed è perfetto per tracker autonomi dove l'ordine non conta.

// Script di analytics: async, non blocca il rendering.
add_action( 'wp_enqueue_scripts', function() {
    wp_enqueue_script(
        'analytics-esterno',
        'https://www.esempio-analytics.com/tracker.js',
        [],
        null,
        [ 'strategy' => 'async' ]
    );
} );

Su un sito che ho seguito quest'estate, il solo passaggio di tre script di marketing a async ha portato l'LCP da 3,1 a 2,2 secondi. Zero costi, venti minuti di lavoro.

3. Cache delle risposte API con transient

Molte chiamate esterne servono dati che cambiano lentamente: tariffe di spedizione, tabelle IVA, listini, orari. Ogni volta che ricarichi quei dati dalla fonte, regali a un fornitore esterno il potere di rallentare il tuo sito. La cache con i transient taglia il problema alla radice:

$cache_key = 'tariffe_spedizione_v2';
$tariffe = get_transient( $cache_key );

if ( false === $tariffe ) {
    $tariffe = wp_remote_get( 'https://api.corriere.it/tariffe', [ 'timeout' => 5 ] );
    if ( ! is_wp_error( $tariffe ) && 200 === wp_remote_retrieve_response_code( $tariffe ) ) {
        set_transient( $cache_key, wp_remote_retrieve_body( $tariffe ), 30 * MINUTE_IN_SECONDS );
    }
}

Trenta minuti di TTL sono un buon compromesso per dati che cambiano poco: nel frattempo, anche se l'API del fornitore è in giù, il tuo sito continua a servire le tariffe dalla cache. Questo pattern, insieme a una cache di bordo ben configurata, è lo stesso ragionamento che ho descritto per la cache edge differenziata per i bot AI: proteggere il server dai picchi di traffico che non controlli.

4. Operazioni pesanti fuori dalla richiesta

Sincronizzare il CRM durante il checkout, generare una fattura PDF, inviare venti email: sono tutte operazioni che non devono mai stare nel ciclo di richiesta-risposta di un utente. WordPress ha WP-Cron per scaricarle in background, e i plugin di job queue permettono di accodarle con retry automatici. La regola che seguo è: la richiesta dell'utente deve durare il tempo strettamente necessario a dargli quello che ha chiesto; tutto il resto va in coda.

L'attenzione pratica: le code vanno monitorate. Una coda che si gonfia silenziosamente perché il consumer è bloccato su un'API morta è un secondo problema mascherato. Nelle manutenzioni che faccio per i clienti, controllo il backlog delle code con la stessa regolarità con cui controllo i backup: è una voce fissa del mio piano di assistenza WordPress mensile.

5. Un piano B per ogni fornitore critico

L'ultima contromisura è organizzativa, non tecnica: per ogni dipendenza critica — pagamento, spedizione, email transazionale — deve esistere un piano B documentato. Un gateway alternativo già configurato in staging. Un secondo provider email pronto a subentrare cambiando due costanti. Non serve costruire sistemi ridondanti complicati: serve sapere, il giorno in cui il fornitore principale cade per tre ore, esattamente cosa fare senza improvvisare.

La checklist che uso nella manutenzione mensile

Riassumo in cinque punti la routine con cui gestisco le dipendenze esterne dei siti che mantengo, utile anche se fai da te:

• Timeout espliciti su tutte le chiamate HTTP critiche (mai più di 10 secondi)
• Script esterni tutti in async o defer, verificati con Lighthouse ogni mese
• Transient sulle risposte API che servono dati lenti a cambiare
• Log delle chiamate fallite con notifica: un errore isolato è rumore, cinque nella stessa ora è un incidente
• Piano B documentato per ogni fornitore critico, testato almeno una volta l'anno

Se ti accorgi che il tuo sito dipende da più fornitori di quanti riesci a tenere d'occhio, è il momento di farsi aiutare: il mio servizio di assistenza WordPress include proprio questa attività di sorveglianza, mese dopo mese, prima che il problema diventi un ticket del martedì sera.

In sintesi: cosa fare adesso

Tre azioni immediate, in ordine di impatto. Primo: fai l'inventario delle chiamate esterne del tuo sito — plugin di pagamento, analytics, CRM — e verifiche che ognuna abbia un timeout esplicito. Secondo: passa gli script non critici ad async o defer; è una mezz'ora di lavoro che paga da sola. Terzo: metti in cache con i transient tutto ciò che può esserlo.

Il resto — monitoring continuo, code monitorate, piani B — è ciò che distingue un sito che si difende da uno che subisce. E se preferisci dedicarti al tuo business lasciando questa sorveglianza a qualcuno, sai dove trovarmi: l'assistenza WordPress specializzata nasce esattamente per questo.

Riferimenti utili

• How WordPress hosting handles partial failures — Kinsta
• async e defer su wpWPGUTENBERGBLOCKPLACEHOLDER0Xscript — Make WordPress Core
• Elemento script: async e defer — MDN Web Docs
• Sito WordPress lento: 12 cause e come velocizzarlo nel 2026
• Credibilità sito WordPress: hosting, uptime e E-E-A-T
• Assistenza WordPress: supporto gestito per il tuo sito