Cos'è la cache? Guida semplice per chi costruisce app

Il caching significa conservare una copia già pronta di qualcosa che era lento o costoso da ottenere, così la richiesta successiva può essere soddisfatta rapidamente da quella copia. La copia salvata si chiama cache. Il tuo browser mette in cache le immagini, così un sito si carica più velocemente alla seconda visita; un server mette in cache il risultato di una query lenta sul database, così non deve eseguirla per ogni visitatore.

La cache rende le app più veloci ed economiche da far funzionare. Il suo grande compromesso è che una copia può diventare obsoleta.

Perché la cache conta quando costruisci con l'AI

Nelle app costruite con l'AI incontrerai la cache in tre modi:

• «Ho aggiornato l'app ma vedo ancora la vecchia versione.» È il caso più comune, e di solito è innocuo — il browser o una CDN mostra una copia salvata.
• Velocità. Se una pagina è lenta perché ricalcola gli stessi numeri per ogni visitatore, mettere in cache il risultato può farla sembrare istantanea.
• Costi. Molti AI builder e hosting addebitano il calcolo, il tempo di database e le chiamate API esterne. Se mille visitatori attivano la stessa richiesta costosa, la cache ti permette di pagarla una volta sola.

Conoscere le basi ti consente di chiedere il caching dove aiuta e di riconoscerlo quando è il motivo per cui qualcosa sembra sbagliato.

Un'analogia quotidiana

Pensa alla cucina di un bar affollato.

Ogni mattina, il cuoco potrebbe preparare ogni caffè con chicchi appena macinati al momento dell'ordine. Sarebbe lento. Invece tiene pronta una caraffa di caffè americano sulla piastra. La maggior parte dei clienti riceve la tazzina in pochi secondi — questo è un cache hit. Quando la caraffa finisce, qualcuno ne prepara una nuova — un cache miss.

Ma il caffè lasciato troppo a lungo diventa stantio, quindi il bar ha una regola: buttare ogni caraffa più vecchia di 30 minuti. Quella regola è il tempo di scadenza della cache. Nessuno terrebbe la stessa caraffa tutto il giorno, e nessuno preparerebbe in anticipo l'ordine personalizzato di qualcuno con latte d'avena e tre zuccheri — alcune cose non andrebbero messe in cache affatto.

Dove vivono le cache

Un singolo caricamento di pagina può passare attraverso diverse cache, dalla più vicina all'utente alla più lontana:

Una CDN (content delivery network) è sostanzialmente una rete mondiale di cache per i file del tuo sito.

Come una cache decide cosa conservare

Ogni cache deve rispondere alle stesse domande:

• Cosa si può mettere in cache? Dati pubblici e condivisi (un'immagine di prodotto, un post del blog) — sì. Dati privati (la pagina account di un utente, i suoi messaggi) — mai in una cache condivisa.
• Per quanto tempo? Questo è il TTL (time to live). Un logo può restare in cache per un anno; un livello di scorte per 30 secondi.
• Come viene aggiornata? Oppure la copia scade e viene recuperata di nuovo, oppure l'app rimuove deliberatamente la copia quando i dati cambiano — si chiama invalidazione.

Per i siti web, il server dice a browser e CDN come mettere in cache ogni file tramite l'header Cache-Control. Ad esempio, Cache-Control: max-age=3600 significa «puoi riutilizzare questa copia per un'ora».

Gli strumenti di build moderni risolvono la parte più difficile per i file statici con il cache busting: ogni volta che un file cambia, riceve un nuovo nome con un'impronta, come app.3f9a2c.js. I browser possono mettere in cache il vecchio nome per molto tempo, perché la nuova versione ha semplicemente un nome diverso.

Un esempio pratico: un catalogo prodotti

Hai un piccolo negozio online. La home page mostra 50 prodotti con prezzi e livelli di scorta presi dal database, più una lista «di tendenza» che richiede un calcolo lento su tutti gli ordini.

1. Immagini e script vengono messi in cache dal browser e dalla CDN per molto tempo. Ogni nuova build dà ai file modificati nuovi nomi, quindi gli aggiornamenti continuano ad apparire.
2. La lista di tendenza viene calcolata una volta ogni 10 minuti e salvata in una cache applicativa. Ogni visitatore in quei 10 minuti riceve subito il risultato salvato.
3. I prezzi vengono messi in cache per un breve periodo, e la cache viene svuotata ogni volta che modifichi un prodotto, così i clienti non vedono mai un prezzo vecchio a lungo.
4. Le scorte al checkout non vengono mai messe in cache. Quando qualcuno clicca «Acquista», l'app controlla il database reale, quindi non può vendere un articolo appena esaurito.
5. Il carrello e le pagine account non vengono mai conservati nelle cache condivise, perché sono personali.

Il risultato: la home page è veloce, il database fa molto meno lavoro e nulla che riguardi denaro o privacy è mai obsoleto.

Termini chiave

Idee sbagliate comuni

• «La cache è sempre utile.» Mettere in cache la cosa sbagliata causa bug reali: prezzi vecchi, nuovi post che non compaiono o — nel caso peggiore — la pagina privata di un utente mostrata a un altro. Usa la cache in modo deliberato.
• «Se vedo la vecchia versione, il mio aggiornamento è fallito.» Di solito no. Prova un aggiornamento forzato (Ctrl+Maiusc+R, o Cmd+Maiusc+R su Mac) o una finestra in incognito prima di pensare che qualcosa sia rotto.
• «La cache risolve un'app lenta.» Nasconde la lentezza per le richieste ripetute. La prima richiesta resta lenta, e se il problema di fondo è un indice mancante nel database, va sistemato anche quello.
• «Dovrei mettere in cache tutto il più a lungo possibile.» I tempi lunghi vanno bene per i file che ricevono nuovi nomi quando cambiano. Per le pagine HTML e i dati, tempi più brevi sono più sicuri.
• «Svuotare la mia cache risolve il problema per tutti.» Svuota solo il tuo browser. I visitatori e le cache delle CDN hanno ancora le loro copie.

Cosa chiedere al tuo AI builder

• «Quali parti di questa app sono lente, e quali si potrebbero mettere in cache in sicurezza?»
• «Metti in cache la [lista di tendenza / risultato dell'API] per [N] minuti, e svuotala quando cambiano i dati sottostanti.»
• «Assicurati che nessuna pagina con dati personali o dell'account possa essere messa in cache da una CDN o da una cache condivisa.»
• «Imposta tempi di cache lunghi per i file statici con impronta e brevi per l'HTML.»
• «Metti in cache le risposte di [API esterna] così non la chiamiamo a ogni caricamento di pagina — e dimmi quanto potrebbero diventare obsoleti quei dati.»
• «Dopo la pubblicazione vedo una versione vecchia. È la cache del mio browser, o qualcosa non è stato distribuito?»

Caching in Mythex

Dopo aver pubblicato un aggiornamento di un'app Mythex, la documentazione segnala che le cache delle CDN possono restare indietro per un breve periodo, e un aggiornamento forzato dell'URL pubblico mostra la nuova versione — vedi Come pubblicare. La pagina Limiti di hosting consiglia anche di mettere in cache le risorse statiche, perché hosting, tempo di database e banda vengono pagati dal tuo saldo di crediti. Tutto il resto — mettere in cache i risultati delle query o le risposte delle API — è qualcosa che chiedi all'agente di costruire nella tua app.

Letture correlate: cos'è una CDN, come rendere il tuo sito più veloce e cos'è il rate limiting.

Domande