WooCommerce dichiara richieste Store API e REST più rapide del 30-42% nella versione 11.1. Il dato è interessante, ma non dice quanto guadagnerà il tuo negozio: cache, hosting, catalogo ed estensioni cambiano il risultato. La conseguenza pratica è semplice. Prima dell’aggiornamento serve una misura ripetibile su staging, altrimenti un miglioramento reale può passare inosservato e una regressione può arrivare fino al checkout.

Il problema non è aggiornare, ma confrontare

WooCommerce 11.1 evita di registrare blocchi e pattern nelle richieste che non possono renderli o modificarli. Nei test del team WooCommerce, questa modifica risparmia 13-18 millisecondi e riduce del 30-42% il tempo delle richieste Store API e WooCommerce REST interessate. Non significa che ogni pagina prodotto diventerà più veloce della stessa percentuale: frontend, amministrazione ed editor continuano a registrare ciò che serve, mentre la nuova guardia interviene su contesti precisi. Se aggiorni senza una baseline, vedrai solo una sensazione generale o un singolo numero contaminato da cache e rete. Per una PMI il controllo utile non è “il sito sembra più rapido”, ma “lo stesso endpoint, con lo stesso catalogo e la stessa configurazione, risponde meglio senza rompere le integrazioni”. Questo confronto va preparato prima di toccare la produzione.

Misura la Store API su staging in dieci richieste

Crea o aggiorna una copia staging, verifica che prodotti, plugin e tema corrispondano al live, poi svuota la cache applicativa una sola volta. Scegli un endpoint pubblico che rappresenti un flusso reale, per esempio una lista di prodotti della Store API. Esegui dieci richieste consecutive e registra il tempo al primo byte. La prima può includere il riscaldamento della cache: non cancellarla, ma leggila separatamente dalle successive. Un comando minimale è questo, sostituendo il dominio con quello dello staging:

for i in {1..10}; do
  curl -sS -o /dev/null \
    -w '%{time_starttransfer}\n' \
    'https://staging.example.com/wp-json/wc/store/v1/products?per_page=10'
done

Salva i valori, aggiorna WooCommerce e completa l’eventuale migrazione del database. Ripeti lo stesso test senza cambiare endpoint, quantità di prodotti, plugin o impostazioni. Confronta la mediana delle nove richieste successive alla prima: è una lettura più robusta di un singolo picco e resta abbastanza semplice da rifare a ogni manutenzione.

Controlla le estensioni che renderizzano blocchi nelle API

Il guadagno nasce dal lavoro che WooCommerce non esegue più, quindi il test non può fermarsi alla velocità. Un’estensione personalizzata potrebbe aspettarsi che i blocchi WooCommerce siano già registrati dentro una richiesta REST, Store API, AJAX o webhook. Il segnale tipico è markup del blocco restituito grezzo oppure HTML statico privo dell’output dinamico. Le descrizioni di prodotti e variazioni sono gestite on demand da WooCommerce e non richiedono interventi; anche i blocchi registrati direttamente dall’estensione con la Block API standard non sono coinvolti. Dopo l’update prova almeno elenco prodotti, ricerca, carrello, checkout e le integrazioni che leggono il catalogo. Se un plugin proprietario renderizza davvero blocchi in uno dei contesti esclusi, lo sviluppatore può usare il filtro woocommerce_should_register_blocks solo per quella richiesta. Attivarlo ovunque annullerebbe il vantaggio e nasconderebbe una dipendenza progettata male.

L’errore da evitare: testare sul live e guardare la media

Non aggiornare la produzione per “vedere se va meglio”. La documentazione WooCommerce raccomanda backup corrente, prova su staging e verifica dei flussi del negozio prima di riaprire il checkout; la versione 11.1 richiede anche un aggiornamento del database. Evita inoltre di confrontare una media prima e dopo: una sola richiesta lenta può spostarla e farti inseguire un falso problema. Conserva endpoint, dieci tempi, mediana, versione WooCommerce e lista delle estensioni attive in una nota di manutenzione. La mia take è questa: un’ottimizzazione di core vale solo se diventa un test locale ripetibile. Il 30-42% ufficiale è un buon motivo per misurare, non una garanzia da copiare in un report cliente. Se devi strutturare la finestra di manutenzione, parti anche dalla guida all’aggiornamento sicuro di WordPress: rollback e controlli devono esistere prima del pulsante “Aggiorna”.

Fonti: WooCommerce Developer Blog, block registration e prestazioni API; WooCommerce 11.1.0 Release Notes; WooCommerce, procedura ufficiale di aggiornamento.