WP-Cron WordPress: ottimizzare i task background in produzione

Un cliente mi ha scritto la scorsa settimana: la homepage del mio e-commerce è lentissima dalle 14 alle 16 di ogni giorno, ma veloce il resto della settimana. Ho contattato l'hosting e mi hanno detto che è tutto a posto. La risposta è quasi sempre la stessa: alle 14 su quel sito gira un cron job di importazione catalogo che impiega 47 minuti, e mentre gira il checkout fa acqua da tutte le parti. È esattamente il tema approfondito dal team di Kinsta nel loro articolo del 25 giugno 2026 WordPress performance during background activity (cron jobs, imports, backups), che stima come il 90% dei siti WordPress in produzione conviva con task background che degradano il frontend senza che nessuno se ne accorga.

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="[email protected]"

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