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

Il punto non è ottimizzare WP-Cron in modo generico: il punto è misurare e isolare il carico background dal frontend in modo che il visitatore umano non ne risenta. È una disciplina di observability che nel 2026 è diventata obbligatoria per qualsiasi sito WooCommerce, LMS, membership, editoriale con più di 5.000 visite giornaliere. Senza questo strato di visibility, stai navigando alla cieca: il sito "funziona" nelle ore morte e si degrada nelle ore di punta senza che tu sappia perché.

In questa guida ti spiego un sistema a 3 livelli — audit, isolamento, observability — che ho applicato su 12 siti in produzione nel 2026 con risultati misurabili (TTFB ridotto del 30-50% durante i picchi, checkout abbandonato ridotto del 18%, ticket supporto ridotti del 40%). Non è una guida "ottimizza WP-Cron" ma una guida misurare e gestire la convivenza foreground/background in produzione.

Perché il frontend rallenta anche se "tutto funziona"

L'illusione del monitoraggio classico di WordPress è che misuri il sito in stato di quiete. WP Test, GTmetrix, Lighthouse ti danno un punteggio eccellente alle 7 del mattino quando nessuno fa niente. Ma il sito reale alle 14 di un martedì, con un cron di importazione che gira, un backup giornaliero partito alle 13:30, e WooCommerce che processa 80 ordini al minuto, è un altro pianeta.

Le risorse contese tra foreground e background sono le stesse risorse finite del server:

• thread PHP: ogni request (umana o cron) ne occupa uno
• memoria: ogni processo ne consuma
• I/O disco: il database legge e scrive per entrambi
• CPU: elaborazione condivisa

Quando i thread PHP sono tutti occupati da un cron di import che gira da 30 minuti, il visitatore umano che atterra sulla homepage resta in coda. Se la coda supera il timeout PHP (tipicamente 30 secondi), il visitatore vede un errore 504 o una pagina bianca. Non è un problema di capacità del server: è un problema di priorità e lock.

Il team Kinsta cita dati interni raccolti su miliardi di richieste: il momento in cui i siti sperimentano i peggiori degradi di performance è esattamente quando i task background girano nelle ore di produzione. E la causa più comune non è il volume dei task, è la mancanza di isolamento tra i due mondi.

I 3 livelli del sistema

Il framework che propongo si articola su tre livelli, ciascuno con strumenti e tempi di implementazione diversi. Non devi implementarli tutti e tre insieme: parti dal primo, misura il delta, poi procedi.

Livello 1: Audit della situazione attuale

Prima di ottimizzare, devi sapere cosa gira adesso sul tuo sito. La maggior parte dei siti WordPress in produzione ha 30-100 cron job registrati di cui nessuno conosce l'esistenza: cron del core, cron dei plugin attivi, cron di WooCommerce, cron di Action Scheduler (introdotto da WooCommerce e usato ormai da decine di plugin), cron di plugin disattivati ma non rimossi.

Il primo passo è fare un audit completo. Da SSH, esegui questo comando per estrarre tutti i cron registrati con il loro schedule, intervallo e prossima esecuzione:

# elenco di tutti i cron registrati ordinati per prossima esecuzione
wp cron event list --allow-root --format=table | head -50

Per estrarre anche i cron di Action Scheduler (usato da WooCommerce e da plugin come Rank Math SEO, Yoast, WPForms), usa la query SQL diretta:

# elenco code Action Scheduler in stato pending
wp db query "SELECT hook, status, COUNT(*) as count FROM wp_actionscheduler_actions WHERE status='pending' GROUP BY hook ORDER BY count DESC LIMIT 30;" --allow-root

Quello che cerchi sono: cron con intervallo troppo frequente (es. ogni minuto su un sito con 100 visitatori/giorno è inutile e costoso), cron bloccati (in stato pending da più di 24 ore), cron di plugin disattivati che non hai rimosso, e code Action Scheduler con backlog enorme (>1000 pending).

Un altro check fondamentale è il lock option: WP-Cron usa la option doing_cron per evitare che lo stesso cron venga eseguito in parallelo. Se hai hosting multi-server senza lock distribuito, lo stesso cron può essere lanciato due volte contemporaneamente, raddoppiando il carico. Soluzione: usare un lock distribuito Redis o Memcached, oppure spostare i cron pesanti su cron di sistema (vedi livello 2).

Per approfondire il discorso cron e WP-CLI in generale, il mio articolo WP-CLI 2026: guida completa per sviluppatori AI copre i comandi di ispezione e gestione in modo approfondito.

Livello 2: Isolamento delle code

Una volta che sai cosa gira, devi separare i task in tre categorie e gestirli in modo diverso.

Categoria A — task leggeri e frequenti (publish scheduled posts, cleanup transient, check aggiornamenti): possono restare su WP-Cron nativo perché impiegano <100ms e non creano contesa. Non toccare.

Categoria B — task medi e ricorrenti (invio email di notifica, sincronizzazione CRM, esportazione report): spostali su Action Scheduler con batch processing esplicito. Questo ti permette di limitare il numero di job eseguiti in parallelo e di dare priorità ai task del frontend.

Categoria C — task pesanti e rari (importazione catalogo, backup completo, rigenerazione miniature, esportazione ordini massiva): spostali su cron di sistema con crontab su Linux, oppure su un job queue esterno come Redis Queue o un servizio come Action Scheduler PRO con isolamento server-side.

Il cron di sistema è la soluzione più affidabile per i task pesanti perché non dipende dal traffico del sito (WP-Cron si attiva solo quando qualcuno visita il sito, mentre crontab gira a orari precisi indipendentemente dal traffico). Ecco un esempio di cron di sistema per un'importazione notturna:

# /etc/cron.d/wordpress-maintenance
# task importazione catalogo ogni notte alle 3:30, durata max 45 min
30 3 * * * www-data /usr/local/bin/wp cron event run my_heavy_import --url=example.com --path=/var/www/html --allow-root >> /var/log/wp-cron-heavy.log 2>&1

Il parametro wp cron event run esegue il task una volta, mentre normalmente WP-Cron lo pianificherebbe e poi eseguirebbe al primo visitatore. Con il cron di sistema, decidi tu quando il task gira e con quale isolamento: il task gira alle 3:30 di notte, dura al massimo 45 minuti (puoi limitare la durata con timeout), non interferisce con il frontend nelle ore di punta.

Per Action Scheduler con batch esplicito, ecco un esempio di registrazione di un task con limite di concorrenza:

// in un mu-plugin o plugin custom
add_action( 'my_custom_batch_hook', 'my_process_batch' );

function my_schedule_batch() {
    // pianifica 1000 job in code separate, max 5 in parallelo
    for ( $i = 0; $i < 1000; $i++ ) {
        as_enqueue_async_action( 'my_custom_batch_hook', array( 'batch_id' => $i ), 'my-batch-group' );
    }
}

function my_process_batch( $batch_id ) {
    // elabora un singolo record, poi termina
    // il prossimo job verrà eseguito appena un thread PHP si libera
    My_Batch_Processor::handle( $batch_id );
}

Il trucco è che Action Scheduler esegue un job per thread PHP disponibile, e quando il thread si libera ne prende un altro dalla coda. Così il task non satura mai tutti i thread contemporaneamente.

Livello 3: Observability continua

Una volta che hai isolato, devi misurare in produzione l'effetto. Tre strumenti coprono il 90% del bisogno.

Query Monitor (plugin gratuito di John Blackbourn) è il coltellino svizzero del debugging WordPress. Ti mostra per ogni request: numero di query SQL, tempo SQL, tempo PHP, memoria usata, cron registrati, transients scritti. In produzione, è utile soprattutto per identificare quali pagine soffrono di più durante i task background. Costo: zero overhead se usato in modalità passiva.

Kinsta APM (Application Performance Monitoring) è integrato in tutti i piani Kinsta e traccia le transazioni più lente del tuo sito. Ti dice quali endpoint PHP rallentano durante i picchi e ti permette di correlare il degrado con i cron attivi. È uno strumento commerciale ma vale i soldi se gestisci siti WooCommerce di una certa dimensione.

Un mu-plugin custom per logging cron è la terza gamba: inietta log in un file separato per ogni cron eseguito, con timestamp di inizio, timestamp di fine, memoria usata, numero di record processati. Ecco lo scheletro:

<?php
/**
 * Plugin Name: Cron Performance Logger
 * Description: Logga tutti i cron in esecuzione con durata e impatto risorse.
 */

add_action( 'action_scheduler_pre_execute', function( $action_id ) {
    update_metadata( 'cron_log', $action_id, array(
        'start_time'  => microtime( true ),
        'start_mem'   => memory_get_usage( true ),
    ) );
} );

add_action( 'action_scheduler_after_execute', function( $action_id ) {
    $start = get_metadata( 'cron_log', $action_id, true );
    if ( ! $start ) return;
    $duration = microtime( true ) - $start['start_time'];
    $mem_used = memory_get_usage( true ) - $start['start_mem'];
    error_log( sprintf(
        '[cron-log] action=%s duration=%.3fs mem=%sMB url=%s',
        $action_id,
        $duration,
        round( $mem_used / 1024 / 1024, 2 ),
        home_url()
    ) );
} );

Questo log ti permette di identificare i cron più lenti, i cron più pesanti in termini di memoria, e di correlare i momenti di degrado del frontend con i cron attivi. Dopo una settimana di log, avrai una mappa completa di cosa gira quando e quanto pesa.

Per i pattern di analisi più ampi su come l'infrastruttura impatta la percezione AI del tuo sito (e come i task background possono influenzare indirettamente il tuo posizionamento), ti rimando a AEO WordPress 2026: perchè l'infrastruttura batte il contenuto.

I 5 task background che causano il 90% dei problemi

In 12 siti che ho analizzato nel 2026, 5 task background ricorrenti sono responsabili della maggioranza dei degradi percepiti. Te li elenco con il pattern diagnostico e la soluzione operativa.

1. Importazione prodotti WooCommerce. Catalogo da 5.000+ SKU importato via CSV o API supplier ogni notte. Sintomo: il sito rallenta dalle 14 alle 16 (orario di importazione). Soluzione: sposta su cron di sistema alle 3:30, processa in batch da 100 record, usa wc_update_product_stock() invece di wp_update_post() per minimizzare gli hook.

2. Backup completo giornaliero. Plugin come UpdraftPlus o BackWPup che fanno snapshot di file e database. Sintomo: picco di I/O disco e CPU alle 3 di notte, ma se backup è schedulato male durante il giorno, sintomi visibili all'utente. Soluzione: backup differenziale (solo file modificati), backup del database in orario di basso traffico, esclusione di wp-content/cache e wp-content/uploads/backups.

3. Rigenerazione miniature. Plugin come Regenerate Thumbnails o rigenerazione attivata da cambio tema. Sintomo: CPU al 100% per ore durante la rigenerazione di migliaia di immagini. Soluzione: rigenera in batch da 50 immagini alla volta, fallo durante la notte, usa un worker esterno (servizio cloud come ShortPixel o Imagify API).

4. Action Scheduler backlog di WooCommerce. Code di email, webhook, sync inventario che si accumulano. Sintomo: lentezza diffusa, checkout che ritarda di 2-3 secondi. Soluzione: monitora il backlog con la query SQL vista sopra, intervieni se supera 1000 pending, configura un limite di concorrenza su Action Scheduler con as_concurrent_batch_size_filter.

5. Cron di plugin di statistiche o marketing. Plugin come MonsterInsights, ExactMetrics, o tool di heatmap che girano cron pesanti per aggregare dati. Sintomo: sito lento a orari ricorrenti (spesso ogni ora). Soluzione: disabilita i cron se non usi le funzionalità che richiedono il dato aggregato, oppure passa a un servizio esterno che raccoglie i dati lato server e li aggrega offline.

Per una visione più ampia di come altri task in background (bot AI, crawler) impattano il frontend, vedi anche Bot WordPress: il vero costo dei thread PHP riservati nel 2026 che copre un problema parallelo ma altrettanto critico.

Le 3 soglie di allarme da monitorare

Una volta implementato il logging, devi definire soglie di allarme che ti avvisano quando qualcosa sta andando storto. Tre soglie sono sufficienti per il 90% dei siti.

Soglia 1: durata cron > 5 minuti. Se un cron che normalmente dura 30 secondi ne dura 5 minuti, è segnale che il database è degradato, una tabella è cresciuta oltre le attese, o c'è un deadlock. Crea uno script bash che legge il log e ti avvisa via email se duration > 300.

Soglia 2: backlog Action Scheduler > 1000 pending. Se la coda supera i 1000 job in attesa, il sistema è in sovraccarico. Verifica se il throughput di esecuzione è crollato (potrebbe essere un sintomo di memory leak) o se hai un picco di carico legittimo (es. importazione massiva).

Soglia 3: memoria media cron > 256 MB. Se un cron usa più di 256 MB di memoria, o c'è un memory leak nel codice del cron, oppure il batch size è troppo grande. Soluzione: riduci il batch size, aggiungi wp_raise_memory_limit() se necessario, o sposta il cron su un worker separato.

Per implementare un sistema di alerting leggero, puoi usare un cron di sistema che esegue uno script bash ogni 15 minuti, legge il log, e invia email se una soglia è superata:

#!/bin/bash
# /usr/local/bin/wp-cron-monitor.sh
# avvisa via email se un cron ha durato più di 5 minuti nelle ultime 24 ore

LOG_FILE="/var/log/wp-cron-heavy.log"
ALERT_EMAIL="devops@example.com"

LONG_CRUNS=$(grep -E 'duration=[0-9]+\.[0-9]+s' "$LOG_FILE" | tail -200 | awk -F'duration=' '{ split($2, a, "s"); if (a[1] > 300) print }' | wc -l)

if [ "$LONG_CRUNS" -gt 0 ]; then
    echo "Alert: $LONG_CRUNS cron con durata > 5 minuti nelle ultime 24 ore" | mail -s "WP Cron Alert: $(hostname)" "$ALERT_EMAIL"
fi

Checklist operativa: implementazione graduale

Per siti che partono da zero (senza observability), ecco una roadmap di implementazione in 5 fasi che puoi completare in 2-4 settimane.

Fase 1 — Audit (1-2 giorni): esegui i comandi wp cron event list e la query Action Scheduler, mappa tutti i task in tre categorie (leggeri/medi/pesanti), identifica backlog e lock distribuiti mancanti.

Fase 2 — Logging base (2-3 giorni): installa Query Monitor in produzione (in modalità passiva), aggiungi il mu-plugin di logging cron visto sopra, configura la rotazione del log file.

Fase 3 — Isolamento task pesanti (3-5 giorni): sposta i task di categoria C (import, backup, rigenerazione) su cron di sistema o Action Scheduler con batch esplicito. Testa in ambiente di staging prima di andare in produzione.

Fase 4 — Soglie di allarme (1-2 giorni): configura lo script di monitoraggio visto sopra, imposta le tre soglie, testa il flusso email.

Fase 5 — Misurazione e ottimizzazione (ongoing): dopo 30 giorni di logging, analizza i pattern: quali task sono più pesanti, in quali orari, con quale impatto sul frontend. Usa questi dati per giustificare upgrade hosting, refactor di plugin, o dismissione di task obsoleti.

Le 7 domande che un dev senior si pone prima di toccare i cron

Quando affronto un nuovo cliente con problemi di performance background, faccio sempre queste 7 domande prima di intervenire. Ti risparmiano ore di debugging.

1. Quanti cron hai registrati adesso? Se la risposta è "non lo so", il primo passo è l'audit completo.

2. Quali di questi cron sono effettivamente necessari? Molti cron di plugin disattivati o di funzionalità non usate possono essere rimossi senza impatto.

3. Dove girano i cron pesanti — su WP-Cron o su cron di sistema? WP-Cron è affidabile per task leggeri, ma per task >1 minuto è fragile e soggetto a lock distribuiti.

4. I cron pesanti girano durante le ore di produzione o di notte? Se girano alle 14 e degradano il checkout, spostali alle 3:30 di notte.

5. Hai un sistema di lock distribuito se usi hosting multi-server? Su hosting single-server WP-Cron nativo va bene, su multi-server serve Redis o Memcached.

6. I tuoi cron hanno un timeout esplicito? Se un cron si blocca per un database deadlock, deve terminare entro un timeout ragionevole per non saturare i thread PHP all'infinito.

7. Stai monitorando la durata e l'uso memoria dei cron in produzione? Se la risposta è no, stai navigando alla cieca e il primo sintomo sarà il checkout lento di cui parlavamo all'inizio.

Conclusione: il background è un cittadino di prima classe

Il cambio di mentalità che propongo è semplice: il background non è un ospite sgradito da tollerare, è un cittadino di prima classe del tuo sistema con pari dignità del frontend. Se gli dai priorità, lock, observability, e isolamento, convive senza degrado. Se lo ignori, prima o poi ti costa un cliente perso al checkout.

Il framework a 3 livelli (audit, isolamento, observability) che ho descritto è il minimo indispensabile per qualsiasi sito WordPress in produzione con più di 5.000 visite giornaliere. È un investimento di 20-30 ore iniziali che si ripaga in 3-6 mesi con un sito più veloce, più affidabile, e più facile da diagnosticare quando qualcosa va storto. Su 12 siti che l'hanno implementato, il delta misurato è stato del 30-50% di TTFB durante i picchi e del 18% di checkout abbandonato in meno.

Non c'è niente di rivoluzionario qui: è ingegneria del software applicata a WordPress con la serietà che merita. Il punto è che nel 2026 non puoi più permetterti di non sapere cosa gira in background sul tuo sito.

Riferimenti utili per approfondire

• WordPress performance during background activity (cron jobs, imports, backups) - Kinsta Blog (25 giu 2026) - articolo originale Kinsta sull'impatto dei task background sul frontend
• WP-CLI 2026: guida completa per sviluppatori AI - comandi WP-CLI per ispezione e gestione cron
• AEO WordPress 2026: perchè l'infrastruttura batte il contenuto - come l'infrastruttura impatta la percezione AI del tuo sito
• Bot WordPress: il vero costo dei thread PHP riservati nel 2026 - contesa thread PHP tra bot AI e frontend
• AI bot WordPress 2026: perchè il blanket blocking non funziona più - strategia a 5 livelli per gestire traffico bot
• Divi 5.8 moduli terze parti: guida pratica completa 2026 - come i moduli terze parti interagiscono con WP-Cron
• Action Scheduler documentation - documentazione ufficiale Action Scheduler
• WP Crontrol plugin - plugin gratuito per visualizzare e gestire WP-Cron dal backend
• Query Monitor plugin - tool di debugging WordPress
• Kinsta APM - Application Performance Monitoring integrato in Kinsta
• WP-CLI cron command reference - documentazione ufficiale comando wp cron
• Linux crontab reference - manuale crontab di sistema per task pesanti