# Caching del sito Source: https://support.kapsulehost.com/it-it/site-cache Caching è il singolo miglioramento di velocità più importante disponibile per un sito WordPress: la cache full-page serve HTML già pronto senza eseguire PHP, mentre la cache degli oggetti mantiene i risultati del database in memoria. Questa guida copre entrambe, cosa viene escluso automaticamente dalla cache e come svuotarla e riscaldarla. ## Dove si trova la cache in KPanel 1. Accedi a [KPanel](https://kpanel.kapsulehost.com). 2. Clicca su **Siti web** nella barra laterale sinistra, poi clicca sul sito. 3. Nel menu sinistro del sito, apri **WordPress**, poi **Cache**. L'indirizzo diretto è `/websites//cache`. ![Caching settings for a site in KPanel](https://support.kapsulehost.com/help/screenshots/site-cache.ebc987e4.webp) > **Note:** Il gruppo **WordPress** compare solo per i siti WordPress e WooCommerce. La cache qui è un diritto del piano: la cache full-page e la cache degli oggetti sono incluse con Managed WordPress. Negli altri piani la pagina mostra un pannello di upgrade che descrive cosa è disponibile, invece dei controlli. ## Cache full-page La cache full-page memorizza l'HTML finito di una pagina e lo serve direttamente al visitatore successivo. Per un visitatore anonimo, questo significa nessuna esecuzione di PHP e nessuna query al database: la richiesta viene soddisfatta prima ancora che WordPress venga caricato. La scheda mostra un indicatore **On** oppure **Off**, e quando è attiva, la data in cui è stata abilitata, se il routing è stato confermato e la durata della cache. Per abilitarla, clicca su **Abilita cache full-page**. Per disattivarla di nuovo, clicca su **Disable**. La cache viene svuotata automaticamente quando pubblichi o aggiorni un articolo, quindi le tue modifiche compaiono immediatamente invece di aspettare la scadenza della durata. > **Tip:** Se il tuo sito è letto principalmente da visitatori anonimi, questo è l'interruttore di maggior valore della pagina. È comune che la differenza sia di un ordine di grandezza sul tempo al primo byte, perché la parte lenta di una richiesta WordPress è proprio quella che non avviene più. ## Svuotamento e riscaldamento Due azioni compaiono una volta che la cache full-page è attiva. **Svuota la cache** svuota la cache immediatamente. Usala dopo una modifica che WordPress non considera un aggiornamento di un articolo: modificare un file del tema, cambiare un widget, aggiornare un menu o alterare un'impostazione di un plugin che influisce sull'output. Il visitatore successivo di ogni pagina ottiene una copia aggiornata. **Cache calda** precarica le tue pagine in modo che siano già in cache prima che un visitatore le richieda. Dopo il riscaldamento, un banner indica quante pagine sul totale sono state precaricate ed elenca i primi URL. La sequenza naturale dopo una modifica di design è: svuota, poi riscalda. In questo modo nessuno deve essere il visitatore sfortunato che paga il prezzo del primo rendering non in cache. Per la cache edge davanti al tuo sito, che è un livello separato, vedi [Svuotare la cache del CDN](https://support.kapsulehost.com/it-it/cdn-cache-purge). ## Cosa non viene mai memorizzato in cache Alcuni URL devono sempre eseguire PHP, perché il loro output varia per ogni visitatore o ha effetti collaterali. Questi percorsi vengono esclusi automaticamente e non è necessario configurare nulla: | Percorso | Motivo | |---|---| | `/wp-admin/` | L'area amministrativa di WordPress è sempre dinamica | | `/wp-login.php` | La pagina di login non viene mai messa in cache | | `/cart/` | Il carrello WooCommerce è specifico per ogni visitatore | | `/checkout/` | Il checkout WooCommerce è specifico per ogni visitatore | | `/my-account/` | Le pagine dell'account WooCommerce sono specifiche per ogni visitatore | | `/wp-cron.php` | Le attività pianificate devono effettivamente essere eseguite | | `/?wc-ajax=*` | Endpoint AJAX WooCommerce | Oltre alle regole sui percorsi, contano anche i cookie. Un utente WordPress connesso, oppure un visitatore con un cookie di sessione WooCommerce attivo, riceve sempre una risposta dinamica, anche su una pagina che è messa in cache per tutti gli altri. Questo è il motivo per cui il proprietario di un negozio che naviga sul proprio sito spesso non vede alcun beneficio, mentre i visitatori anonimi sì. > **Warning:** Poiché di solito sei connesso, testare il comportamento della cache nel tuo browser normale ti trarrà in inganno. Esegui il test in una finestra privata, oppure in un browser in cui non hai effettuato l'accesso. ## Cache degli oggetti La cache degli oggetti è un livello diverso. Invece di memorizzare pagine finite, conserva in memoria i risultati delle query al database e i transient di WordPress, in modo che il lavoro ripetuto non venga rifatto. La scheda mostra un indicatore **On** oppure **Off**, e quando è attiva, la data in cui è stata abilitata. Usa **Attiva** e **Disattiva** per modificarla. La cache degli oggetti è utile esattamente dove la cache full-page non può arrivare: utenti connessi, schermate di amministrazione e pagine specifiche per ogni visitatore come carrello e checkout. Questo la rende particolarmente preziosa per negozi molto frequentati e siti di membership, dove gran parte del traffico è autenticato e quindi non viene mai messo in cache a livello di pagina. Usare entrambe insieme è la configurazione normale. La cache full-page gestisce il traffico anonimo, mentre la cache degli oggetti velocizza tutto ciò che deve comunque eseguire PHP. ## Scegliere cosa abilitare - **Sito di contenuti, principalmente lettori anonimi.** La cache full-page è la priorità. La cache degli oggetti aggiunge un miglioramento minore in più. - **Negozio WooCommerce.** Abilita entrambe. La cache full-page copre comunque le tue pagine di prodotto e categoria per i visitatori in navigazione, mentre la cache degli oggetti gestisce il carrello, il checkout e le pagine dell'account che non possono mai essere messe in cache. - **Sito di membership o community dove quasi tutti sono connessi.** La cache degli oggetti svolge il lavoro pesante, perché la maggior parte delle richieste bypasserà la cache di pagina per progettazione. ## Risoluzione dei problemi **Ho aggiornato il sito ma i visitatori vedono ancora la vecchia versione.** Svuota la cache, poi riscaldala. Se è ancora obsoleta, ricorda che potrebbe esserci anche una cache edge: vedi [Svuotare la cache del CDN](https://support.kapsulehost.com/it-it/cdn-cache-purge). **La cache non mi serve a niente.** Quasi sicuramente sei connesso. Verifica in una finestra privata. **Il carrello o un modulo si comporta in modo strano per i visitatori anonimi.** I percorsi standard di commercio vengono esclusi automaticamente, ma una pagina dinamica personalizzata o fornita da un plugin su un URL non standard non lo è. Se una pagina non deve mai essere messa in cache e non è nell'elenco delle esclusioni, vale la pena segnalarlo al supporto così possiamo esaminare la regola. **La scheda dice che la cache è inclusa con Managed WordPress.** Il tuo piano attuale non la include. Il banner rimanda alla pagina dei piani. **Controllo del routing in sospeso.** La cache è abilitata e la conferma del routing non è ancora stata completata. Attendi un momento e aggiorna la pagina. **Una pagina mostra contenuti personalizzati sbagliati.** Qualsiasi contenuto personalizzato deve essere escluso dalla cache di pagina oppure essere renderizzato lato client. Se un plugin personalizza l'output su un URL altrimenti idoneo alla cache senza impostare un cookie di sessione, la cache di pagina non può saperlo. Esegui il test in una finestra privata e segnalalo al supporto se ne trovi uno. ## Pagine correlate - [Prestazioni del sito e APM](https://support.kapsulehost.com/it-it/site-performance) per verificare se la cache ha effettivamente aiutato. - [Analisi del traffico del sito](https://support.kapsulehost.com/it-it/site-analytics) per il tasso di successo della cache edge. - [Abilitare il CDN](https://support.kapsulehost.com/it-it/cdn-enabling) per aggiungere una cache edge davanti a tutto questo. - [Eseguire un backup](https://support.kapsulehost.com/it-it/taking-a-backup) prima di apportare modifiche più grandi a un sito in produzione.