{"id":1038,"date":"2026-08-05T09:57:08","date_gmt":"2026-08-05T07:57:08","guid":{"rendered":"https:\/\/aarkly.com\/?p=1038"},"modified":"2026-08-08T12:25:09","modified_gmt":"2026-08-08T10:25:09","slug":"wordpress-ttfb-optimization-reduce-time-to-first-byte","status":"publish","type":"post","link":"https:\/\/aarkly.com\/it\/wordpress-ttfb-optimization-reduce-time-to-first-byte\/","title":{"rendered":"WordPress TTFB Optimization: Get Time to First Byte Under 200ms"},"content":{"rendered":"<p class=\"wp-block-paragraph\">La maggior parte dei proprietari di siti \u00e8 ossessionata dai punteggi Lighthouse, dalla compressione delle immagini e dal numero di plugin. Ma c'\u00e8 un numero che rivela pi\u00f9 di qualsiasi altro sulla tua infrastruttura: <strong>Time to First Byte (TTFB)<\/strong>.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Il TTFB \u00e8 il tempo che intercorre tra la richiesta della pagina da parte del browser dell'utente e la ricezione del <em>primo byte<\/em> della risposta. \u00c8 la misura pi\u00f9 pura di quanto sia veloce il tuo server \u2014 prima che una singola immagine, script o foglio di stile venga scaricato.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Un TTFB lento significa che il tuo server stesso \u00e8 lento. Nessuna quantit\u00e0 di ottimizzazione delle immagini o plugin di caching pu\u00f2 nasconderlo. Questo \u00e8 il motivo per cui i Core Web Vitals di Google trattano il TTFB come la base del Largest Contentful Paint (LCP): un server lento ritarda tutto ci\u00f2 che segue.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">In questa guida, imparerai come appare un buon TTFB, come misurarlo e la sequenza esatta di otto passaggi per ridurre il TTFB del tuo WordPress sotto i 200ms \u2014 il target che garantiamo sull'infrastruttura Fortezza Digitale.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Qual \u00e8 un Buon TTFB per WordPress?<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Prima di ottimizzare, ti serve un benchmark. Ecco la scala che usa la maggior parte degli ingegneri delle prestazioni:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Sotto 100ms:<\/strong> Eccellente. Solo VPS dedicati o server dedicati con software ottimizzato raggiungono questo risultato.<\/li>\n\n\n\n<li><strong>100\u2013200ms:<\/strong> Molto buono. Un VPS ben configurato con una corretta cache. Questo \u00e8 l'obiettivo per siti seri.<\/li>\n\n\n\n<li><strong>200\u2013500ms:<\/strong> Accettabile ma lento. Tipico di hosting condiviso o di un VPS non ottimizzato. Gli utenti lo notano.<\/li>\n\n\n\n<li><strong>500ms\u20131s:<\/strong> Scarso. Il tuo server \u00e8 il collo di bottiglia. I visitatori iniziano ad abbandonare il sito.<\/li>\n\n\n\n<li><strong>Oltre 1s:<\/strong> Critico. Qualcosa \u00e8 fondamentalmente sbagliato nel tuo hosting o nella configurazione.<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">Google raccomanda un TTFB di <strong>sotto 800ms<\/strong>, ma questo \u00e8 un minimo, non un obiettivo. Per un sito che si posiziona e converte, mira a <strong>200ms o meno<\/strong>. Ogni 100ms di latenza del server ritarda direttamente il tuo LCP e spinge i tuoi Core Web Vitals pi\u00f9 lontano dal verde.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">La verit\u00e0 dolorosa: <strong>se il tuo TTFB supera i 300ms, il problema \u00e8 il tuo hosting, non il tuo sito.<\/strong> Puoi rifinire il frontend tutto il giorno, ma una risposta lenta del server limita tutto.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Come misurare correttamente il TTFB<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">La maggior parte delle persone misura il TTFB in modo errato. Il pannello di rete del browser include la risoluzione DNS, la configurazione della connessione e l'handshake TLS, che possono trarre in inganno.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Misura a livello di server<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">La misurazione pi\u00f9 pulita \u00e8 sul server stesso, bypassando la rete:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>curl -o \/dev\/null -s -w \"TTFB: %{time_starttransfer}s\\n\" https:\/\/yourdomain.com<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Questo isola il tempo di risposta grezzo del server. Eseguilo 5 volte e prendi la mediana, non la media (una singola richiesta a freddo gonfia il numero).<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Misura da pi\u00f9 posizioni<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Una singola misurazione dal tuo ufficio ti dice poco. Usa:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>WebPageTest<\/strong> con una posizione lontana dal tuo server per testare la latenza globale.<\/li>\n\n\n\n<li><strong>GTmetrix<\/strong> vista a cascata per vedere il TTFB suddiviso per DNS, connessione e tempo di attesa.<\/li>\n\n\n\n<li><strong>Google PageSpeed Insights<\/strong> \u2014 guarda il campo &#8220;server response time&#8221; nella diagnostica.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">Separa i due componenti del TTFB<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Un TTFB misurato \u00e8 in realt\u00e0 due cose: <strong>RTT di rete<\/strong> (quanto distante \u00e8 il tuo utente dal tuo server) e <strong>tempo di elaborazione del server<\/strong> (quanto tempo impiega il server per generare la risposta).<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Il comando curl sopra ti mostra il <em>totale<\/em>. Per isolare l'elaborazione del server, confrontala con un semplice test di latenza (<code>ping<\/code> o <code>curl<\/code> a un file statico). Se un file statico \u00e8 veloce (20ms) ma la tua homepage \u00e8 400ms, il problema \u00e8 <strong>elaborazione lato server<\/strong>, non la rete.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Questa distinzione \u00e8 importante: una CDN risolve la latenza di rete, ma solo l'ottimizzazione del server risolve l'elaborazione lenta. La maggior parte dei problemi TTFB di WordPress sono lato server \u2014 ed \u00e8 redditizio risolverli perch\u00e9 ne hai il controllo.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">La Sequenza in 8 Passi per Ridurre il TTFB di WordPress<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Affrontali in ordine. Ogni passaggio affronta un diverso livello dello stack e ciascuno si accumula sul precedente.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Passo 1: Sistemare l'Hosting Stesso<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Il TTFB inizia dalle fondamenta. Se sei su hosting condiviso, questo \u00e8 il tuo tetto, punto e basta.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">L'hosting condiviso limita la CPU, limita l'uso degli inode e fa overselling delle risorse del server. Il picco di traffico del tuo vicino &#8220;veloce&#8221; rallenta il tuo sito. Nessuna ottimizzazione \u2014 caching, CDN o altro \u2014 compensa pienamente un host che ti limita.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Passa a <strong>VPS con CPU e RAM garantite<\/strong>. Solo questo spesso fa scendere il TTFB da 600ms a 150ms perch\u00e9 smetti di competere per le risorse. Scegli un provider con storage NVMe veloce e data center vicini al tuo pubblico.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Non hai bisogno del piano pi\u00f9 costoso. Hai bisogno <strong>risorse garantite<\/strong>. Un VPS modesto ma isolato batte ogni volta un piano condiviso nominalmente pi\u00f9 veloce.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Passaggio 2: Ottimizza PHP-FPM<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">PHP-FPM \u00e8 il process manager che esegue il tuo codice PHP. La sua configurazione predefinita \u00e8 progettata per un uso ridotto della memoria, non per la velocit\u00e0 \u2014 e limita i siti WordPress ad alto traffico.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Apri il tuo <code>php-fpm.conf<\/code> (o configurazione del pool) e regola:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>pm.max_children = 30\npm.start_servers = 5\npm.min_spare_servers = 5\npm.max_spare_servers = 10<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">I numeri esatti dipendono dalla RAM del tuo server. Una regola approssimativa: ogni worker PHP utilizza circa 40\u201380MB. Un VPS da 4GB esegue comodamente 30\u201340 worker.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Una sotto-provisioning di PHP-FPM significa che le richieste si accodano in attesa di un worker libero. Questo aumenta direttamente il TTFB. Regolalo in modo da non aspettare mai un worker in condizioni di traffico normale.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Passo 3: Usa la Versione PHP Corretta<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Questa \u00e8 la vittoria pi\u00f9 economica sul TTFB disponibile. Ogni versione principale di PHP \u00e8 pi\u00f9 veloce della precedente.<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>PHP 7.4 ha raggiunto la fine del ciclo di vita ed \u00e8 drammaticamente pi\u00f9 lento rispetto alle versioni moderne.<\/li>\n\n\n\n<li>PHP 8.1 \u00e8 circa <strong>2 volte pi\u00f9 veloce<\/strong> rispetto a PHP 7.4 per i tipici carichi di lavoro WordPress.<\/li>\n\n\n\n<li>PHP 8.2 e 8.3 continuano i guadagni con il supporto JIT e i miglioramenti di opcache.<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">Se sei ancora su PHP 7.x, l'aggiornamento a 8.3+ \u00e8 un semplice menu a tendina nella maggior parte dei pannelli di controllo e pu\u00f2 ridurre il TTFB del 30\u201350% senza modifiche al codice. Verifica prima che i tuoi plugin e il tema supportino la versione, ma quasi tutti i plugin moderni lo fanno.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Abilita l'estensione OpCache se non \u00e8 gi\u00e0 attiva. OpCache memorizza nella cache il bytecode PHP compilato in memoria, eliminando la fase di parsing e compilazione a ogni richiesta \u2014 una significativa riduzione lato server.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Passaggio 4: Ottimizza il database<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Il database di WordPress \u00e8 un frequente killer nascosto del TTFB. Ogni caricamento di pagina esegue decine di query, e un database non ottimizzato rende ciascuna pi\u00f9 lenta e ripete il lavoro.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Inizia con <strong>il caching dei risultati delle query<\/strong> (object caching). Come spiegato nella nostra guida su Redis, installare Redis come backend dell'object cache riduce drasticamente il numero di query al database ripetute per richiesta. \u00c8 uno dei cambiamenti lato server ad alto impatto disponibili.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Poi pulisci il database:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Rimuovi transient, revisioni e spam dalle tabelle.<\/li>\n\n\n\n<li>Aggiungi indici appropriati alle <code>wp_options<\/code> e <code>wp_postmeta<\/code> tabelle \u2014 queste sono le tabelle che ricevono il maggior numero di query in WordPress.<\/li>\n\n\n\n<li>Considera <strong>MariaDB o MySQL 8<\/strong> rispetto alle versioni MySQL pi\u00f9 vecchie per un migliore ottimizzatore di query e prestazioni InnoDB.<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">Un database ottimizzato dovrebbe rispondere alle query di una pagina in meno di 30ms. Se richiede 200ms, il database \u00e8 il tuo collo di bottiglia.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Passaggio 5: Aggiungi la cache delle pagine a livello di server.<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">La cache delle pagine serve una copia HTML statica di ogni pagina invece di eseguire PHP a ogni richiesta. Questa \u00e8 la pi\u00f9 grande riduzione del TTFB disponibile.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Ci sono due livelli:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Cache di pagina tramite plugin<\/strong> (ad esempio, WP Super Cache, plugin di cache) funziona, ma avvia comunque WordPress e PHP per servire il file in cache \u2014 il suo TTFB \u00e8 solo marginalmente migliore rispetto a una pagina dinamica.<\/li>\n\n\n\n<li><strong>Cache a livello di server<\/strong> (cache FastCGI di Nginx, Varnish, cache di pagina Redis) serve l'HTML in cache direttamente dalla memoria. <em>prima<\/em> PHP gira. Per i visitatori anonimi questo pu\u00f2 portare il TTFB sotto 50ms.<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">La differenza \u00e8 enorme. La cache a livello server intercetta la richiesta al server web, mai toccando PHP. Ecco perch\u00e9 la nostra configurazione Fortezza usa un livello di cache nativo piuttosto che affidarsi solo ai plugin.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Passaggio 6: Abilita compressione e HTTP\/2<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Due ottimizzazioni a livello di protocollo riducono i byte trasferiti e l'overhead di connessione:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Gzip o Brotli<\/strong> La compressione riduce HTML, CSS e JS del 60-80% prima che vengano trasmessi. Brotli generalmente comprime meglio di gzip con le stesse impostazioni.<\/li>\n\n\n\n<li><strong>HTTP\/2<\/strong> multiplexa pi\u00f9 richieste su una singola connessione, eliminando il blocco head-of-line di HTTP\/1.1 e riducendo i round trip per le risorse della pagina.<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">Entrambe sono configurate sotto il cofano a livello di web server o CDN. Non riducono direttamente l'elaborazione <em>del server<\/em> tempo, ma riducono millisecondi reali dalla risposta totale \u2014 e sono gratuiti.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Passaggio 7: Aggiungi una CDN con caching perimetrale<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Una Content Delivery Network (CDN) replica i tuoi asset statici \u2014 e, con il caching perimetrale, la tua pagina intera \u2014 in data center pi\u00f9 vicini ai tuoi visitatori.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Questo affronta <strong>RTT di rete<\/strong> componente del TTFB. Un utente a Milano che raggiunge un server a Francoforte o Amsterdam ha una latenza di andata e ritorno di 30\u201360ms. Con un nodo edge CDN a Milano, quella scende a meno di 10ms.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Per la cache a pagina intera, la CDN memorizza l'output HTML al bordo e lo serve ai visitatori anonimi senza mai contattare il tuo server di origine. Combinato con la cache a livello server, questo ti d\u00e0 un TTFB sub-50ms per la stragrande maggioranza delle richieste.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Poich\u00e9 serviamo clienti europei con requisiti GDPR, usiamo una CDN con posizioni edge solo nell'UE e garantiamo che nessun dato lasci l'UE.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Passaggio 8: Monitora e mantieni<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">L'ottimizzazione non \u00e8 un compito una tantum. Il TTFB si degrada silenziosamente mentre il tuo sito cresce, i plugin si accumulano e i modelli di traffico cambiano.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Imposta un ciclo di monitoraggio:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Settimanalmente:<\/strong> Esegui la misurazione curl di cui sopra e registra la mediana.<\/li>\n\n\n\n<li><strong>Mensilmente:<\/strong> Controlla i Core Web Vitals in Search Console e PageSpeed Insights.<\/li>\n\n\n\n<li><strong>Ad ogni modifica:<\/strong> Ripeti il test del TTFB ogni volta che aggiungi un plugin pesante, cambi tema o modifichi la configurazione del server.<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">Fai attenzione alla crescita lenta. Un TTFB che sale da 150ms a 300ms nell'arco di tre mesi segnala una regressione di un plugin o un server sottodimensionato che necessita di scaling.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Una diagnosi reale: da 900ms a 160ms<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Per rendere il tutto concreto, ecco l'esatta sequenza di riscontri di un tipico sito WordPress lento \u2014 lo stesso schema che vediamo su quasi ogni sito che arriva su Fortezza con \u201cil mio sito \u00e8 lento\u201d.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Punto di partenza:<\/strong> TTFB di 900ms misurato tramite curl, caricamento pagina di 4,2 secondi, LCP di 5,4s. Il proprietario aveva gi\u00e0 provato quattro plugin di ottimizzazione immagini e tre plugin cache senza alcun miglioramento reale.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Diagnosi (5 minuti):<\/strong><\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><code>curl -w \"TTFB: %{time_starttransfer}s\\n\"<\/code> \u2192 900ms. Gi\u00e0 tutto il problema.<\/li>\n\n\n\n<li>Servire un file statico \u2192 40ms. Quindi la rete era a posto; l'elaborazione del server era 860ms.<\/li>\n\n\n\n<li>Versione PHP controllata \u2192 ancora in esecuzione PHP 7.4, fine del ciclo di vita.<\/li>\n\n\n\n<li><code>pm.max_children<\/code> \u2192 impostato su 10 worker conservativi, tutti saturati durante i picchi di traffico.<\/li>\n\n\n\n<li>Cache oggetti Redis \u2192 non installata. Ogni richiesta ripeteva le stesse ~40 query al database.<\/li>\n\n\n\n<li>Nessuna cache di pagina a livello di server. Ogni caricamento di pagina anonima eseguiva PHP + MySQL completi.<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Correzioni applicate in ordine:<\/strong><\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Aggiornato PHP 7.4 \u2192 PHP 8.3: TTFB sceso da 900ms a ~500ms. I miglioramenti del compilatore e di OpCache da soli hanno fatto la maggior parte del lavoro.<\/li>\n\n\n\n<li>Ottimizzato PHP-FPM <code>pm.max_children<\/code> da 10 a 32 e ho regolato i server di riserva: il TTFB \u00e8 sceso a ~350ms. Non pi\u00f9 code su lavoratori liberi.<\/li>\n\n\n\n<li>Installato Redis come backend per la cache degli oggetti: il TTFB \u00e8 sceso a ~260ms. Le query ripetute al database sono cessate.<\/li>\n\n\n\n<li>Cache FastCGI Nginx abilitata per i visitatori anonimi: TTFB sceso a ~120ms, perch\u00e9 PHP non girava pi\u00f9 affatto per le pagine in cache.<\/li>\n\n\n\n<li>Aggiunto un CDN con edge in UE per la latenza geografica residua: TTFB misurato da una citt\u00e0 europea remota sceso a ~90ms.<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Per favore, fornisci le stringhe da tradurre.<\/strong> {\n  \"text\": \"TTFB di 90\u2013120ms (a seconda della posizione), LCP inferiore a 2.5s, Core Web Vitals completamente verdi. Tempo totale investito: meno di un'ora, interamente lato server.\"\n}<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">La lezione \u00e8 sempre la stessa: <strong>il sito non era mai stato rotto \u2014 era lo stack.<\/strong> Una volta che al server sono state date risorse reali, un PHP moderno, una query cache e un layer nativo di page-cache, il \"sito lento\" \u00e8 sparito senza toccare una singola riga di frontend.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Una Configurazione di Riferimento per la Cache FastCGI Nginx<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Se usi Nginx come web server e vuoi il page caching a livello di server, una cache FastCGI \u00e8 una delle cose ad alto impatto che puoi abilitare. Ecco un riferimento minimo funzionante:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># Nel contesto http\nfastcgi_cache_path \/var\/cache\/nginx levels=1:2 keys_zone=WORDPRESS:100m inactive=60m max_size=1g;\nfastcgi_cache_key \"$scheme$request_method$host$request_uri\";\n\n# Nel blocco server \/ location che fa da proxy a PHP\nset $skip_cache 0;\nif ($request_uri ~* \"\/wp-admin\/|\/wp-json\/|\/xmlrpc.php|wp-.*.php\") { set $skip_cache 1; }\nif ($request_method = POST) { set $skip_cache 1; }\nif ($query_string != \"\") { set $skip_cache 1; }\n\nlocation ~ \\.php$ {\n    include fastcgi_params;\n    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;\n    fastcgi_pass unix:\/var\/run\/php\/php8.3-fpm.sock;\n    fastcgi_cache WORDPRESS;\n    fastcgi_cache_valid 200 60m;\n    add_header X-Cache $upstream_cache_status;\n    fastcgi_cache_bypass $skip_cache;\n    fastcgi_no_cache $skip_cache;\n}<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">{\"The\": \"Il\"} <code>X-Cache<\/code> ti permette di confermare che la cache funziona: <code>HIT<\/code> appare sulle risposte in cache, <code>MISS<\/code> sulla prima richiesta. Le regole <code>$skip_cache<\/code> mantengono dinamici l'area admin, l'API REST e i flussi con login, cos\u00ec non servi mai contenuti stantii agli utenti autenticati.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Nota che WordPress imposta gli header <code>Cache-Control<\/code> e potresti aver bisogno di una piccola modifica per la piena compatibilit\u00e0. Per il comportamento del team e le sessioni con login, i casi limite contano \u2014 ecco perch\u00e9 un layer di caching ben testato e pre-costruito (come quello di una configurazione managed) batte il fai-da-te su un sito trafficato.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Cosa NON fare: errori comuni relativi al TTFB<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Diverse ottimizzazioni sembrano utili ma fanno perdere tempo o peggiorano le cose:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Nascondere il TTFB con uno spinner di caricamento o uno skeleton.<\/strong> Questo non risolve il problema del server lento; maschera solo il ritardo all'utente. Google continua a misurare il tempo di risposta reale.<\/li>\n\n\n\n<li><strong>Risolvere il TTFB con il lazy loading front-end.<\/strong> Il lazy loading posticipa immagini e script \u2014 non velocizza la risposta iniziale del server. Aiuta l'LCP ma non il TTFB.<\/li>\n\n\n\n<li><strong>Sospetto sui plugin &#8220;cache everything&#8221; che entrano in conflitto.<\/strong> Troppi livelli di cache che si contrastano a vicenda creano pagine obsolete e doppio lavoro. Usa uno stack coerente, non cinque plugin sovrapposti.<\/li>\n\n\n\n<li><strong>Ottimizzare prima di misurare.<\/strong> Se non puoi indicare il tuo TTFB mediano attuale, stai ottimizzando alla cieca. Misura prima.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">Il punto fondamentale<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Il TTFB \u00e8 la metrica delle prestazioni pi\u00f9 onesta del web, e la strada pi\u00f9 rapida per un sito veloce \u00e8 risolverlo.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Ecco di nuovo la sequenza, in una riga: <strong>{\"translation\":\"esci dall'hosting condiviso \u2192 ottimizza PHP-FPM \u2192 aggiorna PHP \u2192 metti in cache le query con Redis \u2192 aggiungi la cache delle pagine a livello di server \u2192 attiva la compressione e HTTP\/2 \u2192 metti una CDN davanti \u2192 monitora settimanalmente.\"}<\/strong><\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Fai tutti gli otto e atterrerai <strong>sotto i 200ms<\/strong>, spesso sotto i 100ms. Non farne nessuno e ogni altro sforzo di performance che fai \u00e8 limitato da un server lento.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Questo \u00e8 esattamente lo stack che usiamo su <strong>Fortezza Digitale<\/strong>: infrastruttura VPS dedicata, caching nativo, TTFB sotto 200ms garantito e monitoraggio continuo cos\u00ec le prestazioni non decadono mai silenziosamente.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Un TTFB lento non \u00e8 un mistero. \u00c8 una checklist. Ora ce l'hai.<\/p>","protected":false},"excerpt":{"rendered":"<p>Come portare il Time to First Byte di WordPress sotto i 200ms: hosting, PHP-FPM, Redis, page caching lato server e CDN. Una checklist operativa completa.<\/p>","protected":false},"author":2,"featured_media":1162,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"ai_primary_source":"0","visibility_scope":"both","ai_summary":"","ai_intent":"","ai_related_resources":"","ai_priority":5,"ai_entity_type":"","ai_is_based_on":"","ai_citations":"","ai_mentions":"","ai_speakable_selector":"","ai_chunk_hints":"","footnotes":""},"categories":[3,6],"tags":[34,33,30],"ai_visibility":[22],"class_list":["post-1038","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-performance-hosting","category-wordpress","tag-caching","tag-site-speed","tag-wordpress-performance"],"blocksy_meta":{"styles_descriptor":{"styles":{"desktop":"","tablet":"","mobile":""},"google_fonts":[],"version":7}},"_links":{"self":[{"href":"https:\/\/aarkly.com\/it\/wp-json\/wp\/v2\/posts\/1038","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/aarkly.com\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/aarkly.com\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/aarkly.com\/it\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/aarkly.com\/it\/wp-json\/wp\/v2\/comments?post=1038"}],"version-history":[{"count":2,"href":"https:\/\/aarkly.com\/it\/wp-json\/wp\/v2\/posts\/1038\/revisions"}],"predecessor-version":[{"id":1297,"href":"https:\/\/aarkly.com\/it\/wp-json\/wp\/v2\/posts\/1038\/revisions\/1297"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/aarkly.com\/it\/wp-json\/wp\/v2\/media\/1162"}],"wp:attachment":[{"href":"https:\/\/aarkly.com\/it\/wp-json\/wp\/v2\/media?parent=1038"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/aarkly.com\/it\/wp-json\/wp\/v2\/categories?post=1038"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/aarkly.com\/it\/wp-json\/wp\/v2\/tags?post=1038"},{"taxonomy":"ai_visibility","embeddable":true,"href":"https:\/\/aarkly.com\/it\/wp-json\/wp\/v2\/ai_visibility?post=1038"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}