Hosting e prestazioni
Come rendiamo veloce WordPress: LiteSpeed Enterprise, LSCache e Redis per sito
La richiesta WordPress più rapida è quella che non viene mai eseguita — ecco come il nostro stack risponde alla maggior parte delle visite dalla cache prima ancora che PHP o MySQL vengano richiamati, e cosa significa per i Core Web Vitals.
La richiesta più veloce è quella che non viene mai eseguita
Una richiesta WordPress standard richiede molte risorse. Il server web passa la mano a PHP, PHP avvia WordPress, esegue i plugin, interroga MySQL alcune dozzine di volte, assembla l'HTML e solo allora restituisce i byte. Su un sito trafficato, l'intero processo si ripete per ogni visitatore, ed è qui che se ne va quasi tutto il vostro tempo al primo byte (time-to-first-byte).
La nostra risposta è fare in modo che, per la maggior parte delle visite, nulla di tutto questo avvenga. Su tutti i siti che ospitiamo — oltre 100.000 siti PBN più il comune WordPress gestito — la stragrande maggioranza delle visualizzazioni di pagina front-end viene servita direttamente dalla cache come pagina completa pre-renderizzata, senza invocare PHP né toccare il database. Il resto di questo articolo spiega come si integrano i vari livelli che rendono possibile tutto ciò e perché ciascuno di essi si guadagna il proprio posto.
L'inquadramento fondamentale è che non si tratta di cache in concorrenza tra cui scegliere. La cache di pagina intera, la cache degli oggetti e l'edge della CDN intercettano ciascuna una classe diversa di richieste, e il vero valore risiede nel modo in cui passano il carico l'una all'altra.
LiteSpeed Enterprise + LSCache: il livello a pagina intera
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 tag e controllo della cache LiteSpeed, e LiteSpeed distribuisce la pagina completa direttamente alla richiesta successiva: nessun processo PHP generato, nessuna query MySQL eseguita. 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 operare prima nel ciclo di vita della richiesta e conserva le pagine in un formato che il server può svuotare istantaneamente. Un crawler della cache mantiene le pagine più popolari sempre pronte, evitando che il primo visitatore dopo uno svuotamento debba farsi carico del tempo di rigenerazione della pagina. Il risultato è un TTFB nettamente inferiore e più costante rispetto a una cache basata esclusivamente su plugin e aggiunta a uno stack generico, in cui la cache si trova ancora dietro a PHP.
Il nostro plugin di cache a livello di repository viene fornito preinstallato e aggiornato automaticamente su ogni sito, collegando correttamente WordPress a LSCache fin da subito. Su un'origine non LiteSpeed, semplicemente non emette intestazioni di pagina intera e non interferisce, mentre la cache degli oggetti e le regole di esclusione continuano a svolgere il proprio lavoro; in questo modo, un sito migrato non viene mai lasciato in uno stato danneggiato o configurato a metà.
Garantire la massima velocità senza fornire contenuti obsoleti: ESI ed eliminazione automatica intelligente
La memorizzazione nella cache aggressiva dell'intera pagina presenta due classiche modalità di errore: servire a un utente connesso la pagina di un altro e servire a chiunque una pagina che avrebbe dovuto subire modifiche. Entrambi i problemi si risolvono a livello del livello di memorizzazione nella cache anziché memorizzando meno nella cache.
ESI (Edge Side Includes) consente di memorizzare nella cache la pagina lasciando varchi per le parti che devono rimanere dinamiche. Su un negozio WooCommerce, le pagine del catalogo, dei prodotti e delle categorie vengono servite come cache a pagina intera per ottenere 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. Il carrello, la cassa, l'account personale e qualsiasi pagina con nonce o sessione sono esclusi per impostazione predefinita. Gli acquirenti vedono sempre il proprio carrello e una procedura di pagamento funzionante; tutti continuano a ricevere la vetrina dalla cache.
La freschezza dei contenuti è gestita dall'eliminazione automatica intelligente. I ganci di eliminazione si attivano automaticamente quando cambiano contenuti, prodotti, prezzi o ordini, consentendo l'aggiornamento immediato delle pagine memorizzate nella cache anziché a intervalli prefissati; inoltre, è possibile eseguire l'eliminazione su richiesta dalla dashboard o direttamente dall'interno di WordPress. L'eliminazione basata su tag fa sì che la modifica di un singolo articolo svuoti solo quell'articolo e i relativi archivi, non l'intera cache, evitando così che una semplice modifica provochi un avvio a freddo dell'intero sito.
Cache degli oggetti Redis per singolo sito: per ciò che non può essere una pagina intera
Non tutte le richieste possono essere una pagina completa statica. Le sessioni con accesso effettuato, l'amministrazione di WordPress, i carrelli WooCommerce, la ricerca e i frammenti dinamici che ESI lascia attivi devono tutti eseguire PHP. Per questi, l'obiettivo passa da 'saltare l'applicazione' a 'saltare il database'.
Ogni sito riceve la propria cache degli oggetti Redis dedicata. WordPress memorizza nella cache i risultati delle letture ripetute del database — opzioni, transient, ricerche di post e termini, dati sui prodotti e sulle sessioni di WooCommerce — in memoria, evitando che la stessa query venga eseguita su MySQL a ogni richiesta. L'effetto è particolarmente evidente proprio laddove la cache dell'intera pagina non può intervenire: bacheche più scattanti, carrelli più veloci e un carico del database notevolmente ridotto in presenza di traffico.
La cache degli oggetti è specifica per ogni sito e non condivisa, il che è fondamentale sia per le prestazioni sia per l'isolamento. In combinazione con la limitazione del database per singolo sito, le query pesanti o scritte male di un sito non possono privare di risorse il database per i siti vicini. Può leggere ulteriori informazioni su come si integra l'intera configurazione multilivello nella nostra pagina delle funzionalità di memorizzazione nella cache, e sui limiti tra i tenant nella sezione dedicata all'isolamento.
L'edge e il trasporto sottostante
La cache presente 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 a riposo anche sotto carico. Per la nostra linea di hosting senza footprint, lo stesso edge è un pool multi-CDN distribuito tra diversi provider, che persegue sia un obiettivo di footprint sia uno di prestazioni; sul tradizionale WordPress è semplicemente un livello veloce e ben strutturato che mantiene inattive le origini.
Alla base, non si risparmia sui fondamentali. I siti operano su storage NVMe con HTTP/3, pertanto i byte inviati dalla cache arrivano tramite un trasporto moderno e multiplato, con uno storage veloce dietro ogni mancato riscontro della cache (cache miss). Nessuno di questi livelli è un componente aggiuntivo: LiteSpeed, LSCache, Redis per sito, NVMe e HTTP/3 sono la base di ogni piano, non un livello di vendita superiore.
Cosa incide davvero su Core Web Vitals
È importante essere precisi, poiché il web hosting viene spesso promosso in modo esagerato per quanto riguarda i Core Web Vitals. Il TTFB è la parte dell'equazione gestita dal server, e lo stack di memorizzazione nella cache sopra descritto è ciò che lo riduce: una pagina intera memorizzata nella cache e fornita tramite HTTP/3 dall'edge rappresenta il livello più basso possibile per il TTFB. Poiché il TTFB costituisce la fase iniziale del Largest Contentful Paint, un'origine rapida offre a ciascuna metrica a valle un vantaggio iniziale che altrimenti non potrebbe ottenere.
Ma LCP, CLS e INP sono decisi principalmente nel browser, dalla pagina stessa: un'immagine hero non ottimizzata, CSS e JavaScript che bloccano il rendering, layout che si sposta al caricamento di caratteri e annunci, e un pesante carico di lavoro sul thread principale dovuto ai plugin. Nessun livello di memorizzazione nella cache del server può risolvere un'immagine hero da 2 MB o un tema che invia megabyte di JavaScript. Un hosting onesto rende il contributo del server virtualmente trascurabile e coerente, dopodiché spetta al sito mantenere il front-end leggero.
Questa divisione del lavoro rappresenta un utile modello concettuale. Noi garantiamo che la richiesta raggiunga il browser rapidamente e rimanga veloce anche sotto traffico; Lei si occupa di mantenere il payload leggero e stabile. Il punto in cui i due elementi si incontrano — il preriscaldamento della cache, la distribuzione edge e il mantenimento della reattività del database per evitare blocchi alle pagine dinamiche — è esattamente ciò su cui è ottimizzato il nostro stack, ed è ciò che rende un'istanza gestita di WordPress su questa piattaforma più veloce rispetto allo stesso sito su un hosting generico.
Domande frequenti
Ho ancora bisogno di un plugin di memorizzazione nella cache come WP Rocket?
No. La memorizzazione nella cache dell'intera pagina è gestita a livello di server web da LSCache di LiteSpeed, e il nostro plugin di cache proprietario — preinstallato e aggiornato automaticamente — vi collega correttamente WordPress, supportato da una cache degli oggetti Redis per ciascun sito. L'aggiunta di un secondo plugin per la cache dell'intera pagina solitamente entra in conflitto con la cache a livello di server anziché essere d'aiuto, pertanto non è necessaria né consigliata.
La memorizzazione nella cache comprometterà il carrello di WooCommerce o le pagine degli utenti che hanno effettuato l'accesso?
No. Il carrello, la cassa, my-account e qualsiasi pagina di nonce o di sessione sono esclusi dalla cache per impostazione predefinita, ed ESI mantiene aggiornati il frammento del carrello e i totali sulle pagine altrimenti memorizzate nella cache. Gli acquirenti vedono sempre il proprio carrello e una cassa funzionante mentre la vetrina del negozio continua a caricarsi dalla cache.
In che modo la cache rimane aggiornata quando pubblico o modifico?
L'eliminazione automatica intelligente si attiva sugli hook pertinenti di WordPress, quindi la pubblicazione, la modifica dei contenuti o la variazione di un prodotto, prezzo o ordine svuota solo le pagine interessate e i relativi archivi, non l'intera cache, e un crawler le preriscalda nuovamente. È inoltre possibile eseguire l'eliminazione su richiesta dalla dashboard o dall'interno di WordPress.
L'hosting da solo può offrirmi Core Web Vitals perfetti?
Offre il miglior TTFB possibile, che rappresenta il contributo del server e un vantaggio iniziale per il Largest Contentful Paint. Tuttavia, LCP, CLS e INP sono determinati 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 l'apporto del server rapido e costante; mantenere leggero il payload del front-end è ciò che colma il resto del divario.
Correlati
Lo provi gratuitamente per 14 giorni
Attivi i Suoi primi siti gratuitamente per 14 giorni — senza carta. Vuole trasferire una rete esistente? Le migrazioni sono gratuite e senza limiti.
Inizia gratis