Per verificare se LiteSpeed Cache funziona, controlla gli header HTTP della pagina da una finestra anonima. La prima richiesta può mostrare X-LiteSpeed-Cache: miss; ricaricando la stessa pagina, una risposta memorizzabile dovrebbe normalmente diventare hit. L’assenza dell’header, un valore no-cache o un MISS permanente richiedono controlli differenti.
Il semplice fatto che il plugin LiteSpeed Cache sia attivo non dimostra che una pagina venga servita dalla cache del server. Per una diagnosi corretta bisogna testare la risposta HTTP, evitare sessioni WordPress autenticate e distinguere tra cache svuotata, pagina esclusa, cookie, query string, contenuto privato e configurazione non funzionante.
Questa guida spiega come leggere LSCache HIT o MISS, come ripetere il test e quali controlli effettuare prima di modificare le impostazioni.
Che cosa significano HIT e MISS
| Header o valore | Significato operativo |
|---|---|
X-LiteSpeed-Cache: hit | La risposta è stata servita da un oggetto già presente nella cache LiteSpeed. |
X-LiteSpeed-Cache: miss | L’oggetto non era disponibile per quella richiesta; il server ha generato la pagina e può aver avviato la creazione della cache. |
X-LiteSpeed-Cache-Control: no-cache | La pagina è stata esclusa o marcata per non essere memorizzata. |
| Header assente | La risposta potrebbe non attraversare LSCache, provenire da un CDN, essere esclusa oppure avere una configurazione incompleta. |
X-QC-Cache: hit o miss | La risposta è passata dalla cache QUIC.cloud; va distinta dalla cache dell’origine. |
Un singolo miss non è un errore. È normale subito dopo un purge, alla prima visita di un URL, dopo una modifica o quando la cache è scaduta. Il controllo utile consiste nel richiamare due o tre volte la stessa URL nelle stesse condizioni.
Prima del test: usa una pagina adatta
Non testare per prima cosa carrello, checkout, area riservata, amministrazione WordPress, anteprima o una pagina personalizzata per utente. Questi contenuti devono spesso restare dinamici.
Scegli invece:
- homepage pubblica;
- articolo del blog;
- pagina informativa accessibile senza login;
- URL senza parametri di tracciamento o query string;
- pagina che non mostra dati diversi per ogni visitatore.
Apri una finestra anonima o privata, perché un cookie di login WordPress, WooCommerce o altri plugin può causare un bypass.
Metodo 1: controllare gli header dal browser
- apri la pagina in una finestra anonima;
- premi F12 e apri la scheda Network o Rete;
- ricarica la pagina;
- seleziona la prima richiesta di tipo documento, corrispondente all’URL della pagina;
- apri la sezione Response Headers;
- cerca
X-LiteSpeed-Cache,X-LiteSpeed-Cache-Controloppure gli header QUIC.cloud.
Ripeti il caricamento senza cambiare URL. Dopo un primo miss, la seconda risposta dovrebbe spesso essere hit. Disattiva temporaneamente nel browser l’opzione “Disable cache” degli strumenti di sviluppo se altera il comportamento della richiesta.
Metodo 2: verificare con curl
Da terminale puoi visualizzare solamente gli header:
curl -sSIL https://www.esempio.it/ | grep -iE 'x-litespeed|x-qc-cache|cache-control|vary'
Esegui il comando due volte. Se sono presenti redirect, -L li segue. Per evitare che una risposta compressa o un proxy nascondano dettagli, puoi anche usare:
curl -sS -D - -o /dev/null https://www.esempio.it/
Non utilizzare URL reali contenenti token, anteprime o parametri riservati nei ticket o negli screenshot pubblici.
Perché vedo sempre MISS
Cache appena svuotata
Dopo Purge All, aggiornamenti, modifiche al tema o salvataggi di contenuti, la prima richiesta deve rigenerare l’oggetto. Ripeti il test sulla stessa pagina.
Utente autenticato o cookie di esclusione
WordPress, WooCommerce, membership e plugin multilingua possono impostare cookie che rendono la risposta privata. Verifica da una finestra anonima pulita e non copiare cookie dal browser normale.
URL con query string
Parametri come ricerche, filtri, anteprime e campagne possono produrre una variante o essere esclusi. Testa prima l’URL canonico senza parametri.
Pagina esclusa
Controlla LiteSpeed Cache → Cache → Excludes e le esclusioni impostate da plugin, tema o codice. Una pagina esclusa intenzionalmente non deve diventare HIT.
Cache pubblica disattivata
In LiteSpeed Cache → Cache verifica che la cache sia abilitata. Non attivare indiscriminatamente cache per utenti autenticati, REST API o pagine private solo per ottenere un HIT.
TTL scaduto o purge frequente
Un plugin, un webhook, un crawler o aggiornamenti continui possono svuotare la cache troppo spesso. Controlla se il MISS compare immediatamente dopo pubblicazioni, sincronizzazioni o attività pianificate.
CDN o proxy davanti al server
Cloudflare o QUIC.cloud possono rispondere prima dell’origine. Per capire quale livello serve la pagina, osserva insieme gli header del CDN e quelli LiteSpeed. Un HIT del CDN non dimostra necessariamente un HIT dell’origine e viceversa.
Quando il MISS è corretto
Non tutte le pagine devono essere memorizzate. Il MISS o il bypass sono corretti per:
- carrello e checkout;
- account cliente e aree riservate;
- pagine con nonce o token personali;
- anteprime WordPress;
- richieste POST;
- risposte con cookie o dati personalizzati;
- endpoint amministrativi e operazioni AJAX sensibili.
L’obiettivo non è trasformare ogni risposta in HIT, ma memorizzare in sicurezza le pagine pubbliche ripetitive.
Come controllare senza alterare il sito
- non cambiare più impostazioni contemporaneamente;
- annota URL, ora e header della prima richiesta;
- ripeti il test sulla stessa pagina;
- prova un secondo URL pubblico;
- controlla da anonimo e da un’altra rete;
- verifica eventuali cookie e query string;
- solo dopo controlla esclusioni, cache e purge.
Per la configurazione generale consulta LiteSpeed Cache per WordPress: configurazione consigliata su Xlogic. Il controllo LSCache HIT o MISS va ripetuto dopo ogni modifica importante.
Browser cache e test realmente comparabili
La cache del browser non è la stessa cosa della page cache LiteSpeed. Il browser può riutilizzare immagini, CSS o JavaScript anche quando il documento HTML viene richiesto nuovamente al server. Per questo devi selezionare la richiesta di tipo documento e leggere gli header della risposta, non basarti soltanto sulla velocità percepita.
Durante i confronti mantieni invariati protocollo, dominio, slash finale e parametri. https://esempio.it/ e https://www.esempio.it/ possono seguire percorsi e cache differenti. Evita inoltre di alternare richieste HEAD e GET senza considerare che alcuni proxy o plugin possono trattarle in modo diverso. Il test più affidabile ripete la stessa richiesta GET anonima e confronta gli header.
Quando aprire un ticket Xlogic
Apri un ticket se due pagine pubbliche continuano a non mostrare alcun header LiteSpeed dopo più richieste anonime, se il plugin segnala che la cache non è disponibile o se il comportamento cambia tra domini dello stesso account.
Indica dominio, URL testata, data e ora, output di curl -I, presenza di Cloudflare o QUIC.cloud, plugin di cache attivi e operazioni già eseguite. Non inviare credenziali.
Fonti tecniche ufficiali
- LiteSpeed Cache: Getting Started
- LiteSpeed: X-LiteSpeed-Cache header
- LiteSpeed Cache for WordPress: Cache
Domande frequenti su LSCache HIT e MISS
Un valore MISS significa che LiteSpeed Cache non funziona?
No. La prima richiesta dopo un purge o la scadenza può essere MISS e creare l’oggetto. Ripeti la stessa richiesta da anonimo: una pagina memorizzabile dovrebbe normalmente diventare HIT.
Perché da amministratore vedo MISS e da anonimo HIT?
Gli utenti autenticati hanno cookie e contenuti potenzialmente personalizzati. È normale che la cache pubblica venga evitata per proteggere dati e funzionalità riservate.
Cloudflare HIT equivale a LiteSpeed HIT?
No. Sono livelli distinti. Cloudflare può servire una copia dal proprio edge mentre l’origine non viene interrogata; controlla gli header di entrambi i sistemi.
Devo memorizzare carrello e checkout?
No. Queste pagine contengono dati di sessione e devono normalmente essere escluse dalla cache pubblica. Forzare un HIT può mostrare informazioni errate ad altri utenti.
Quali dati servono per il ticket?
Invia URL pubblica, ora del test, output degli header, numero di richieste eseguite, eventuale CDN e plugin di cache presenti. Non inviare password o cookie di sessione.