L’hosting WordPress gestito è pensato per garantire il corretto funzionamento di WordPress. Offre un ambiente ottimizzato in base al comportamento di WordPress sotto carico, alla gestione della cache e all’esecuzione del PHP.
I temi a blocchi non modificano gli aspetti fondamentali dell’hosting, ma cambiano il punto in cui si verificano i colli di bottiglia nelle prestazioni. È qui che il ruolo del provider di hosting diventa più chiaro. L’infrastruttura da sola non rende veloce un sito; un’infrastruttura mal ottimizzata si riconosce nei moderni flussi di lavoro di WordPress, specialmente quando sono coinvolti blocchi dinamici, l’editor del sito, le anteprime e le sessioni di accesso.
Per capire il perché, è utile osservare cosa succede effettivamente durante una richiesta di pagina e come le scelte di hosting influenzano l’esperienza utente quando si utilizza un’architettura basata su blocchi.
Cosa succede quando viene richiesta una pagina WordPress
Esaminiamo una semplice richiesta che restituisce una risposta 200 OK.
1: Il browser invia la richiesta
Un utente digita un URL o clicca su un link. Se l’indirizzo IP del server non è già memorizzato nella cache, il browser esegue una ricerca DNS. Quindi apre una connessione TCP e negozia una sessione TLS sicura.
Prima che WordPress entri in gioco, la richiesta passa attraverso il server web e qualsiasi livello configurato, come firewall o proxy inversi.
2: Controllo della cache
Il server verifica se esiste una versione valida della pagina richiesta memorizzata nella cache.
Se è disponibile una cache HTML a pagina intera e questa è valida, WordPress non viene eseguito. La risposta memorizzata nella cache viene restituita immediatamente.
Se non esiste alcuna voce nella cache, o se la memorizzazione nella cache viene intenzionalmente bypassata per gli utenti che hanno effettuato l’accesso, le anteprime o endpoint specifici, la richiesta prosegue verso WordPress.
3: Avvio di WordPress
WordPress carica i suoi file principali, i plugin attivi e il tema attivo. Inizializza gli hook e si prepara a risolvere la richiesta.
In questa fase, WordPress non genera ancora alcun output. Determina quale contenuto viene richiesto.
4: Risoluzione della query principale
Utilizzando regole di riscrittura e variabili di query, WordPress costruisce ed esegue la query principale del database. Determina se la richiesta riguarda un singolo post, una pagina, un archivio, un risultato di ricerca o un altro tipo di contenuto.
Solo dopo questo processo ha inizio la selezione del template.
5: Risoluzione del template
È qui che i temi a blocchi e quelli classici iniziano a differenziarsi strutturalmente.
Temi classici
WordPress valuta la gerarchia dei template e seleziona il file PHP appropriato, come single.php, page.php o archive.php. Quel file contiene la logica PHP che genera direttamente l’HTML.
Temi a blocchi
WordPress verifica se nel database esiste un template di blocco personalizzato. Se esiste, ha la priorità. In caso contrario, WordPress ricorre al file del template di blocco incluso nel tema, come single.html o index.html.
Il template selezionato viene quindi elaborato attraverso il sistema di rendering dei blocchi.
6: Assemblaggio del layout
Temi classici
Il layout viene costruito tramite template PHP. Questi template combinano markup, logica e chiamate di funzione per produrre un output HTML.
Temi a blocchi
Il layout viene assemblato da template di blocchi, parti di template e contenuto dei post. Il markup dei blocchi viene analizzato e ogni blocco viene convertito in HTML prima che venga generato l’output finale.
7: Struttura dei contenuti
Temi classici
Il contenuto dei post viene memorizzato principalmente come HTML nel database. Durante l’output, WordPress applica filtri, shortcode e altre elaborazioni prima del rendering.
Temi a blocchi
Il contenuto dei blocchi viene memorizzato come HTML con metadati dei blocchi incorporati, ad esempio:
<!-- wp:image {"id":123} -->
<img src="logo.png">
<!-- /wp:image -->Quando WordPress elabora questo contenuto, analizza la struttura del blocco, ne comprende gli attributi e il nesting e applica attributi e stili a livello di blocco, come spaziatura, allineamento e tipografia, prima di generare l’HTML finale.
8: Rendering dinamico
Il rendering dinamico è presente sia nei temi classici che in quelli a blocchi. Molti temi classici si basano su query personalizzate, widget o shortcode che generano output in fase di esecuzione.
Nelle architetture basate su blocchi, il comportamento dinamico è formalizzato attraverso blocchi dinamici. Ad esempio, un blocco Query Loop genera il proprio markup durante la richiesta utilizzando PHP anziché memorizzare HTML statico nel database.
Quando la cache a pagina intera viene bypassata, questo flusso di lavoro di rendering avviene ad ogni richiesta.
9: Stile
Per i temi classici, lo styling viene in genere fornito tramite file CSS statici messi in coda dal tema.
Per i temi a blocchi, gli stili globali definiti in theme.json e i metadati dei blocchi consentono a WordPress di generare automaticamente CSS coerenti. Ciò riduce la necessità di fogli di stile di grandi dimensioni creati manualmente e centralizza la configurazione del design.
10: Output finale
Dopo l’elaborazione di template, contenuti, blocchi e stili, WordPress produce la risposta HTML finale.
Il server invia il payload al browser. Se configurato, la risposta può quindi essere memorizzata nella cache per richieste future.
Dove i temi a blocchi spostano il carico
Il ciclo di vita delle richieste che abbiamo appena esaminato si applica sia ai temi classici che a quelli a blocchi. WordPress continua a risolvere le query, selezionare i template, eseguire il PHP e restituire l’HTML.
Ciò che cambia con i temi a blocchi non è la base, ma dove avviene il lavoro e quando non può essere saltato.
In primo luogo, i template possono risiedere nel database. Quando un utente modifica un template nell’Editor del sito, WordPress memorizza quella versione e le dà la priorità rispetto al file nella directory del tema. Ciò aggiunge flessibilità, ma significa anche che le distribuzioni e l’invalidazione della cache devono tenere conto dei template memorizzati nel database.
In secondo luogo, i blocchi dinamici rendono più visibile il rendering in fase di esecuzione. I temi classici possono generare output dinamici tramite query personalizzate, widget o shortcode. I temi a blocchi formalizzano questo template attraverso blocchi dinamici, come il blocco Query Loop. Quando la cache a pagina intera viene bypassata, questi blocchi eseguono il codice PHP durante la richiesta.
In terzo luogo, i flussi di lavoro dell’editor si basano fortemente sugli endpoint REST. Il salvataggio dei template, l’aggiornamento degli stili globali, l’anteprima delle modifiche e l’interazione con i pattern generano richieste non memorizzate nella cache. Questi percorsi dipendono direttamente dall’esecuzione di PHP, dalle prestazioni del database e dalla memorizzazione nella cache degli oggetti.
Infine, gli stili globali definiti in theme.jsoncentralizzano le decisioni di progettazione. Quando gli stili o le strutture dei template cambiano, il coordinamento della cache diventa più importante per garantire che i visitatori e gli editori vedano immediatamente l’output aggiornato.
Nessuno di questi cambiamenti richiede un tipo diverso di hosting. Tuttavia, rendono più evidenti alcune debolezze dell’infrastruttura, in particolare in scenari non memorizzati nella cache e con accesso effettuato.
Tenendo presente questo, il passo successivo è esaminare ciò che un ambiente di hosting ben configurato dovrebbe gestire in una configurazione basata su blocchi.
Considerazioni sull’hosting per i siti basati su blocchi
I temi a blocchi non introducono nuovi requisiti di hosting. Rendono invece più importante la corretta gestione di quelli esistenti.
Un ambiente ben configurato dovrebbe tenere conto sia dei percorsi con cache che di quelli senza cache, specialmente per gli editori e gli utenti che hanno effettuato l’accesso.
Caching coordinato tra i livelli
La cache a pagina intera rimane il livello di prestazioni più efficace per il traffico anonimo. Le pagine pubbliche dovrebbero essere memorizzate in cache in modo aggressivo, mentre le anteprime, le sessioni con utente registrato e gli endpoint specifici vengono automaticamente bypassati.
Anche la cache degli oggetti svolge un ruolo significativo. Memorizzando in memoria i risultati delle query ripetute e le strutture di dati calcolate, una cache degli oggetti riduce il carico sul database e migliora la reattività sia del frontend che del backend.
L’invalidazione della cache deve essere coordinata. Quando i contenuti, i template o gli stili globali vengono aggiornati, le pagine correlate dovrebbero aggiornarsi tempestivamente. Uno scarso coordinamento della cache può comportare layout obsoleti, stili incoerenti o un comportamento di anteprima confuso.
Un CDN integra questa configurazione memorizzando nella cache risorse statiche come immagini, font e script più vicine ai visitatori.
La memorizzazione nella cache non riguarda un singolo livello. Riguarda il modo in cui questi livelli lavorano insieme.
Capacità PHP e prestazioni di runtime
Quando la memorizzazione a pagina intera viene bypassata, WordPress esegue il PHP per risolvere le query, renderizzare i template ed elaborare i blocchi dinamici.
Questo rende importante la pianificazione della capacità PHP. L’ambiente dovrebbe fornire un numero sufficiente di thread PHP per gestire la concorrenza prevista senza accumulo di code. I limiti di memoria dovrebbero essere configurati per impedire lo swapping sotto carico.
OPcache dovrebbe essere abilitato e dimensionato correttamente in modo che il bytecode PHP non debba essere ricompilato ripetutamente. Durante le distribuzioni, OPcache dovrebbe aggiornarsi in modo che il codice aggiornato venga eseguito immediatamente.
Queste pratiche si applicano a tutti i siti WordPress, ma i flussi di lavoro basati su blocchi possono rendere i problemi di prestazioni più evidenti quando il rendering è dinamico.
Caching del database e degli oggetti
I template di blocco personalizzati nell’Editor del sito vengono memorizzati nel database. Il contenuto dei blocchi include metadati strutturati che WordPress analizza prima dell’output. Sebbene questa elaborazione sia efficiente, dipende comunque dalla reattività del database quando la cache viene bypassata.
Una cache degli oggetti persistente riduce le query ripetute e aiuta a stabilizzare le prestazioni sia per i visitatori del frontend che per gli editori che lavorano all’interno della dashboard.
Osservabilità e monitoraggio
Man mano che l’attività si sposta verso i percorsi di runtime, la visibilità diventa più importante. Gli host e i proprietari dei siti dovrebbero monitorare:
- Tassi di hit della cache
- Utilizzo dei worker PHP e lunghezza della coda
- Le prestazioni delle query del database
- I tempi di risposta delle API REST
- Tempo di risposta (Time to First Byte) per le richieste con e senza cache
I temi a blocchi non richiedono un’infrastruttura specializzata. Rendono però più facile individuare eventuali configurazioni non ottimali dell’infrastruttura.
Esecuzione di WordPress così come funziona oggi
I temi a blocchi non modificano ciò che WordPress richiede all’hosting. Rendono semplicemente più evidente quando tali requisiti non vengono soddisfatti.
Quando i template risiedono nel database, quando i blocchi dinamici vengono renderizzati in fase di esecuzione e quando gli editori si affidano a richieste REST non memorizzate nella cache, l’infrastruttura non è più invisibile. O supporta il flusso di lavoro senza intoppi oppure lo ostacola.
È qui che l’hosting gestito per WordPress fa la differenza.
In Kinsta, l’intero stack è costruito specificamente per il modo in cui WordPress opera oggi, dalla cache coordinata e dalla cache degli oggetti persistenti alle prestazioni PHP ottimizzate e alla distribuzione CDN globale su una potente infrastruttura cloud. L’obiettivo è garantire che sia i visitatori che gli editor godano di prestazioni costanti, anche quando il rendering avviene dinamicamente.
WordPress basato su blocchi non è più pesante. È più trasparente. E quando le fondamenta sono solide, quella trasparenza gioca a tuo favore.
Bud Kraus has been working with WordPress as an in-class and online instructor, site developer, and content creator since 2009. He has produced instructional videos and written many articles for WordPress businesses.
