Il caching è una delle funzioni più antiche del proxy: invece di scaricare più volte lo stesso contenuto, se ne conserva una copia e si risponde localmente alle richieste successive. Con la diffusione di HTTPS l'ambito di questa funzione si è ristretto, ma non è scomparso del tutto — e nella tua pipeline di raccolta dati resta una fonte di risparmio importante.
Flusso di base
In caso di cache hit non si raggiunge affatto il server di origine. È un guadagno in termini di velocità, banda e carico sul server di destinazione.
Chi decide che cosa viene conservato?
La decisione spetta al server, che la comunica con l'header Cache-Control :
| Direttiva | Significato | Comportamento del proxy |
|---|---|---|
public | La cache condivisa può conservarlo | Conserva |
private | Solo il browser può conservarlo | Non conserva |
no-store | Non va conservato affatto | Non conserva |
no-cache | Può essere conservato ma va convalidato a ogni uso | Effettua una richiesta condizionale |
max-age=3600 | Considerato fresco per 3600 secondi | Per tutta la durata non contatta l'origine |
s-maxage=600 | Durata separata per la cache condivisa | Ha la precedenza su questo valore |
no-cachenon significa "non conservare affatto" — significa "conserva ma verifica prima di usare". L'equivalente di "non conservare affatto" è no-store.
Richieste condizionali: 304 Not Modified
Quando la copia in cache invecchia, il proxy non è obbligato a riscaricare il contenuto da zero. Chiede al server: "la versione che ho è ancora valida?":
La risposta 304 non contiene corpo; tornano solo gli header. Significa ridurre una pagina da 500 KB a 300 byte.
Usare questo meccanismo nella tua pipeline di raccolta dati riduce sensibilmente il costo della banda .
Come ha inciso HTTPS sulla cache?
Quando viene stabilito un tunnel CONNECT il proxy non può vedere i contenuti — e quindi non può nemmeno metterli in cache. Poiché quasi tutto il web è passato a HTTPS, il classico caching proxy è rimasto in gran parte inutilizzabile.
Per questo il caching moderno è uscito dal livello proxy e si è spostato sul livello CDN e client.
Realizzare la propria cache
Se il caching proxy non è utilizzabile, puoi ottenere lo stesso vantaggio all'interno della tua applicazione. Nelle pipeline di raccolta dati è molto efficace:
Questo semplice livello evita di riscaricare più volte pagine che cambiano di rado. Su risorse tariffate a GB come i residential proxy il risparmio si riflette direttamente in fattura.
Quando il caching è sbagliato?
Cache adatta
- Pagine di prodotto e categoria che cambiano di rado.
- Dati di riferimento statici.
- Lavori che scaricano la stessa pagina più volte al giorno.
- Fase di sviluppo e test (preserva la quota).
Cache sbagliata
- Monitoraggio di prezzi e disponibilità in tempo reale.
- Contenuti personalizzati.
- Pagine che richiedono una sessione.
- Attività SEO che seguono le variazioni di posizionamento.
Lavorare con dati obsoleti presi dalla cache può produrre risultati peggiori del non raccogliere dati affatto. Negli ambiti sensibili al tempo, come prezzi e disponibilità, mantieni durate di cache molto brevi oppure non usarla affatto.
Riepilogo
Con la diffusione di HTTPS il caching proxy ha in gran parte perso la sua funzione classica, perché in un tunnel CONNECT il proxy non vede i contenuti. In compenso è ancora possibile — e molto utile — costruire la stessa logica nel tuo livello applicativo. Le richieste condizionali basate su ETag eliminano quasi tutto il traffico sui contenuti che cambiano di rado. Sui dati sensibili al tempo, invece, la cache va evitata. Per il calcolo dei consumi vedi il nostro articolo sulla banda puoi consultarlo.