Ukládání stylu do mezipaměti. Jak odstranit soubory css a js z mezipaměti. Obnovení stránky někdy ušetří

Zahrnutím externích CSS a Javascriptu chceme omezit zbytečné HTTP požadavky na minimum.

Za tímto účelem jsou soubory .js a .css poskytovány s hlavičkami, které poskytují spolehlivé ukládání do mezipaměti.

Ale co když se některý z těchto souborů během vývoje změní? Všichni uživatelé mají v mezipaměti starou verzi - dokud nebude mezipaměť zastaralá, bude přicházet spousta stížností na nefunkční integraci serverové a klientské části.

Správný způsob ukládání do mezipaměti a verzování tento problém zcela odstraňuje a zajišťuje spolehlivou a transparentní synchronizaci verzí stylu / skriptu.

Snadné ukládání do mezipaměti ETag

Nejjednodušší způsob ukládání statických zdrojů do mezipaměti je pomocí ETag.

Stačí povolit příslušné nastavení serveru (pro Apache je ve výchozím nastavení povoleno) - a každému souboru bude v záhlaví přidělen ETag - hash, který závisí na době aktualizace, velikosti souboru a (na souborových systémech založených na inodech ) inode.

Prohlížeč uloží takový soubor do mezipaměti a na další požadavky specifikuje záhlaví If-None-Match z ETag dokumentu uloženého v mezipaměti. Po přijetí takové hlavičky může server odpovědět kódem 304 - a poté bude dokument odebrán z mezipaměti.

Vypadá to takto:

První požadavek na server (vyčištění mezipaměti) GET /misc/pack.js HTTP / 1.1 Host: web

Obecně platí, že prohlížeč obvykle přidává spoustu záhlaví, jako je User-Agent, Accept atd. Pro stručnost jsou střižené.

Odpověď serveru Server odešle jako odpověď dokument s kódem 200 a ETag: HTTP / 1.x 200 OK Kódování obsahu: gzip Typ obsahu: text / javascript; charset = utf-8 Etag: "3272221997" Accept-Ranges: bytes Content-Length: 23321 Date: Fri, 02 May 2008 17:22:46 GMT Server: lighttpd Další požadavek prohlížeče Na další požadavek prohlížeč přidá If-None-Match: (uložený ETag): GET /misc/pack.js HTTP / 1.1 Host: site If-None-Match: "453700005" Odpověď serveru Server hledá - ano, dokument se nezměnil. To znamená, že můžete vydat kód 304 a dokument již neposílat. HTTP / 1.x 304 Neupraveno Kódování obsahu: gzip Etag: "453700005" Typ obsahu: text / javascript; charset = utf-8 Accept-Ranges: bytes Datum: Út, 15. dubna 2008 10:17:11 GMT

Případně, pokud se dokument změnil, server jednoduše odešle 200 s novým ETag.

Balíček Last-Modified + If-Modified-Since funguje podobným způsobem:

server odešle datum poslední změny v hlavičce Last-Modified (místo ETag)
prohlížeč uloží dokument do mezipaměti a při příštím požadavku na stejný dokument odešle datum verze uložené v mezipaměti v záhlaví If-Modified-Since (místo If-None-Match)
server ověří data, a pokud se dokument nezměnil, odešle pouze kód 304, žádný obsah.

Tyto metody fungují stabilně a dobře, ale prohlížeč to stejně musí udělat na vyžádání pro každý skript nebo styl.

Inteligentní ukládání do mezipaměti. Verzování

Obecný přístup k verzování je v kostce:

Verze (nebo datum úpravy) je přidána do všech skriptů. Například http: // site / my.js změní se na http: // web / my.v1.2.js
Všechny skripty jsou v prohlížeči pevně ukládány do mezipaměti
Po aktualizaci skriptu se verze změní na novou: http: // site / my.v2.0.js
Adresa se změnila, takže prohlížeč si soubor znovu vyžádá a uloží do mezipaměti
Stará verze 1.2 bude postupně vypadávat z mezipaměti

Tvrdé ukládání do mezipaměti

Tvrdé ukládání do mezipaměti- druh perlíku, který zcela přibije požadavky serveru na dokumenty uložené v mezipaměti.

Chcete-li to provést, stačí přidat záhlaví Expires a Cache-Control: max-age.

Chcete-li například ukládat do mezipaměti po dobu 365 dní v PHP:

Záhlaví ("Platnost vyprší:" .gmdate ("D, d M Y H: i: s", čas () + 86400 * 365). "GMT"); záhlaví ("Cache-Control: max-age =" + 86400 * 365);

Nebo můžete obsah ukládat do mezipaměti po dlouhou dobu pomocí mod_header v Apache:

Po obdržení takových záhlaví bude prohlížeč dokument na dlouhou dobu pevně ukládat do mezipaměti. Všechna další volání dokumentu budou obsluhována přímo z mezipaměti prohlížeče, bez kontaktování serveru.

Většina prohlížečů (Opera, Internet Explorer 6+, Safari) NEKACHUJE dokumenty, pokud je v adrese otazník, protože jsou považovány za dynamické.

To je důvod, proč přidáváme verzi do názvu souboru. Samozřejmě, s takovými adresami musíte použít řešení jako mod_rewrite, o tom budeme uvažovat později v článku.

P.S. Ale Firefox ukládá adresy s otazníky do mezipaměti.

Automatický překlad jmen

Podívejme se, jak automaticky a transparentně měnit verze bez přejmenování samotných souborů.

Název verze -> Soubor

Nejjednodušší je převést název verze na původní název souboru.

Na úrovni Apache to lze provést pomocí mod_rewrite:

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

Toto pravidlo zpracuje všechny soubory css / js / gif / png / jpg a odstraní verzi z názvu.

Například:

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

Ale kromě oříznutí verze musíte do souborů přidat také hlavičky uložené v mezipaměti. K tomu se používají direktivy mod_header:

Přidat do záhlaví "Platnost vyprší" "Po, 28. července 2014 23:30:00 GMT" Přidat do záhlaví "Cache-Control" "max-age = 315360000"

A dohromady to implementuje takovou konfiguraci Apache:

RewriteEngine na # odstraní verzi a zároveň nastaví proměnnou, že soubor má verzi RewriteRule ^ / (. * \.) V + \. (Css | js | gif | png | jpg) $ / $ 1 $ 2 # souborů verze pevné mezipaměti Přidat záhlaví "Platnost vyprší" "Po, 28. července 2014 23:30:00 GMT" env = VERSIONED_FILE Přidat záhlaví "Cache-Control" "max-age = 315360000" env = VERSIONED_FILE

Vzhledem k tomu, jak modul mod_rewrite funguje, musí být RewriteRule umístěno v hlavním konfiguračním souboru httpd.conf nebo v souborech k němu připojených, ale v žádném případě v .htaccess, jinak budou nejprve spuštěny příkazy Header, než bude nainstalovaná proměnná VERSIONED_FILE.

Direktivy záhlaví mohou být kdekoli, dokonce i v .htaccess - žádný rozdíl.

Automaticky přidat verzi k názvu souboru na stránce HTML

Jak vložit verzi do názvu skriptu závisí na vašem systému šablon a obecně na tom, jak přidáváte skripty (styly atd.).

Například při použití data úpravy jako verze a nástroje Smarty šablony lze odkazy nastavit takto:

Funkce verze přidá verzi:

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

Výsledek na stránce:

Optimalizace

Abyste se vyhnuli zbytečným voláním statistik, můžete pole se seznamem aktuálních verzí uložit do samostatné proměnné.

$ verze ["css"] = pole ("skupina.css" => "1.1", "jine.css" => "3.0")

V tomto případě je HTML jednoduše nahrazeno aktuální verzí z pole.

Můžete zkřížit oba přístupy a vydat verzi podle data modifikace během vývoje - pro relevanci a ve výrobě - verzi z pole pro výkon.

Použitelnost

Tato metoda ukládání do mezipaměti funguje všude, včetně Javascriptu, CSS, obrázků, flash filmů atd.

Je to užitečné při každé změně dokumentu, ale prohlížeč by měl mít vždy aktuální aktuální verzi.

Správně nakonfigurované ukládání do mezipaměti poskytuje obrovské zvýšení výkonu, šetří šířku pásma a snižuje náklady na server, ale mnoho webů neimplementuje ukládání do mezipaměti dobře, což způsobuje konflikt, který způsobuje, že se vzájemně propojené zdroje nesynchronizují.

Naprostá většina osvědčených postupů ukládání do mezipaměti spadá do jednoho ze dvou vzorů:

Vzor č. 1: neměnný obsah a dlouhé maximální stáří mezipaměti

Cache-Control: max-age = 31536000

Obsah na URL se nemění, proto...
Prohlížeč nebo CDN dokáže ukládat zdroj do mezipaměti bez problémů po dobu jednoho roku
Obsah mezipaměti, který je mladší než zadaný maximální věk, lze použít bez konzultace se serverem

Strana : Ahoj, potřebuji "/script-v1.js", "/styles-v1.css" a "/cats-v1.jpg" 10:24

Mezipaměti : Jsem prázdný, co ty Server? 10:24

server : Dobře, tady jsou. Mimochodem, Cash, měly by být použity do jednoho roku, ne více. 10:25

Mezipaměti : DÍKY! 10:25

Strana : Hurá! 10:25

Další den

Strana : Hej, potřebuji "/ skript- v2.js "," / styly- v2.css "and" /cats-v1.jpg "08:14

Mezipaměti : Je tam obrázek s kočkami, zbytek ne. server? 08:14

server : Snadno – zde jsou nové CSS a JS. Ještě jednou Cash: jejich trvanlivost není delší než rok. 08:15

Mezipaměti : Super! 08:15

Strana : Dík! 08:15

Mezipaměti : Hmm, nepoužil jsem "/script-v1.js" & "/styles-v1.css" dostatečně dlouho. Je čas je smazat. 12:32

Pomocí tohoto vzoru nikdy nezměníte obsah konkrétní adresy URL, změníte adresu URL samotnou:

Každá adresa URL má něco, co se mění spolu s obsahem. Může to být číslo verze, upravené datum nebo hash obsahu (toto je možnost, kterou jsem zvolil pro svůj blog).

Většina serverových frameworků má nástroje pro snadné provádění tohoto druhu věcí (v Django používám Manifest Static Files Storage); V Node.js jsou také velmi malé knihovny, které dělají totéž, jako gulp-rev.

Tento vzor však není vhodný pro věci, jako jsou články a blogové příspěvky. Jejich adresy URL nelze upravovat a jejich obsah se může měnit. Vážně, mám spoustu gramatických a interpunkčních chyb a potřebuji být schopen rychle aktualizovat obsah.

Vzor č. 2: měnitelný obsah, který je na serveru vždy znovu ověřen

Cache-Control: no-cache

Obsah adresy URL se změní, takže...
Žádnou místní verzi uloženou v mezipaměti nelze použít bez určení serveru.

Strana : Ahoj, potřebuji obsah "/ about /" a "/sw.js" 11:32

Mezipaměti : Nemůžu si pomoct. server? 11:32

server : Existují takové. Hotovost, mějte je u sebe, ale před použitím se mě zeptejte. 11:33

Mezipaměti : Ano pane! 11:33

Strana : DÍKY! 11:33

Další den

Strana : Ahoj, potřebuji znovu obsah "/ about /" a "/sw.js" 09:46

Mezipaměti : Počkej chvíli. Server, jsou moje kopie v pořádku? Kopie "/ about /" je z pondělí a "/sw.js" je ze včerejška. 09:46

server : "/sw.js" se nezměnilo ... 09:47

Mezipaměti : Chladný. Stránka, podržte "/sw.js". 09:47

server : ... ale "/ o /" mám novou verzi. Hotovost, drž ji, ale jako minule se mě nejdřív zeptej. 09:47

Mezipaměti : Rozumím! 09:47

Strana : Pokuta! 09:47

Poznámka: no-cache neznamená „neukládat do mezipaměti“, znamená to „zkontrolovat“ (nebo znovu ověřit) uložený zdroj ze serveru. No-store nařídí prohlížeči, aby vůbec neukládal do mezipaměti. Také must-revalidate neznamená povinné opětovné ověření, ale skutečnost, že prostředek uložený v mezipaměti se použije pouze v případě, že je mladší než zadaný maximální věk, a pouze jinak se znovu ověří. Tak to začíná s ukládáním klíčových slov do mezipaměti.

V tomto vzoru můžete k odpovědi přidat ETag (ID verze dle vašeho výběru) nebo hlavičku Last-Modified. Při dalším požadavku na obsah od klienta vydá výstup If-None-Match nebo If-Modified-Since, což umožňuje serveru říci „Použijte, co máte, vaše mezipaměť je aktuální“, což znamená vrátit HTTP 304.

Pokud odeslání ETag / Last-Modified není možné, server vždy odešle celý obsah.

Tento vzor vždy vyžaduje síťové požadavky, takže není tak dobrý jako první vzor, který se obejde bez síťových požadavků.

Není neobvyklé, když nemáme infrastrukturu pro první vzor, ale mohou nastat i problémy se síťovými požadavky ve vzoru 2. V důsledku toho se používá přechodná možnost: krátký maximální věk a proměnlivý obsah. To je špatný kompromis.

Použití max-age s proměnlivým obsahem je obvykle špatná volba.

A bohužel je to rozšířené, jako příklad lze vzít stránky Github.

Představte si:

/ článek /
/styles.css
/script.js

S hlavičkou na straně serveru:

Kontrola mezipaměti: nutno znovu ověřit, maximální věk = 600

Obsah URL se změní
Pokud má prohlížeč verzi v mezipaměti čerstvých 10 minut, použije se bez konzultace se serverem
Pokud taková mezipaměť neexistuje, použije se síťový požadavek, pravděpodobně s If-Modified-Since nebo If-None-Match

Strana : Ahoj, potřebuji "/ article /", "/script.js" a "/styles.css" 10:21

Mezipaměti : Nemám nic jako ty, server? 10:21

server : Žádný problém, tady jsou. Ale pamatujte, hotovost: mohou být použity během následujících 10 minut. 10:22

Mezipaměti : Tady je! 10:22

Strana : DÍKY! 10:22

Strana : Ahoj, potřebuji znovu "/ article /", "/script.js" a "/styles.css" 10:28

Mezipaměti : Jejda, omlouvám se, ale ztratil jsem "/styles.css", ale všechno ostatní mám, vezměte si to. Server, můžete mi přizpůsobit "/styles.css"? 10:28

server : Snadno, už se to změnilo od doby, kdy jsi to vzal naposledy. Můžete jej bezpečně používat dalších 10 minut. 10:29

Mezipaměti : Žádný problém. 10:29

Strana : Dík! Ale vypadá to, že se něco pokazilo! Všechno je rozbité! Co se děje? 10:29

Tento vzorec má právo žít v testování, ale ve skutečném projektu porušuje vše a je velmi obtížné jej sledovat. Ve výše uvedeném příkladu server aktualizoval HTML, CSS a JS, ale stránka se zobrazuje se starým HTML a JS z mezipaměti, do které byly přidány aktualizované CSS ze serveru. Nesoulad verzí vše zkazí.

Při provádění významných změn v HTML často měníme jak CSS, aby správně odrážely novou strukturu, tak JavaScript, abychom udrželi krok s obsahem a styly. Všechny tyto prostředky jsou nezávislé, ale hlavičky mezipaměti to nemohou vyjádřit. V důsledku toho mohou uživatelé mít nejnovější verzi jednoho / dvou zdrojů a starou verzi zbytku.

max-age je nastaven relativně k době odezvy, takže pokud jsou všechny zdroje přeneseny jako součást stejné adresy, jejich platnost vyprší ve stejnou dobu, ale stále existuje malá šance na desynchronizaci. Pokud máte stránky, které neobsahují JavaScript nebo obsahují jiné styly, data vypršení jejich mezipaměti nebudou synchronizována. A co je horší, prohlížeč neustále vytahuje obsah z mezipaměti, aniž by věděl, že HTML, CSS a JS jsou na sobě závislé, takže může vesele vytáhnout jeden ze seznamu a zapomenout na všechno ostatní. Když vezmete v úvahu všechny tyto faktory dohromady, měli byste pochopit, že pravděpodobnost neshodných verzí je poměrně vysoká.

Pro uživatele může být výsledkem nefunkční rozvržení stránky nebo jiné problémy. Od drobných závad až po zcela nepoužitelný obsah.

Naštěstí mají uživatelé nouzový východ...

Obnovení stránky někdy ušetří

Pokud se stránka načte obnovením, prohlížeče vždy provedou revalidaci na straně serveru a ignorují maximální věk. Pokud má tedy uživatel něco rozbitého kvůli max-age, může vše napravit jednoduché obnovení stránky. Ale samozřejmě po nalezení lžiček sediment stále zůstane a postoj k vašemu webu bude poněkud odlišný.

Servisní pracovník může životnost těchto chyb prodloužit.

Máte například servisního pracovníka, jako je tento:

Const verze = "2"; self.addEventListener ("install", event => (event.waitUntil (caches.open (`static - $ (version)`) .then (cache => cache.addAll (["/styles.css", "/ skript .js "])));)); self.addEventListener ("aktivovat", událost => (//… smazat staré mezipaměti…)); self.addEventListener ("načíst", událost => (event.respondWith (caches.match (event.request) .then (response => odpověď || načíst (event.request)));));

Tento servisní pracovník:

ukládá skript a styly do mezipaměti
používá mezipaměť při shodě, jinak přistupuje k síti

Pokud změníme CSS / JS, zvýšíme také číslo verze, což spustí aktualizaci. Protože však addAll přistupuje k mezipaměti jako první, můžeme skončit ve sporu kvůli maximálnímu věku a neshodám s verzemi CSS a JS.

Po jejich uložení do mezipaměti budeme mít nekompatibilní CSS & JS až do další aktualizace servisního pracovníka – a to v případě, že se během aktualizace znovu nedostaneme do race condition.

Ukládání do mezipaměti můžete přeskočit v servisním pracovníkovi:

Self.addEventListener ("install", událost => (event.waitUntil (caches.open (`static - $ (verze)`) .then (cache => cache.addAll ([nový požadavek ("/ styles.css", (cache: "no-cache")), nový požadavek ("/ script.js", (cache: "no-cache"))])));));

Možnosti ukládání do mezipaměti bohužel nejsou podporovány v prohlížeči Chrome / Opera a byly právě přidány do nočního sestavení Firefoxu, ale můžete to udělat sami:

Self.addEventListener ("install", event => (event.waitUntil (caches.open (`static - $ (version)`) .then (cache => Promise.all (["/styles.css", "/ skript .js "] .map (url => (// výpadek mezipaměti pomocí náhodného zpětného načtení řetězce dotazu (` $ (url)? $ (Math.random ()) `) .then (response => (// selže na 404, 500 atd. if (! response.ok) throw Error ("Not ok"); return cache.put (url, response);))))))));));

V tomto příkladu vyprázdním mezipaměť pomocí náhodného čísla, ale můžete pokračovat a přidat hash obsahu na sestavení (toto je podobné tomu, co dělá sw-precache). Toto je druh JavaScriptové implementace prvního vzoru, ale funguje pouze se servisním pracovníkem, nikoli s prohlížeči a CDN.

Service Workers a HTTP Cache skvěle spolupracují, nenuťte je bojovat!

Jak vidíte, chyby ukládání do mezipaměti můžete obejít ve svém servisním pracovníkovi, ale je lepší vyřešit kořen problému. Správné nastavení ukládání do mezipaměti nejen usnadňuje práci servisního pracovníka, ale také pomáhá prohlížečům, které nepodporují servisní pracovníky (Safari, IE / Edge) a také vám umožňuje vytěžit maximum z vašeho CDN.

Správné hlavičky mezipaměti mohou také výrazně usnadnit aktualizaci servisního pracovníka.

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

Zde jsem uložil do mezipaměti kořenovou stránku se vzorem # 2 (revalidace na straně serveru) a všechny ostatní zdroje se vzorem # 1 (neměnný obsah). Každá aktualizace servisního pracovníka způsobí požadavek na kořenovou stránku a všechny ostatní zdroje budou načteny pouze v případě, že se změnila jejich adresa URL. Dobrou zprávou je, že šetří provoz a zlepšuje výkon, ať už upgradujete z předchozí nebo velmi staré verze.

Zde je značná výhoda oproti nativní implementaci, kdy se i s malou změnou stáhne celá binárka, případně vyvolá složitá binární porovnávání. Můžeme tak aktualizovat velkou webovou aplikaci s relativně malým zatížením.

Servisní pracovníci fungují lépe jako vylepšení než dočasná berlička, takže místo boje s vyrovnávací pamětí pracujte.

Při pečlivém použití může být maximální věk a měnitelný obsah velmi dobrý.

max-age je velmi často špatnou volbou pro měnitelný obsah, ale ne vždy. Například původní článek má maximální stáří tři minuty. Závodní podmínky nepředstavují problém, protože neexistují žádné závislosti na stránce používající stejný vzor ukládání do mezipaměti (CSS, JS a obrázky používají vzor # 1 - neměnný obsah), vše ostatní tento vzor nepoužívá.

Tento vzorec znamená, že klidně píšu populární článek a moje CDN (Cloudflare) může ubrat zatížení serveru, pokud jsem samozřejmě ochoten počkat tři minuty, než bude aktualizovaný článek dostupný uživatelům.

Tento vzor by měl být používán bez fanatismu. Pokud jsem do článku přidal novou sekci a odkazoval na ni z jiného článku, vytvořil jsem závislost, kterou je třeba vyřešit. Uživatel může kliknout na odkaz a získat kopii článku bez sekce, kterou hledá. Pokud se tomu chci vyhnout, musím článek aktualizovat, smazat cacheovanou verzi článku z Cloudflare, počkat tři minuty a teprve potom přidat odkaz na další článek. Ano, tento vzor vyžaduje opatrnost.

Při správném použití může ukládání do mezipaměti poskytnout významný výkon a úsporu šířky pásma. Předejte neměnný obsah, pokud můžete snadno změnit adresu URL nebo použít revalidaci na straně serveru. Smíchejte maximální věk a měnitelný obsah, pokud jste dostatečně odvážní, abyste se ujistili, že váš obsah nemá žádné závislosti, které by mohly být nesynchronizované.

Mnoho lidí si myslí, že ve výchozím nastavení se soubory CSS připojené přes odkaz nebo @import neukládají do mezipaměti. musím tě zklamat. Právě css se ukládá do mezipaměti v samostatném souboru a je velmi dobrý, řekl bych vynikající. Tyto informace jsou spolehlivě ověřeny jak na 6 a vyšší, tak na jiných prohlížečích. Stojí za zmínku, že mnoho milovaných mezipaměti takové soubory takříkajíc naprosto divokou rychlostí dostává v tomto případě první místo. Mimochodem, právě na tento mechanismus má Opera v mnoha případech značnou rychlost ve srovnání s jinými prohlížeči. Hned si ale udělám výhradu, že toto „super“ cachování v Opeře je při použití technologie AJAX krutý vtip. Zatímco jiní při používání AJAX vylaďují chicky shluky, Opera bere ten starý. Ale to je píseň na samostatné téma.

CSS mezipaměť

ALE! V tomto směru stále existují určité problémy se smutkem. To je zpravidla způsobeno nesprávně nakonfigurovaným serverem Apache, který vytváří nesprávné hlavičky. A pomocí hlavičky můžete ovládat ukládání souborů do mezipaměti. Ve výchozím nastavení je mezipaměť samozřejmě vždy povolena. Ale jsou chvíle, kdy nepotřebujete ukládat soubory do mezipaměti. Za to profíci začnou tančit s tamburínama o HTTP hlavičkách. Ale pokud čtete celý tento článek, pak jste stále velmi daleko od správy HTTP hlaviček. Ujišťuji vás, že v blízké budoucnosti vás takový úkol nečeká. A přesto, pokud jste zvědaví až do morku kostí, stručně vám řeknu, jak se to stane.

posílá HTTP hlavičku na WEB server - řeknou hej, papriko, dej mi ten CSS soubor, jinak mám CSS, ale naposledy tam byla taková změna.
A server mu odpověděl, tak milé, od té chvíle nedošlo k žádným změnám, vezměte a směle používejte své staré CSS.
Pokud se CSS změnilo, prohlížeč hloupě aktualizuje CSS ve své mezipaměti.

No a teď, když ne unavený, tak trochu vědeckého odpadu z nějakého experimentu.

Hned vám řeknu, že spodní text bude pro začátečníky ve WEBu špatně srozumitelný. V zásadě to bude užitečné pro ty, kteří se stále potýkají s úkoly deaktivace a povolení mezipaměti.

Všechny experimenty byly prováděny na skutečném, placeném základě. Dobrý hostitel, abych tak řekl, který vám umožní změnit strukturu HTTP hlaviček, aniž byste museli paranoiu, že bude hacknut HTTP hlavičkou :)

Režimy prohlížeče

Takže každý prohlížeč má 2 režimy:

1. Výchozí režim, vrácený název je:

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

2. Režim povoleno ukládání do mezipaměti, vrácený název je:

Kontrola mezipaměti: soukromá, maximální věk = 10 800, předběžná kontrola = 10 800

Dále popisuji chování prohlížečů

FireFox 3.5 a vyšší

Zaprvé režim pevně ukládá externí soubory JavaScriptu a ani nekontroluje aktualizace, pokud nevynutíte obnovení stránky. CSS je ověřeno žádostí o hlavičku.

If-Modified-Since: "aktuální datum" GMT If-None-Match: "vlastní hash kód"

To znamená, že CSS se znovu načte, pouze pokud bylo skutečně aktualizováno.

Za druhé režim přestane obnovovat stránku úplně. To znamená, že i když jsme změnili obsah zobrazený na stránce v databázi, nezobrazuje to, i když je nucena se aktualizovat, protože odešle požadavek:

GET / HTTP / 1.1 Host: xxx.com If-Modified-Since: aktuální datum GMT

a dostane odpověď:

HTTP / 1.1 304 nezměněno

Internet Explorer 8 (IE8)

Zaprvé Režim Internet Explorer odesílá požadavky If-Modified-Since & If-None-Match pro JavaScript i css, to znamená, že načte JavaScript a CSS pouze v případě, že jsou skutečně aktualizovány. Totéž platí, pokud je stránka nucena aktualizovat.

Za druhé Režim Internet Explorer také odesílá požadavky If-Modified-Since & If-None-Match pro JavaScript i css. Ale zároveň se ani nepokouší načíst / aktualizovat stránku samotnou, to znamená, že ani nepošle požadavek, to znamená, že vaše js / css bude aktualizováno, ale šablona a obsah stránky ne. K aktualizaci obsahu nepomůže ani vynucené obnovení stránky.

Opera 10 a starší

Zaprvé Režim Opera, v prvním režimu závisí aktualizace js & CSS na hodnotě volby Check images v nastavení. Pokud je možnost nastavena na Vždy, opera odešle požadavky s If-Modified-Since & If-None-Match pro kontrolu aktualizací js a css. Pokud je nastavena hodnota např. 5 hodin, pak bude kontrolována každých 5 hodin nebo vynuceným obnovením stránky.

Za druhé režimu, Opera nekontroluje aktualizace js a CSS (nevytváří požadavky GET) a také nevytváří požadavek GET pro samotnou stránku, to znamená, že neuvidíme aktualizace js a css ani aktualizace obsahu, jako v jiné věci a v jiných prohlížečích. Ale s vynucenou aktualizací je Opera lepší. Na rozdíl od IE a FF Opera výslovně požaduje obsah stránky bez If-Modified-Since a If-None-Match. Požadavky na aktualizaci Js a CSS pro vynucenou aktualizaci přicházejí s If-Modified-Since & If-None-Match.

závěry

Ukládání do mezipaměti, pokud přesně nerozumíte tomu, jak to v různých prohlížečích funguje a jaké to má důsledky, je poměrně nebezpečná věc.
Ukládání do mezipaměti lze povolit pouze v případě, že je stránka aktualizována zřídka (tj. pokud web nemá stránky, které se aktualizují v reálném čase), a i v tomto případě je nutné nastavit limit na dobu omezení ukládání do mezipaměti (např. , několik hodin nebo den)
FireFox se chová dle mého názoru o něco chytřeji než IE, protože i s vypnutým cachováním neustále nekontroluje aktualizace JavaScriptu, což vypadá logicky, protože JavaScript se aktualizuje velmi zřídka.
Opera umožňuje flexibilně ovládat aktualizaci obrázků, JavaScriptu a CSS pomocí nastavení Kontrola obrázků, což je plus. Opera se také chová lépe než IE a FF s povoleným ukládáním do mezipaměti a vynuceným obnovením, protože, dovolte mi, abych vám připomněl, Opera v tomto případě zcela obnovuje obsah stránky a IE a FF vás nechá v šťastné nevědomosti.

Hodně štěstí a ziskové stránky.