Hosting e prestazioni
Come rendiamo WordPress veloce: LiteSpeed Enterprise, LSCache e Redis per singolo sito
La richiesta WordPress più veloce è quella che non viene mai eseguita: ecco come il nostro stack risponde alla maggior parte delle visite dalla cache prima che vengano avviati PHP o MySQL, e cosa questo significhi per i Core Web Vitals.
La richiesta più veloce è quella che non viene mai eseguita
Una richiesta WordPress standard è costosa. Il server web passa il compito a PHP, che avvia WordPress, esegue i plugin, interroga MySQL decine di volte, assembla l'HTML e solo allora invia i byte indietro. Su un sito trafficato quell'intera sequenza si ripete per ogni visitatore, ed è lì che se ne va quasi tutto il tuo tempo al primo byte.
La nostra soluzione consiste nel fare in modo che, per la maggior parte delle visite, tutto ciò non avvenga affatto. Su tutti i siti che ospitiamo – oltre 100.000 siti PBN e i principali siti WordPress gestiti – la grande maggioranza delle visualizzazioni di pagine front-end viene servita come pagina intera pre-renderizzata direttamente dalla cache, senza invocare PHP o toccare il database. Il resto di questo post spiega come si integrano i livelli che rendono tutto ciò possibile e dove ciascuno di essi guadagna il proprio posto.
La premessa fondamentale è che non si tratta di cache in competizione tra cui scegliere. La cache a pagina intera, la cache a oggetti e l'edge della CDN gestiscono ciascuna una diversa classe di richieste, e il vero valore risiede nel modo in cui si passano il testimone a vicenda.
LiteSpeed Enterprise + LSCache: il livello di intera pagina
Ogni sito funziona su LiteSpeed Enterprise con LSCache a livello di server. Quando una risposta front-end è memorizzabile nella cache, il server web la contrassegna con intestazioni di controllo della cache e tag di LiteSpeed, e LiteSpeed serve la pagina completa direttamente alla richiesta successiva, senza avviare alcun processo PHP né eseguire alcuna query MySQL. Questa è la leva principale per il TTFB di WordPress, poiché rimuove l'intero avvio dell'applicazione dal percorso critico.
Poiché LSCache risiede all'interno del server web anziché in un plugin PHP, inizia a funzionare prima nel ciclo di vita della richiesta e memorizza le pagine in un formato che il server può rilasciare all'istante. Un crawler della cache mantiene le pagine più popolari sempre calde, in modo che il primo visitatore dopo una pulizia non sia quello che deve farsi carico di rigenerare la pagina. Il risultato è un TTFB notevolmente inferiore e più costante rispetto a una cache basata solo su plugin applicata a uno stack generico, dove la cache si trova comunque dietro a PHP.
Il nostro plug-in di cache di livello repo viene fornito preinstallato e si aggiorna automaticamente su ogni sito, collegando WordPress a LSCache in modo corretto fin dal primo utilizzo. Su un'origine non LiteSpeed, semplicemente non emette intestazioni per l'intera pagina e si fa da parte, mentre la cache degli oggetti e le regole di esclusione continuano a fare il loro lavoro, in modo che un sito migrato non venga mai lasciato in uno stato di configurazione parziale e non funzionante.
Veloci senza servire contenuti obsoleti: ESI e auto-purge intelligente
La memorizzazione aggressiva nella cache dell'intera pagina presenta due modalità di errore classiche: servire a un utente loggato la pagina di qualcun altro e servire a chiunque una pagina che avrebbe dovuto cambiare. Entrambi i problemi vengono risolti a livello di cache anziché riducendo l'uso della cache.
ESI (Edge Side Includes) ci consente di memorizzare la pagina in cache lasciando spazi aperti per le parti che devono rimanere dinamiche. Su un negozio WooCommerce il catalogo, le pagine dei prodotti e delle categorie vengono servite come cache a pagina intera per il TTFB più rapido possibile, mentre ESI esegue il rendering del frammento del carrello, dei totali del mini-carrello e dello stato dell'account per ciascuna richiesta. Carrello, checkout, il mio account e qualsiasi pagina di nonce o di sessione vengono esclusi per impostazione predefinita. Gli acquirenti vedono sempre il proprio carrello e un checkout funzionante, mentre tutti gli altri continuano a ricevere la vetrina dalla cache.
La freschezza è gestita da un sistema intelligente di auto-pulizia. Gli hook di pulizia si attivano automaticamente quando contenuti, prodotti, prezzi o ordini cambiano, in modo che le relative pagine memorizzate nella cache si aggiornino immediatamente anziché a tempo, ed è anche possibile effettuare la pulizia su richiesta dalla dashboard o dall'interno di WordPress. La pulizia basata su tag significa che la modifica di un singolo articolo cancella quell'articolo e i suoi archivi — non l'intera cache — in modo che una singola modifica non provochi un riavvio a freddo dell'intero sito.
Object cache Redis per singolo sito: per ciò che non può essere una pagina intera
Non tutte le richieste possono essere una pagina statica completa. Le sessioni con accesso effettuato, l'area amministrativa di WordPress, i carrelli di WooCommerce, la ricerca e i frammenti dinamici lasciati liberi da ESI devono tutti eseguire PHP. Per questi, l'obiettivo passa da "saltare l'applicazione" a "saltare il database".
Ogni sito ha la sua object cache Redis dedicata. WordPress memorizza nella cache i risultati delle letture ripetute del database — opzioni, transient, ricerche di post e termini, dati di prodotti e sessioni di WooCommerce — in memoria, in modo che la stessa query non venga eseguita su MySQL a ogni richiesta. L'effetto è più evidente proprio dove la cache a pagina intera non può aiutare: dashboard più veloci, carrelli più rapidi e un carico del database notevolmente inferiore in caso di traffico.
La cache degli oggetti è per singolo sito e non condivisa, il che è importante sia per le prestazioni che per l'isolamento. Combinata con la limitazione del database per singolo sito, le query pesanti o scritte male di un sito non possono affamare il database per i siti vicini. Puoi leggere di più su come l'intera configurazione multilivello si integra nella nostra pagina delle funzioni di caching e sui confini tra i tenant nella sezione sull'isolamento.
L'edge e il trasporto sottostante
La cache che risiede sull'origine deve comunque attraversare la rete. Davanti al server si trova l'edge della CDN, quindi gli asset statici e le pagine memorizzabili nella cache vengono serviti da un punto di presenza vicino al visitatore, e l'origine rimane silenziosa anche sotto carico. Per la nostra linea di hosting Footprint-Free lo stesso edge è un pool multi-CDN distribuito su diversi provider, che persegue un obiettivo di footprint oltre a uno di performance; su WordPress mainstream è semplicemente un livello veloce e ben strutturato che mantiene le origini inattive.
Sotto il cofano, le basi non vengono trascurate. I siti funzionano su storage NVMe con HTTP/3, in modo che i byte inviati dalla cache arrivino tramite un trasporto moderno e multiplexato, con uno storage veloce a supporto di ogni mancata corrispondenza della cache. Nessuno di questi livelli è un componente aggiuntivo: LiteSpeed, LSCache, Redis per singolo sito, NVMe e HTTP/3 rappresentano la base di ogni piano, non un livello superiore a pagamento.
Cosa muove realmente i Core Web Vitals
Vale la pena essere precisi, perché l'hosting viene spesso venduto promettendo miracoli sui Core Web Vitals. Il TTFB è la parte dell'equazione di competenza del server, e lo stack di caching sovrastante è ciò che lo riduce al minimo: una pagina intera memorizzata nella cache e servita tramite HTTP/3 dall'edge raggiunge il valore di TTFB più basso possibile. Poiché il TTFB rappresenta l'inizio del Largest Contentful Paint, un'origine veloce garantisce a ogni metrica successiva un vantaggio iniziale che altrimenti non potrebbe avere.
Ma LCP, CLS e INP dipendono principalmente dal browser e dalla pagina stessa: un'immagine hero non ottimizzata, CSS e JavaScript che bloccano il rendering, layout che si spostano durante il caricamento di font e annunci, e un intenso lavoro sul thread principale causato dai plugin. Nessuna quantità di caching sul server può risolvere un'immagine hero da 2 MB o un tema che carica megabyte di JavaScript. Un hosting onesto rende il contributo del server efficiente e costante, dopodiché spetta al sito mantenere il front-end leggero.
Questa divisione del lavoro è l'utile modello mentale. Garantiamo che la richiesta arrivi al browser rapidamente e rimanga veloce sotto traffico; voi mantenete il payload piccolo e stabile. Dove i due aspetti si incontrano — riscaldamento della cache, consegna edge e mantenimento della reattività del database affinché le pagine dinamiche non si blocchino — è esattamente il punto in cui il nostro stack è ottimizzato, ed è ciò che rende il WordPress gestito su questa piattaforma più rapido rispetto allo stesso sito su un hosting generico.
Domande frequenti
Ho ancora bisogno di un plugin di caching come WP Rocket?
No. La memorizzazione nella cache a pagina intera è gestita a livello di server web da LSCache di LiteSpeed, e il nostro plugin di cache — preinstallato e aggiornato automaticamente — collega correttamente WordPress ad esso, con una cache a oggetti Redis per singolo sito sottostante. L'aggiunta di un secondo plugin di cache a pagina intera sopra al primo entra tipicamente in conflitto con la cache a livello di server anziché aiutare, quindi non è necessaria e non è consigliata.
La memorizzazione nella cache causerà problemi al mio carrello di WooCommerce o alle pagine con accesso effettuato?
No. Carrello, cassa, mio account e qualsiasi pagina con nonce o di sessione sono esclusi dalla cache per impostazione predefinita, e l'ESI mantiene attivi il frammento del carrello e i totali nelle pagine altrimenti memorizzate nella cache. Gli acquirenti vedono sempre il proprio carrello e una cassa funzionante mentre la vetrina continua a caricarsi dalla cache.
Come fa la cache a rimanere aggiornata quando pubblico o modifico?
L'auto-purge intelligente si attiva sui relativi hook di WordPress, quindi la pubblicazione, la modifica dei contenuti o il cambio di un prodotto, prezzo o ordine svuota solo le pagine interessate e i relativi archivi, non l'intera cache, e un crawler le ripristina. È inoltre possibile effettuare lo svuotamento su richiesta dalla dashboard o dall'interno di WordPress.
Il solo hosting può garantirmi dei Core Web Vitals perfetti?
Ti offre il miglior TTFB possibile, che rappresenta la parte del server e un vantaggio iniziale per il Largest Contentful Paint. Ma LCP, CLS e INP sono decisi in gran parte dalla pagina stessa: dimensioni delle immagini, risorse che bloccano il rendering, stabilità del layout e JavaScript sul thread principale. Il nostro stack rende il contributo del server veloce e costante; mantenere leggero il carico utile del front-end è ciò che colma il resto del divario.
Correlati
Provalo gratis per 14 giorni
Crea i tuoi primi siti gratis per 14 giorni — nessuna carta richiesta. Stai trasferiendo una rete esistente? La prima migrazione la offriamo noi.
Inizia gratis