Checkout WooCommerce lento o con errori: come trovare conflitti tra plugin, cache e JavaScript

Uno spinner infinito, un pulsante “Effettua ordine” che non reagisce e un pagamento acquisito ma non registrato in WooCommerce non sono lo stesso problema. Trattarli allo stesso modo porta spesso a disattivare plugin a caso, con il rischio di interrompere ordini reali o creare doppie transazioni.

Per risolvere un checkout WooCommerce lento bisogna prima individuare il punto esatto in cui il flusso si interrompe, poi raccogliere evidenze dal browser, dai log e dal gateway. Solo dopo ha senso intervenire su cache, ottimizzazioni JavaScript, plugin, tema o server.

1. Prima di intervenire: riproduci il problema senza rischiare ordini reali

Definisci uno scenario ripetibile

Un errore utile da analizzare deve poter essere riprodotto nelle stesse condizioni. Prima del test annota il tipo di checkout, il prodotto nel carrello, il paese e l’indirizzo inseriti, il metodo di spedizione, l’eventuale coupon, il gateway selezionato e se l’utente è ospite oppure autenticato.

Registra anche browser, dispositivo, azione che precede il blocco e un dettaglio decisivo: l’ordine viene creato oppure no? Senza questa informazione è facile confondere un problema di invio del checkout con un errore successivo nel pagamento o nella sincronizzazione del relativo esito.

Testa su staging con gateway sandbox

Il luogo corretto per disattivare componenti e cambiare configurazioni è uno staging aggiornato e protetto. Usa un gateway in modalità sandbox e verifica che l’ambiente non invii email reali, non chiami webhook produttivi e non possa generare addebiti o modifiche su servizi esterni.

Per il primo controllo lato browser, prova anche una finestra anonima. In DevTools puoi disabilitare temporaneamente la cache del browser durante il test: è utile per evitare che risorse locali obsolete falsino il risultato, ma non sostituisce il controllo della cache dell’hosting o della CDN.

La modalità Troubleshooting di Health Check può isolare tema e plugin soltanto per l’amministratore che esegue il test. Per un flusso che coinvolge carrello, ordini e pagamenti, tuttavia, lo staging resta l’opzione più prudente.

Non far ripetere subito il pagamento

Se il cliente riferisce un esito incerto, non invitarlo a pagare di nuovo. Controlla prima l’elenco ordini WooCommerce e la dashboard del provider: potrebbero esistere già un addebito, un’autorizzazione o un ordine creato con stato non aggiornato. Questa verifica viene prima di qualsiasi tentativo di “riprovare”.

2. Individua il punto esatto in cui il checkout si blocca

Verifica se usi checkout classico o Checkout block

La diagnosi cambia in base al tipo di checkout. Quello classico usa normalmente la pagina tradizionale e richieste AJAX WooCommerce come wc-ajax=update_order_review, per aggiornare totali, spedizione e tasse, e wc-ajax=checkout, per inviare l’ordine.

Il Checkout block, inserito tramite l’editor a blocchi, comunica invece attraverso la WooCommerce Store API, con richieste sotto /wp-json/wc/store/. Cerca quindi endpoint diversi nella scheda Network del browser.

Non cambiare dal checkout classico al blocco, o viceversa, solo per tentativi. Il passaggio può nascondere il sintomo senza risolvere la causa e introdurre incompatibilità con gateway, campi personalizzati o altre integrazioni. La compatibilità va verificata per il singolo componente.

Tabella di triage: sintomo, fase e controlli prioritari

Distingui lentezza, pagamento e sincronizzazione

Se l’ordine non viene creato, il problema è probabilmente precedente o coincidente con l’invio del checkout. Se l’ordine esiste ma il pagamento viene rifiutato, la priorità sono le note dell’ordine e i dati del gateway. Se il provider registra il pagamento ma WooCommerce resta in attesa, l’analisi deve concentrarsi su webhook e callback: una generica ottimizzazione delle prestazioni non corregge una sincronizzazione mancante.

3. Analizza Console e Network: trova la richiesta o lo script coinvolto

Procedura in cinque passaggi nei DevTools

1. Apri gli strumenti per sviluppatori del browser e vai in Console. Cancella i messaggi già presenti.
2. Riproduci una sola volta lo scenario annotato e registra il primo errore realmente comparso dopo l’azione.
3. Prendi nota del messaggio e del file indicato, compreso il percorso quando disponibile.
4. Apri Network, filtra per Fetch/XHR, svuota l’elenco e, se necessario, attiva Preserve log.
5. Ripeti lo stesso test e apri la richiesta lenta o fallita: annota URL, metodo, codice HTTP, durata e contenuto della risposta.

La panoramica ufficiale di Chrome DevTools Network aiuta a leggere le richieste e i relativi tempi. Non condividere però screenshot o esportazioni senza rimuovere cookie, nonce, token, email, indirizzi e qualsiasi dato collegato a pagamenti o clienti.

Come leggere i segnali senza conclusioni affrettate

• Pending prolungato o timeout: può indicare PHP lento, calcoli di spedizione o tasse, una query problematica, un servizio esterno o il gateway. Non identifica da solo il responsabile.
• 403: può dipendere da WAF, firewall, autorizzazione o nonce non valido. Non è automaticamente un errore di cache.
• 404: suggerisce di verificare URL, permalink, rewrite, proxy o una configurazione incoerente dopo una migrazione.
• 500: richiede il confronto con log PHP e log server nello stesso intervallo orario.
• HTML, login o redirect invece di JSON: possono essere causati da cache, sicurezza, maintenance mode, proxy o output PHP inatteso.
• Risposta -1 in AJAX: è compatibile con un nonce non valido o scaduto; la cache è una possibile causa, non l’unica.

Dal file JavaScript al componente da isolare

Un errore che punta a un file sotto wp-content/plugins/nome-plugin/ rende quel plugin un candidato concreto per il test di conflitto. Un errore in un file aggregato, differito o caricato da CDN non identifica invece subito il componente originale: in quel caso controlla prima le ottimizzazioni JavaScript e ripeti la prova con aggregazione e ritardo script disattivati nello staging.

Un messaggio rosso in Console è un indizio, non una sentenza. Deve coincidere con l’azione eseguita, con la richiesta di rete coinvolta e, quando possibile, con gli errori nei log.

4. Escludi cache, CDN e ottimizzazioni che interferiscono con il checkout

Controlla tutti i livelli di cache

Carrello, Checkout e Mio account gestiscono sessioni e dati specifici del cliente. Non devono essere distribuiti come pagine statiche condivise. Il controllo non può fermarsi al plugin visibile nella bacheca WordPress: considera cache dell’hosting, CDN o edge cache, Varnish, reverse proxy, WAF, drop-in e plugin must-use.

La documentazione WooCommerce sulla configurazione dei plugin di cache è un buon riferimento per verificare le esclusioni, ma la regola pratica è osservare il comportamento reale della richiesta dinamica nello stack effettivamente usato dal sito.

Verifica sessioni e cookie WooCommerce

Tra gli elementi da non ignorare ci sono woocommerce_cart_hash, woocommerce_items_in_cart e wp_woocommerce_session_…. Cache e proxy devono rispettare queste sessioni e non riutilizzare una risposta dinamica per altri visitatori.

Se sono presenti object cache o database cache, evita configurazioni universali copiate da altri siti. Il trattamento delle sessioni _wc_session_ dipende dall’infrastruttura: segui le indicazioni del provider e verifica il risultato con un test riproducibile.

Test controllato delle ottimizzazioni JavaScript

Nello staging disattiva temporaneamente minificazione, aggregazione, defer, delay degli script e ottimizzazioni JavaScript della CDN. Svuota poi tutti i livelli di cache, non soltanto quello del plugin WordPress, e ripeti identico scenario.

Se il problema scompare, riattiva una funzione alla volta fino a individuare la combinazione responsabile. Minificazione e defer non sono incompatibili per definizione con WooCommerce: il punto è capire se alterano gli script effettivamente necessari al checkout o al gateway.

5. Isola un conflitto tra plugin, tema e personalizzazioni

Configura un ambiente minimo su staging

Il conflict test serve a confermare una causa, non a fare tentativi casuali. Mantieni attivi WooCommerce e il gateway sandbox necessario alla prova, passa a un tema standard o a Storefront e disattiva temporaneamente gli altri plugin.

Le categorie da controllare per prime sono plugin per campi checkout, funnel, upsell, spedizioni, tasse, fatturazione, sicurezza, consenso, traduzioni, multivaluta, marketing, cache e snippet personalizzati. Ripeti ogni volta lo stesso scenario, poi riattiva un plugin o una funzione per volta.

La procedura ufficiale WooCommerce per testare i conflitti è utile soprattutto per mantenere il test ordinato e documentabile.

Quando il conflitto è confermato

Un componente è un sospetto quando l’errore scompare dopo la sua disattivazione. Il conflitto è confermato quando ricompare in modo riproducibile alla riattivazione dello stesso componente o della stessa combinazione. Questa distinzione evita di attribuire il problema all’ultimo plugin modificato senza prove sufficienti.

Se il problema dipende dal tema

Se il checkout torna a funzionare con un tema standard, controlla gli override WooCommerce, la pagina checkout personalizzata, header e footer. Verifica inoltre che il tema richiami correttamente wp_head() e wp_footer(), perché script indispensabili possono essere caricati proprio in questi punti.

Il report di stato WooCommerce può segnalare template potenzialmente obsoleti. Non cancellare gli override alla cieca: confronta il loro contenuto con il template aggiornato e conserva le personalizzazioni ancora necessarie.

6. Incrocia log, ordini e dati del gateway prima di chiedere assistenza

Confronta le fonti nello stesso intervallo orario

Metti in relazione le evidenze raccolte in Console e Network con i log in WooCommerce → Stato → Log, le note dell’ordine, il report di stato WooCommerce, i log PHP e server, i log e la dashboard del gateway. Se pertinente, controlla anche le Azioni pianificate.

Usa sempre data, ora e fuso orario coerenti. I log del gateway possono dover essere abilitati esplicitamente e possono contenere informazioni sensibili: attivali solo per il tempo necessario e non lasciarli verbosi senza motivo.

Quando usare il debug WordPress

Se devi intercettare errori PHP, puoi abilitare temporaneamente il log in staging o in una finestra controllata, senza mostrare gli errori pubblicamente:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

Le indicazioni ufficiali sono disponibili nel manuale WordPress sul debug. Proteggi il file di log, rimuovi o ruota i dati raccolti e disattiva il debug dopo la diagnosi.

Dati utili per hosting, sviluppatore o supporto gateway

Una richiesta di assistenza efficace include URL e tipo di checkout, scenario riproducibile, browser e dispositivo, data/ora con fuso, endpoint coinvolto, codice HTTP, durata e risposta anonimizzata, primo errore in Console, versioni di WordPress, WooCommerce e PHP, tema, gateway, log rilevanti, esito del conflict test e stato dell’ordine nel provider.

Se emergono webhook, WAF, codice personalizzato o transazioni reali, fermati prima di altre modifiche casuali e coinvolgi un tecnico o il supporto competente. Identificare fase e richiesta coinvolta prima di ottimizzare riduce il rischio di ordini persi, sessioni incoerenti e doppi addebiti. Per problemi non riproducibili o legati a un’integrazione complessa, un servizio di assistenza WooCommerce può analizzare lo stack con evidenze già raccolte, senza intervenire alla cieca sul sito live.