Quali sono le regole rigide e veloci per il controllo della cache?

Confessione : i siti che mantengo hanno regole diverse per il controllo della cache principalmente in base alla configurazione predefinita del server, seguita dai consigli dei plug-in Page Speed & Y-Slow Firefox e della vista Risorse di rete in Speed Tracer di Google . Il controllo della cache è impostato su privato / pubblico a seconda di ciò che dicono di fare, le intestazioni di ETag / Last-Modified vengono armeggiate solo se Y-Slow suggerisce che c'è qualcosa di sbagliato e Vary-Accept-Encoding sembra necessario quando si decomprimono manualmente i file per Amazon CloudFront.

Quando si legge il materiale sulle diverse opzioni e su ciò che fanno, sembrano esserci informazioni contrastanti, regole per deleghe rotte e configurazioni di culto del carico . Tutte le informazioni ufficiali fornite dagli strumenti di analisi sopra menzionati sono alquanto inaccessibili in quanto trattano individualmente ogni argomento anziché come strategia unificata (quindi non vi è alcun riferimento incrociato di tecniche).

Ad esempio, sembra che non abbia senso che gli strumenti di analisi della velocità classifichino un sito con ETag uguale a un sito senza di essi se sono pensati per aiutare con la memorizzazione nella cache.

Quali sono le regole rigide e veloci per una strategia di controllo cache indipendente dalla piattaforma?

MODIFICARE:

Un collegamento attraverso l'articolo di Jeff Atwood spiega la memorizzazione nella cache in modo superbo.

Per la cronaca, ecco le regole rigide e veloci:

Se il file è compresso utilizzando GZIP, ecc ., Utilizzare "cache-control: private" poiché un proxy può restituire la versione compressa a un client che non lo supporta (la cache del browser conterrà i file contrassegnati in questo modo). Ricorda anche di includere un "Vary: Accept-Encoding" per dire che è comprimibile.

Usa Last-Modified in congiunzione con ETag : l'utilizzo della cinghia e delle parentesi graffe fornisce entrambi i validatori, mentre ETag si basa sul contenuto del file anziché sul tempo di modifica da solo, usando entrambe le copertine su tutte le basi. NOTA: il PageTest di AOL ha un approccio carta bianca contro ETag per qualche motivo. Se si utilizza Apache su più di un server per ospitare lo stesso contenuto, rimuovere l'inode implicitamente dichiarato da ETags escludendolo dalla direttiva FileETag (ad esempio "Dimensione file MTETag") a meno che non si utilizzi realmente lo stesso filesystem live.

Usa "cache-control: public" dove puoi - questo significa che i server proxy (e la cache del browser) restituiranno i tuoi contenuti anche se il resto della pagina necessita dell'autenticazione HTTP, ecc.

cache-control

— Metalshark
fonte

Risposte:

Innanzitutto, non sbarazzarsi dell'ETag come dice Yahoo, a meno che non si stia utilizzando una server farm / cluster. Finché lo stesso file restituisce sempre lo stesso ETag quando non è cambiato, allora è una direttiva molto utile.

Per quanto riguarda le altre intestazioni, le migliori pratiche di Yahoo suggeriscono di impostare Expiresun'intestazione molto futura per i file statici, da utilizzare Cache-Controlper i contenuti dinamici. Comunque Cache-controlva benissimo per il contenuto statico (praticamente nessuna differenza tra loro).

Quando si modificano i file statici memorizzati nella cache, è necessario modificare il nome file o aggiungere un parametro univoco alla fine, ad es example.com/styles.css?v=2. La modifica del nome file effettivo è preferibile, come indicato nei commenti seguenti.

Per inciso, è possibile modificare le regole YSlow a proprio piacimento, per rimuovere la regola Etag e aggiungere il proprio dominio come CDN. Questo articolo è anche una buona lettura: i problemi di Yahoo non sono i tuoi problemi

— DisgruntledGoat
fonte

L'ETag aveva senso in Apache facendo "FileETag MTime Size" invece del valore predefinito che include l'inode (per FS così non affidabile) su Y-Slow. Tuttavia, le raccomandazioni sulle migliori pratiche di Yahoo sono un po 'confuse rispetto a quelle di Page Speed. Ad esempio, dice di usare Cache-Control solo su pagine dinamiche (come anche tu suggerisci), ma Google suggerisce di usare Cache-Control: pubblico su CSS statico e Cache-Control: privato su file Amazon Cloudfront con compressione manuale.

— Metalshark,

È difficile sapere cosa dare di quel consiglio ai delegati. Google dice semplicemente "Alcuni proxy pubblici hanno bug ..." ma non dice quanto sia prevalente. Si consiglia di impostare l'intestazione Vary: Accept-Encoding, vedere la parte inferiore di code.google.com/speed/page-speed/docs/caching.html

— scontentoGoat

L'aggiunta di un parametro di query disabilita la memorizzazione nella cache di quel file completamente in alcuni browser. Quindi potresti voler seguire l'approccio "cambia il nome del file", ad esempioexample.com/style_v2.css

— Evgeny

@Evgeny: quali browser? L'ho già sentito prima, ma non ho mai visto un browser che in realtà non memorizza nella cache il file (specialmente se hai le intestazioni giuste).

— SconcertatoGoat

@DisgruntledGoat in realtà, dopo alcuni scavi sembra che si tratti di una reliquia dell'era http / 1.0 in cui faceva parte delle specifiche che effettivamente l'agente utente non deve memorizzare nella cache gli asset con stringhe di query. D'altra parte, code.google.com/speed/page-speed/docs/caching.html afferma che sono i proxy (calamari <3.0) che non memorizzeranno nella cache gli asset e quindi l'uso delle stringhe di query per il busting della cache è sconsigliato.

— Evgeny

Modifica le intestazioni di richiesta delle tue risorse per utilizzare la memorizzazione nella cache Per la maggior parte delle persone, la modalità di memorizzazione nella cache ebable consiste nell'aggiungere del codice a un file chiamato .htaccess sul tuo host / server web.

Questo significa andare al file manager (o ovunque tu vada per aggiungere o caricare file) sul tuo host web.

Il file .htaccess controlla molte cose importanti per il tuo sito. Se non hai familiarità con il file .htaccess, leggi il mio articolo di lavoro su .htaccess per sapere come fare prima di modificarlo.

Il codice seguente indica ai browser cosa memorizzare nella cache e per quanto tempo "ricordarlo". Dovrebbe essere aggiunto all'inizio del file .htaccess.

## EXPIRES CACHING ##
<IfModule mod_expires.c>
ExpiresActive On
ExpiresByType image/jpg "access 1 year"
ExpiresByType image/jpeg "access 1 year"
ExpiresByType image/gif "access 1 year"
ExpiresByType image/png "access 1 year"
ExpiresByType text/css "access 1 month"
ExpiresByType text/html "access 1 month"
ExpiresByType application/pdf "access 1 month"
ExpiresByType text/x-javascript "access 1 month"
ExpiresByType application/x-shockwave-flash "access 1 month"
ExpiresByType image/x-icon "access 1 year"
ExpiresDefault "access 1 month"
</IfModule>
## EXPIRES CACHING ##

Salvare il file .htaccess e quindi aggiornare la pagina Web.

Fonte:
https://varvy.com/pagespeed/leverage-browser-caching.html

— Nomib Nomib
fonte

Quasi ogni esempio di ExpiresByTypedirettive che vedo include il tipo mime text/x-javascript: il tuo server risponde davvero con questo tipo di contenuto ?! (Un esempio di copia cieca / incolla IMO.)

— MrWhite,