{"id":83533,"date":"2026-03-18T09:34:39","date_gmt":"2026-03-18T08:34:39","guid":{"rendered":"https:\/\/kinsta.com\/it\/?p=83533&preview=true&preview_id=83533"},"modified":"2026-03-18T20:05:34","modified_gmt":"2026-03-18T19:05:34","slug":"temi-blocchi-hosting-wordpress","status":"publish","type":"post","link":"https:\/\/kinsta.com\/it\/blog\/temi-blocchi-hosting-wordpress\/","title":{"rendered":"In che modo i moderni temi a blocchi stanno cambiando l’hosting WordPress"},"content":{"rendered":"

L’hosting WordPress gestito \u00e8 pensato per garantire il corretto funzionamento di WordPress. Offre un ambiente ottimizzato in base al comportamento di WordPress sotto carico, alla gestione della cache<\/a> e all’esecuzione del PHP.<\/p>\n

I temi a blocchi<\/a> non modificano gli aspetti fondamentali dell’hosting, ma cambiano il punto in cui si verificano i colli di bottiglia nelle prestazioni. \u00c8 qui che il ruolo del provider di hosting diventa pi\u00f9 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<\/a>, le anteprime e le sessioni di accesso.<\/p>\n

Per capire il perch\u00e9, \u00e8 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.<\/p>\n

<\/div><\/kinsta-auto-toc>\n

Cosa succede quando viene richiesta una pagina WordPress<\/h2>\n

Esaminiamo una semplice richiesta che restituisce una risposta 200 OK<\/a>.<\/p>\n

1: Il browser invia la richiesta<\/h3>\n

Un utente digita un URL o clicca su un link. Se l’indirizzo IP del server non \u00e8 gi\u00e0 memorizzato nella cache, il browser esegue una ricerca DNS<\/a>. Quindi apre una connessione TCP e negozia una sessione TLS<\/a> sicura.<\/p>\n

Prima che WordPress entri in gioco, la richiesta passa attraverso il server web e qualsiasi livello configurato, come firewall o proxy inversi.<\/p>\n

2: Controllo della cache<\/h3>\n

Il server verifica se esiste una versione valida della pagina richiesta memorizzata nella cache.<\/p>\n

Se \u00e8 disponibile una cache HTML a pagina intera<\/a> e questa \u00e8 valida, WordPress non viene eseguito. La risposta memorizzata nella cache viene restituita immediatamente.<\/p>\n

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.<\/p>\n

3: Avvio di WordPress<\/h3>\n

WordPress carica i suoi file principali, i plugin attivi e il tema attivo. Inizializza gli hook e si prepara a risolvere la richiesta.<\/p>\n

In questa fase, WordPress non genera ancora alcun output. Determina quale contenuto viene richiesto.<\/p>\n

4: Risoluzione della query principale<\/h3>\n

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.<\/p>\n

Solo dopo questo processo ha inizio la selezione del template.<\/p>\n

5: Risoluzione del template<\/h3>\n

\u00c8 qui che i temi a blocchi e quelli classici iniziano a differenziarsi strutturalmente.<\/p>\n

Temi classici<\/h4>\n

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.<\/p>\n

Temi a blocchi<\/h4>\n

WordPress verifica se nel database esiste un template di blocco personalizzato. Se esiste, ha la priorit\u00e0. In caso contrario, WordPress ricorre al file del template di blocco incluso nel tema, come single.html o index.html.<\/p>\n

Il template selezionato viene quindi elaborato attraverso il sistema di rendering dei blocchi.<\/p>\n

6: Assemblaggio del layout<\/h3>\n

Temi classici<\/h4>\n

Il layout viene costruito tramite template PHP. Questi template combinano markup, logica e chiamate di funzione per produrre un output HTML.<\/p>\n

Temi a blocchi<\/h4>\n

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.<\/p>\n

7: Struttura dei contenuti<\/h3>\n

Temi classici<\/h4>\n

Il contenuto dei post viene memorizzato principalmente come HTML nel database. Durante l’output, WordPress applica filtri, shortcode e altre elaborazioni prima del rendering.<\/p>\n

Temi a blocchi<\/h4>\n

Il contenuto dei blocchi viene memorizzato come HTML con metadati dei blocchi incorporati, ad esempio:<\/p>\n

<!-- wp:image {\"id\":123} -->\n\n<img src=\"logo.png\">\n\n<!-- \/wp:image --><\/code><\/pre>\n
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.<\/p>\n
8: Rendering dinamico<\/h3>\n
Il rendering dinamico \u00e8 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.<\/p>\n
Nelle architetture basate su blocchi, il comportamento dinamico \u00e8 formalizzato attraverso blocchi dinamici. Ad esempio, un blocco Query Loop genera il proprio markup durante la richiesta utilizzando PHP anzich\u00e9 memorizzare HTML statico nel database.<\/p>\n
Quando la cache a pagina intera viene bypassata, questo flusso di lavoro di rendering avviene ad ogni richiesta.<\/p>\n
9: Stile<\/h3>\n
Per i temi classici, lo styling viene in genere fornito tramite file CSS statici<\/a> messi in coda dal tema.<\/p>\n
Per i temi a blocchi, gli stili globali definiti in theme.json<\/code> e i metadati dei blocchi consentono a WordPress di generare automaticamente CSS coerenti. Ci\u00f2 riduce la necessit\u00e0 di fogli di stile di grandi dimensioni creati manualmente e centralizza la configurazione del design.<\/p>\n
10: Output finale<\/h3>\n
Dopo l’elaborazione di template, contenuti, blocchi e stili, WordPress produce la risposta HTML finale.<\/p>\n
Il server invia il payload al browser. Se configurato, la risposta pu\u00f2 quindi essere memorizzata nella cache per richieste future.<\/p>\n
Dove i temi a blocchi spostano il carico<\/h2>\n
Il ciclo di vita delle richieste che abbiamo appena esaminato si applica sia ai temi classici che a quelli a blocchi<\/a>. WordPress continua a risolvere le query, selezionare i template, eseguire il PHP e restituire l’HTML.
\nCi\u00f2 che cambia con i temi a blocchi non \u00e8 la base, ma dove avviene il lavoro e quando non pu\u00f2 essere saltato.<\/p>\n
In primo luogo, i template<\/a> possono risiedere nel database. Quando un utente modifica un template nell\u2019Editor del sito, WordPress memorizza quella versione e le d\u00e0 la priorit\u00e0 rispetto al file nella directory del tema. Ci\u00f2 aggiunge flessibilit\u00e0, ma significa anche che le distribuzioni e l\u2019invalidazione della cache devono tenere conto dei template memorizzati nel database.<\/p>\n
In secondo luogo, i blocchi dinamici<\/a> rendono pi\u00f9 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.<\/p>\n
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.
\nInfine, gli stili globali definiti in theme.json<\/a><\/code>centralizzano le decisioni di progettazione. Quando gli stili o le strutture dei template cambiano, il coordinamento della cache diventa pi\u00f9 importante per garantire che i visitatori e gli editori vedano immediatamente l’output aggiornato.<\/p>\n
Nessuno di questi cambiamenti richiede un tipo diverso di hosting. Tuttavia, rendono pi\u00f9 evidenti alcune debolezze dell’infrastruttura, in particolare in scenari non memorizzati nella cache e con accesso effettuato.
\nTenendo presente questo, il passo successivo \u00e8 esaminare ci\u00f2 che un ambiente di hosting ben configurato dovrebbe gestire in una configurazione basata su blocchi.<\/p>\n
Considerazioni sull’hosting per i siti basati su blocchi<\/h2>\n
I temi a blocchi non introducono nuovi requisiti di hosting. Rendono invece pi\u00f9 importante la corretta gestione di quelli esistenti.<\/p>\n
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.<\/p>\n
Caching coordinato tra i livelli<\/h3>\n
La cache a pagina intera<\/a> rimane il livello di prestazioni pi\u00f9 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.
\nAnche la cache degli oggetti<\/a> 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\u00e0 sia del frontend che del backend.<\/p>\n
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\u00f2 comportare layout obsoleti, stili incoerenti o un comportamento di anteprima confuso.<\/p>\n
Un CDN integra questa configurazione memorizzando nella cache risorse statiche come immagini, font e script pi\u00f9 vicine ai visitatori.<\/p>\n
La memorizzazione nella cache<\/a> non riguarda un singolo livello. Riguarda il modo in cui questi livelli lavorano insieme.<\/p>\n
Capacit\u00e0 PHP e prestazioni di runtime<\/h3>\n
Quando la memorizzazione a pagina intera viene bypassata, WordPress esegue il PHP per risolvere le query, renderizzare i template ed elaborare i blocchi dinamici.
\nQuesto rende importante la pianificazione della capacit\u00e0 PHP. L’ambiente dovrebbe fornire un numero sufficiente di thread PHP<\/a> per gestire la concorrenza prevista senza accumulo di code. I limiti di memoria<\/a> dovrebbero essere configurati per impedire lo swapping sotto carico.<\/p>\n
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.<\/p>\n
Queste pratiche si applicano a tutti i siti WordPress, ma i flussi di lavoro basati su blocchi possono rendere i problemi di prestazioni pi\u00f9 evidenti quando il rendering \u00e8 dinamico.<\/p>\n
Caching del database e degli oggetti<\/h3>\n
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\u00e0 del database quando la cache viene bypassata.<\/p>\n
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.<\/p>\n
Osservabilit\u00e0 e monitoraggio<\/h3>\n
Man mano che l’attivit\u00e0 si sposta verso i percorsi di runtime, la visibilit\u00e0 diventa pi\u00f9 importante. Gli host e i proprietari dei siti dovrebbero monitorare:<\/p>\n