Cache degli stili. Come rimuovere la cache dei file css e js. L'aggiornamento della pagina a volte salva

Includendo CSS e Javascript esterni, vogliamo ridurre al minimo le richieste HTTP non necessarie.

Per questo, i file .js e .css vengono serviti con intestazioni che forniscono una memorizzazione nella cache affidabile.

Ma cosa succede se qualcuno di questi file cambia durante lo sviluppo? Tutti gli utenti hanno una vecchia versione nella cache: fino a quando la cache non sarà obsoleta, arriveranno molti reclami sull'integrazione non corretta del server e delle parti client.

Il modo corretto di caching e versioning elimina completamente questo problema e garantisce una sincronizzazione affidabile e trasparente delle versioni di stile/script.

Facile memorizzazione nella cache ETag

Il modo più semplice per memorizzare nella cache le risorse statiche è utilizzare ETag.

È sufficiente abilitare l'impostazione del server appropriata (per Apache è abilitata per impostazione predefinita) - e ETag verrà assegnato a ciascun file nelle intestazioni - un hash che dipende dal tempo di aggiornamento, dalla dimensione del file e (su file system basati su inode ) inodo.

Il browser memorizza tale file nella cache e, alle richieste successive, specifica l'intestazione If-None-Match dall'ETag del documento memorizzato nella cache. Dopo aver ricevuto tale intestazione, il server può rispondere con un codice 304, quindi il documento verrà prelevato dalla cache.

Sembra così:

Prima richiesta al server (cache clean) GET /misc/pack.js HTTP / 1.1 Host: site

In generale, il browser di solito aggiunge una serie di intestazioni come User-Agent, Accept, ecc. Sono tagliati per brevità.

Risposta del server Il server invia in risposta un documento con codice 200 e ETag: HTTP / 1.x 200 OK Content-Encoding: gzip Content-Type: text / javascript; charset = utf-8 Etag: "3272221997" Accept-Ranges: bytes Content-Length: 23321 Date: Fri, 02 May 2008 17:22:46 GMT Server: lighttpd Prossima richiesta del browser Alla prossima richiesta il browser aggiunge If-None-Match: (ETag memorizzato nella cache): GET /misc/pack.js HTTP / 1.1 Host: site If-None-Match: "453700005" Risposta del server Il server sta cercando - sì, il documento non è cambiato. Ciò significa che puoi emettere un codice 304 e non inviare nuovamente il documento. HTTP / 1.x 304 Non modificato Codifica contenuto: gzip Etag: "453700005" Tipo contenuto: testo / javascript; set di caratteri = utf-8 Intervalli di accettazione: byte Data: Tue, 15 Apr 2008 10:17:11 GMT

In alternativa, se il documento è cambiato, il server invia semplicemente 200 con un nuovo ETag.

Il bundle Last-Modified + If-Modified-Since funziona in modo simile:

1. il server invia la data dell'ultima modifica nell'intestazione Last-Modified (invece di ETag)
2. il browser memorizza il documento nella cache e alla successiva richiesta per lo stesso documento invia la data della versione memorizzata nella cache nell'intestazione If-Modified-Since (invece di If-None-Match)
3. il server verifica le date, e se il documento non è cambiato, invia solo il codice 304, nessun contenuto.

Questi metodi funzionano stabilmente e bene, ma il browser deve farlo comunque su richiesta per ogni script o stile.

Cache intelligente. Versioning

L'approccio generale per il versioning è in poche parole:

1. La versione (o la data di modifica) viene aggiunta a tutti gli script. Ad esempio, http: // sito / mio.js si trasformerà in http: // site / mio.v1.2.js
2. Tutti gli script sono memorizzati nella cache del browser
3. Quando lo script viene aggiornato, la versione cambia in una nuova: http: // site / mio.v2.0.js
4. L'indirizzo è cambiato, quindi il browser richiederà e memorizzerà nuovamente il file nella cache
5. La vecchia versione 1.2 uscirà gradualmente dalla cache

Memorizzazione nella cache

Memorizzazione nella cache- una sorta di mazza che inchioda completamente le richieste al server per i documenti memorizzati nella cache.

Per fare ciò, aggiungi le intestazioni Expires e Cache-Control: max-age.

Ad esempio, per memorizzare nella cache per 365 giorni in PHP:

Intestazione ("Scade:" .gmdate ("D, d M Y H: i: s", ora () + 86400 * 365). "GMT"); intestazione ("Cache-Control: max-age =" + 86400 * 365);

Oppure puoi memorizzare nella cache il contenuto per lungo tempo usando mod_header in Apache:

Dopo aver ricevuto tali intestazioni, il browser memorizzerà a lungo il documento nella cache. Tutte le ulteriori chiamate al documento verranno servite direttamente dalla cache del browser, senza contattare il server.

La maggior parte dei browser (Opera, Internet Explorer 6+, Safari) NON memorizzano nella cache i documenti se nell'indirizzo è presente un punto interrogativo, perché sono considerati dinamici.

Questo è il motivo per cui aggiungiamo la versione al nome del file. Naturalmente, con tali indirizzi devi usare una soluzione come mod_rewrite, lo considereremo più avanti nell'articolo.

P.S Ma Firefox memorizza nella cache gli indirizzi con punti interrogativi ..

Traduzione automatica del nome

Vediamo come modificare le versioni in modo automatico e trasparente senza rinominare i file stessi.

Nome versione -> File

La cosa più semplice è convertire il nome della versione nel nome del file originale.

A livello di Apache, questo può essere fatto con mod_rewrite:

RewriteEngine su RewriteRule ^ / (. * \.) V + \. (Css | js | gif | png | jpg) $ / $ 1 $ 2 [L]

Questa regola elabora tutti i file css/js/gif/png/jpg, eliminando la versione dal nome.

Per esempio:

/images/logo.v2.gif -> /images/logo.gif
/css/style.v1.27.css -> /css/style.css
/javascript/script.v6.js -> /javascript/script.js

Ma oltre a tagliare la versione, devi anche aggiungere intestazioni memorizzate nella cache ai file. Per questo, vengono utilizzate le direttive mod_header:

Header add "Expires" "Mon, 28 Jul 2014 23:30:00 GMT" Header add "Cache-Control" "max-age = 315360000"

E tutti insieme implementa una tale configurazione di apache:

RewriteEngine su # rimuove la versione, e allo stesso tempo imposta la variabile che il file è versionato RewriteRule ^ / (. * \.) V + \. (Css | js | gif | png | jpg) $ / $ 1 $ 2 # file di versione hard-cache Header add "Expires" "Mon, 28 Jul 2014 23:30:00 GMT" env = VERSION_FILE Header add "Cache-Control" "max-age = 315360000" env = VERSION_FILE

Per il funzionamento del modulo mod_rewrite, la RewriteRule deve essere inserita nel file di configurazione principale httpd.conf o nei file ad esso collegati, ma in nessun caso in .htaccess, altrimenti verranno eseguiti prima i comandi Header, prima di variabile installata VERSION_FILE.

Le direttive di intestazione possono essere ovunque, anche in .htaccess - nessuna differenza.

Aggiungi automaticamente una versione al nome del file in una pagina HTML

Come inserire una versione in un nome di script dipende dal tuo sistema di modelli e, in generale, da come aggiungi gli script (stili, ecc.).

Ad esempio, quando si utilizza la data di modifica come versione e il motore del modello Smarty, i collegamenti possono essere impostati in questo modo:

La funzione versione aggiunge una versione:

Funzione smarty_version ($ args) ($ stat = stat ($ GLOBALS ["config"] ["site_root"]. $ Args ["src"]); $ version = $ stat ["mtime"]; echo preg_replace ("! \. (+?) $! "," .v $ versione. \ $ 1 ", $ args [" src "]);)

Risultato a pagina:

Ottimizzazione

Per evitare chiamate stat non necessarie, è possibile memorizzare un array che elenca le versioni correnti in una variabile separata.

$ versioni ["css"] = array ("group.css" => "1.1", "other.css" => "3.0",)

In questo caso, l'HTML viene semplicemente sostituito con la versione corrente dell'array.

È possibile incrociare entrambi gli approcci ed emettere una versione in base alla data di modifica durante lo sviluppo, per la pertinenza, e in produzione, una versione da un array per le prestazioni.

Applicabilità

Questo metodo di memorizzazione nella cache funziona ovunque, inclusi Javascript, CSS, immagini, filmati flash, ecc.

È utile ogni volta che il documento cambia, ma il browser dovrebbe sempre avere la versione corrente corrente.

La memorizzazione nella cache correttamente configurata offre enormi vantaggi in termini di prestazioni, consente di risparmiare larghezza di banda e riduce i costi del server, ma molti siti non implementano correttamente la memorizzazione nella cache, creando una condizione di competizione che causa la mancata sincronizzazione delle risorse interconnesse.

La stragrande maggioranza delle best practice per la memorizzazione nella cache rientra in uno di due modelli:

Modello n. 1: contenuto immutabile e lunga durata massima della cache

Controllo cache: età massima = 31536000

• Il contenuto dell'URL non cambia, quindi...
• Il browser o il CDN possono memorizzare nella cache una risorsa per un anno senza problemi
• Il contenuto memorizzato nella cache di età inferiore all'età massima specificata può essere utilizzato senza consultare il server

Pagina : Ehi, ho bisogno di "/script-v1.js", "/styles-v1.css" e "/cats-v1.jpg" 10:24

cache : Sono vuoto, che ne dici di te Server? 10:24

server : OK, ci sono. A proposito, Cash, dovrebbero essere usati entro un anno, non di più. 10:25

cache : GRAZIE! 10:25

Pagina : Evviva! 10:25

Il giorno successivo

Pagina : Ehi, ho bisogno di "/ script- v2.js "," / stili- v2.css "e" /cats-v1.jpg "08:14

cache : C'è una foto con i gatti, il resto no. Server? 08:14

server : Facile: ecco i nuovi CSS e JS. Ancora una volta, Cash: la loro durata non supera l'anno. 08:15

cache : Super! 08:15

Pagina : Grazie! 08:15

cache : Hmm, non ho usato "/script-v1.js" e "/styles-v1.css" abbastanza a lungo. È ora di eliminarli. 12:32

Usando questo pattern, non cambi mai il contenuto di un URL specifico, cambi l'URL stesso:

Ogni URL ha qualcosa che cambia insieme al contenuto. Può essere un numero di versione, una data di modifica o un hash del contenuto (questa è l'opzione che ho scelto per il mio blog).

La maggior parte dei framework lato server ha strumenti per fare questo tipo di cose con facilità (in Django uso Manifest Static Files Storage); Ci sono anche librerie molto piccole in Node.js che fanno la stessa cosa, come gulp-rev.

Tuttavia, questo modello non è adatto per cose come articoli e post di blog. I loro URL non possono essere versionati e il loro contenuto può cambiare. Seriamente, ho molti errori di grammatica e punteggiatura e devo essere in grado di aggiornare rapidamente il contenuto.

Modello n. 2: contenuto mutabile che viene sempre riconvalidato sul server

Controllo cache: no-cache

• Il contenuto dell'URL cambierà, quindi...
• Qualsiasi versione memorizzata nella cache locale non può essere utilizzata senza specificare un server.

Pagina : Ehi, ho bisogno dei contenuti di "/ about /" e "/sw.js" 11:32

cache : Non posso farci niente. Server? 11:32

server : Ci sono tali. Contanti, tienili con te, ma chiedimelo prima di usarli. 11:33

cache : Si signore! 11:33

Pagina : GRAZIE! 11:33

Il giorno successivo

Pagina : Ehi, ho bisogno di nuovo dei contenuti di "/ about /" e "/sw.js" 09:46

cache : Apetta un minuto. Server, le mie copie sono a posto? Una copia di "/ about /" è di lunedì e "/sw.js" è di ieri. 09:46

server : "/sw.js" non è cambiato ... 09:47

cache : Freddo. Pagina, tieni premuto "/sw.js". 09:47

server : ... ma "/ about /" ho una nuova versione. Cash, tienila, ma come l'ultima volta, ricordati di chiedermelo prima. 09:47

cache : Inteso! 09:47

Pagina : Bene! 09:47

Nota: no-cache non significa "non memorizzare nella cache", significa "controllare" (o riconvalidare) la risorsa memorizzata nella cache dal server. Il no-store ordina al browser di non memorizzare affatto la cache. Inoltre, must-revalidate non significa riconvalida obbligatoria, ma il fatto che la risorsa memorizzata nella cache viene utilizzata solo se è più giovane dell'età massima specificata e solo altrimenti viene riconvalidata. È così che inizia con la memorizzazione nella cache delle parole chiave.

In questo modello, puoi aggiungere ETag (ID versione di tua scelta) o l'intestazione Last-Modified alla risposta. Alla successiva richiesta di contenuto dal client, emette If-None-Match o If-Modified-Since, rispettivamente, consentendo al server di dire "Usa ciò che hai, la tua cache è aggiornata", ovvero restituire HTTP 304.

Se l'invio di ETag / Last-Modified non è possibile, il server invia sempre l'intero contenuto.

Questo modello richiede sempre richieste di rete, quindi non è buono come il primo modello che può fare a meno delle richieste di rete.

Non è raro quando non disponiamo dell'infrastruttura per il primo modello, ma possono sorgere anche problemi con le richieste di rete nel modello 2. Di conseguenza, viene utilizzata un'opzione intermedia: un'età massima breve e un contenuto mutevole. Questo è un cattivo compromesso.

L'uso di max-età con contenuti modificabili è di solito la scelta sbagliata.

E, sfortunatamente, è molto diffuso, le pagine di Github possono essere prese come esempio.

Immaginare:

• / articolo /
• /stili.css
• /script.js

Con un'intestazione lato server:

Controllo cache: da riconvalidare, età massima = 600

• Modifiche al contenuto dell'URL
• Se il browser ha una versione cache fresca di 10 minuti, viene utilizzata senza consultare il server
• Se non esiste tale cache, viene utilizzata una richiesta di rete, possibilmente con If-Modified-Since o If-None-Match

Pagina : Ehi, ho bisogno di "/ articolo /", "/script.js" e "/styles.css" 10:21

cache : Non ho niente come te, Server? 10:21

server : Nessun problema, eccoli. Ma ricorda, Contanti: possono essere utilizzati entro i prossimi 10 minuti. 10:22

cache : C'è! 10:22

Pagina : GRAZIE! 10:22

Pagina : Ehi, ho bisogno di "/ articolo /", "/script.js" e "/styles.css" 10:28

cache : Oops, mi dispiace, ma ho perso "/styles.css", ma ho tutto il resto, prendilo. Server, puoi personalizzare "/styles.css" per me? 10:28

server : Facile, è già cambiato dall'ultima volta che l'hai preso in mano. Puoi usarlo tranquillamente per i prossimi 10 minuti. 10:29

cache : Nessun problema. 10:29

Pagina : Grazie! Ma sembra che qualcosa sia andato storto! Tutto è rotto! Cosa sta succedendo? 10:29

Questo modello ha il diritto di vivere nei test, ma rompe tutto in un progetto reale ed è molto difficile da tracciare. Nell'esempio sopra, il server ha aggiornato HTML, CSS e JS, ma la pagina viene visualizzata con il vecchio HTML e JS dalla cache, a cui è stato aggiunto il CSS aggiornato dal server. La mancata corrispondenza della versione rovina tutto.

Spesso quando si apportano modifiche significative all'HTML, cambiamo sia il CSS per riflettere correttamente la nuova struttura, sia il JavaScript per stare al passo con il contenuto e gli stili. Queste risorse sono tutte indipendenti, ma le intestazioni della cache non possono esprimere questo. Di conseguenza, gli utenti potrebbero avere l'ultima versione di una/due risorse e una vecchia versione del resto.

max-age è impostato in relazione al tempo di risposta, quindi se tutte le risorse vengono trasferite come parte dello stesso indirizzo, scadranno contemporaneamente, ma c'è ancora una piccola possibilità di desincronizzazione. Se disponi di pagine che non includono JavaScript o includono altri stili, le date di scadenza della cache non saranno sincronizzate. E peggio ancora, il browser estrae costantemente il contenuto dalla cache, non sapendo che HTML, CSS e JS sono interdipendenti, quindi può tranquillamente estrarne uno dall'elenco e dimenticare tutto il resto. Considerando tutti questi fattori insieme, dovresti capire che la probabilità di versioni non corrispondenti è piuttosto alta.

Per l'utente, il risultato potrebbe essere un layout di pagina rotto o altri problemi. Da piccoli difetti a contenuti completamente inutilizzabili.

Fortunatamente, gli utenti hanno un'uscita di emergenza ...

L'aggiornamento della pagina a volte salva

Se la pagina viene caricata tramite aggiornamento, i browser eseguono sempre la riconvalida lato server, ignorando l'età massima. Pertanto, se l'utente ha qualcosa di rotto a causa dell'età massima, un semplice aggiornamento della pagina può risolvere tutto. Ma, naturalmente, dopo aver trovato i cucchiai, il sedimento rimarrà ancora e l'atteggiamento nei confronti del tuo sito sarà leggermente diverso.

Un addetto all'assistenza può prolungare la durata di questi bug.

Ad esempio, hai un addetto ai servizi come questo:

Versione const = "2"; self.addEventListener ("install", event => (event.waitUntil (caches.open (`static - $ (version)`) .then (cache => cache.addAll (["/styles.css", "/ script .js "])));)); self.addEventListener ("activate", event => (//… cancella le vecchie cache…)); self.addEventListener ("fetch", event => (event.respondWith (caches.match (event.request) .then (response => risposta || fetch (event.request)));));

Questo addetto ai servizi:

• memorizza nella cache script e stili
• usa la cache in corrispondenza, altrimenti accede alla rete

Se cambiamo il CSS / JS, aumentiamo anche il numero di versione, che attiva un aggiornamento. Tuttavia, poiché addAll accede per primo alla cache, potremmo trovarci in una condizione di competizione a causa dell'età massima e delle versioni CSS e JS non corrispondenti.

Dopo che sono stati memorizzati nella cache, avremo CSS e JS incompatibili fino al prossimo aggiornamento del service worker - e questo è se di nuovo non entriamo in una race condition durante l'aggiornamento.

Puoi saltare la memorizzazione nella cache nel service worker:

Self.addEventListener ("install", event => (event.waitUntil (caches.open (`static - $ (version)`) .then (cache => cache.addAll ([new Request ("/styles.css", (cache: "no-cache")), new Request ("/script.js", (cache: "no-cache"))])));));

Sfortunatamente, le opzioni per la memorizzazione nella cache non sono supportate in Chrome/Opera e sono state appena aggiunte alla build notturna di Firefox, ma puoi farlo da solo:

Self.addEventListener ("install", event => (event.waitUntil (caches.open (`static - $ (version)`) .then (cache => Promise.all (["/styles.css", "/ script .js "] .map (url => (// cache-bust utilizzando una stringa di query casuale return fetch (` $ (url)? $ (Math.random ()) `) .then (response => (// fail on 404, 500 etc if (! response.ok) throw Error ("Non ok"); return cache.put (url, response);))))))));));

In questo esempio, sto svuotando la cache usando un numero casuale, ma puoi andare avanti e aggiungere un hash del contenuto su build (questo è simile a quello che fa sw-precache). Questo è un tipo di implementazione JavaScript del primo modello, ma funziona solo con un service worker, non con browser e CDN.

Service Workers e HTTP Cache funzionano alla grande insieme, non farli litigare!

Come puoi vedere, puoi aggirare gli errori di memorizzazione nella cache nel tuo service worker, ma è meglio affrontare la radice del problema. L'impostazione corretta della memorizzazione nella cache non solo semplifica il lavoro dell'operatore dell'assistenza, ma aiuta anche i browser che non supportano gli operatori dell'assistenza (Safari, IE / Edge) e consente inoltre di ottenere il massimo dalla propria CDN.

Le intestazioni di memorizzazione nella cache corrette possono anche rendere molto più semplice l'aggiornamento del service worker.

Versione const = "23"; self.addEventListener ("install", event => (event.waitUntil (caches.open (`static - $ (version)`) .then (cache => cache.addAll (["/", "/ script-f93bca2c. js "," /styles-a837cb1e.css "," /cats-0e9a2ef4.jpg "])));));

Qui ho memorizzato nella cache la pagina principale con il modello n. 2 (riconvalida lato server) e tutte le altre risorse con il modello n. 1 (contenuto immutabile). Ogni aggiornamento del service worker causerà una richiesta alla pagina root e tutte le altre risorse verranno caricate solo se il loro URL è cambiato. La buona notizia è che risparmia traffico e migliora le prestazioni, sia che tu stia aggiornando da una versione precedente o da una versione molto vecchia.

C'è un vantaggio significativo rispetto all'implementazione nativa qui, in cui l'intero binario viene scaricato anche con una piccola modifica o richiama complessi confronti binari. In questo modo possiamo aggiornare un'applicazione Web di grandi dimensioni con un carico relativamente ridotto.

Gli operatori di servizio funzionano meglio come potenziamento piuttosto che come stampella temporanea, quindi lavora con la cache invece di combatterla.

Se usati con attenzione, i contenuti di età massima e mutevoli possono essere molto buoni.

max-age è molto spesso la scelta sbagliata per i contenuti mutevoli, ma non sempre. Ad esempio, l'articolo originale ha un'età massima di tre minuti. Le race condition non sono un problema in quanto non ci sono dipendenze sulla pagina che utilizzano lo stesso modello di memorizzazione nella cache (CSS, JS e immagini utilizzano il modello n. 1 - contenuto immutabile), tutto il resto non utilizza questo modello.

Questo schema significa che sto scrivendo con calma un articolo popolare e il mio CDN (Cloudflare) può scaricare il carico dal server, se, naturalmente, sono disposto ad aspettare tre minuti affinché l'articolo aggiornato diventi disponibile per gli utenti.

Questo modello dovrebbe essere usato senza fanatismo. Se ho aggiunto una nuova sezione a un articolo e l'ho collegata da un altro articolo, ho creato una dipendenza che deve essere risolta. L'utente può cliccare sul link e ottenere una copia dell'articolo senza la sezione che sta cercando. Se voglio evitare ciò, devo aggiornare l'articolo, eliminare la versione cache dell'articolo da Cloudflare, attendere tre minuti e solo dopo aggiungere il collegamento a un altro articolo. Sì, questo modello richiede cautela.

Se utilizzata correttamente, la memorizzazione nella cache può fornire prestazioni significative e risparmi di larghezza di banda. Passa contenuto immutabile se puoi modificare facilmente l'URL o utilizzare la riconvalida lato server. Mescola contenuti di età massima e modificabili se sei abbastanza audace da assicurarti che il tuo contenuto non abbia dipendenze che potrebbero non essere sincronizzate.

Molte persone pensano che per impostazione predefinita i file CSS collegati tramite link o @import non vengano memorizzati nella cache. ti devo deludere. È proprio il css che viene memorizzato nella cache in un file separato, ed è molto buono, direi eccellente. Queste informazioni sono verificate in modo affidabile sia su 6 che su e su altri browser. Vale la pena notare che molti amati cache di tali file a una velocità completamente selvaggia, per così dire, ottengono il primo posto per questo caso. A proposito, è proprio a questo meccanismo che Opera ha in molti casi una velocità significativa rispetto ad altri browser. Ma farò subito una prenotazione che questo "super" caching in Opera è uno scherzo crudele con esso quando si utilizza la tecnologia AJAX. Mentre altri modificano i mazzi di pulcini quando usano AJAX, Opera prende quello vecchio. Ma questa è una canzone di un argomento separato.

Cache CSS

MA! Ci sono ancora alcuni problemi di dolore in questa direzione. Ciò è dovuto, di norma, a un server Apache configurato in modo errato, che produce intestazioni errate. E con l'aiuto dell'intestazione, puoi controllare la memorizzazione nella cache dei file. Di default, ovviamente, la cache è sempre abilitata. Ma ci sono momenti in cui non è necessario memorizzare nella cache i file. Per questo, i professionisti iniziano a ballare con i tamburelli sulle intestazioni HTTP. Ma se stai leggendo l'intero articolo, sei ancora molto lontano dalla gestione delle intestazioni HTTP. Ti assicuro che nel prossimo futuro non affronterai un compito del genere. Eppure, se sei curioso fino al midollo, allora ti dirò brevemente come succede.

1. invia l'intestazione HTTP al server WEB - dicono, ehi, peperone dolce, dammi il file CSS, altrimenti ho CSS, ma l'ultima volta c'è stato un tale cambiamento.
2. E il server gli dice in risposta, così dolce, non ci sono stati cambiamenti da quel momento, prendi e usa il tuo vecchio CSS con coraggio.
3. Se il CSS è cambiato, il browser aggiorna stupidamente il CSS nella sua cache.

Bene, ora, se non stanco, allora un po' di spazzatura scientifica da qualche tipo di esperimento.

Ti dirò subito che il testo in basso sarà poco compreso dai principianti nel WEB. Fondamentalmente, questo sarà utile per coloro che devono ancora affrontare i compiti di disabilitare e abilitare la cache.

Tutti gli esperimenti sono stati condotti su una base reale e retribuita. Un buon hoster, per così dire, che ti consente di modificare la struttura delle intestazioni HTTP senza dover temere che venga hackerato dall'intestazione HTTP :)

Modalità del browser

Quindi qualsiasi browser ha 2 modalità:

1. Modalità di default, il titolo restituito è:

Cache-Control: no-store, no-cache, must-revalidate, post-check = 0, pre-check = 0

2. Modalità cache abilitata, il titolo restituito è:

Controllo cache: privato, età massima = 10800, pre-controllo = 10800

Successivamente, descrivo il comportamento dei browser

FireFox 3.5 e versioni successive

Nel primo mode memorizza saldamente nella cache i file JavaScript esterni e non controlla nemmeno gli aggiornamenti, a meno che non si forzi l'aggiornamento della pagina. Il CSS viene convalidato da una richiesta di intestazione.

If-Modified-Since: "data corrente" GMT If-None-Match: "proprio codice hash"

Cioè, il CSS viene ricaricato solo se è stato effettivamente aggiornato.

In secondo luogo mode interrompe completamente l'aggiornamento della pagina. Cioè, anche se abbiamo modificato il contenuto visualizzato nella pagina nel database, non lo visualizza, anche se è costretto ad aggiornare, poiché invia una richiesta:

GET / HTTP / 1.1 Host: xxx.com If-Modified-Since: data GMT corrente

e ottiene la risposta:

HTTP / 1.1 304 Non modificato

Internet Explorer 8 (IE8)

Nel primo La modalità Internet Explorer invia richieste If-Modified-Since e If-None-Match sia per JavaScript che per CSS, ovvero carica JavaScript e CSS solo se sono effettivamente aggiornati. Lo stesso vale se la pagina è forzata ad aggiornarsi.

In secondo luogo La modalità Internet Explorer invia anche richieste If-Modified-Since e If-None-Match sia per JavaScript che per CSS. Ma allo stesso tempo, non prova nemmeno a caricare / aggiornare la pagina stessa, cioè non invia nemmeno una richiesta, cioè il tuo js / css verrà aggiornato, ma il modello e il contenuto della pagina no. Anche un aggiornamento forzato della pagina non aiuta ad aggiornare il contenuto.

Opera 10 e precedenti

Nel primo Modalità Opera, nella prima modalità, l'aggiornamento di js e CSS dipende dal valore dell'opzione Verifica immagini nelle impostazioni. Se l'opzione è impostata su Sempre, l'opera invia richieste con If-Modified-Since e If-None-Match per verificare la presenza di aggiornamenti js e css. Se viene impostato un valore, ad esempio 5 ore, allora, di conseguenza, verrà verificato una volta ogni 5 ore o tramite l'aggiornamento forzato della pagina.

In secondo luogo modalità, Opera non verifica la presenza di aggiornamenti js e CSS (non effettua richieste GET) e inoltre non effettua una richiesta GET per la pagina stessa, ovvero non vedremo né aggiornamenti js e css né aggiornamenti del contenuto, come in altre cose e in altri browser. Ma con un aggiornamento forzato, Opera è migliore. A differenza di IE e FF, Opera richiede esplicitamente il contenuto della pagina senza If-Modified-Since e If-None-Match. Le richieste di aggiornamento Js e CSS per l'aggiornamento forzato vengono fornite con If-Modified-Since e If-None-Match.

conclusioni

1. La memorizzazione nella cache, se non si capisce esattamente come funziona nei diversi browser e quali sono le conseguenze, è una cosa piuttosto pericolosa.
2. La memorizzazione nella cache può essere abilitata solo se la pagina viene aggiornata raramente (ovvero se il sito non ha pagine che vengono aggiornate in tempo reale) e anche in questo caso è indispensabile impostare un limite al periodo di limitazione della memorizzazione nella cache (ad esempio , poche ore o un giorno)
3. FireFox si comporta, a mio parere, un po' più intelligente di IE, perché anche con la memorizzazione nella cache disabilitata, non controlla costantemente gli aggiornamenti di JavaScript, il che sembra logico, perché JavaScript viene aggiornato molto raramente.
4. Opera ti consente di controllare in modo flessibile l'aggiornamento di immagini, JavaScript e CSS utilizzando l'impostazione Verifica immagini, che è un vantaggio. Opera si comporta anche meglio di IE e FF con la memorizzazione nella cache abilitata e l'aggiornamento forzato, poiché, lascia che te lo ricordi, Opera aggiorna completamente il contenuto della pagina in questo caso e IE e FF ti lasceranno nella felice ignoranza.

Buona fortuna e siti redditizi.