Predpomnjenje sloga. Kako odstraniti predpomnjenje datotek css in js. Osvežitev strani včasih prihrani

Z vključitvijo zunanjih CSS in Javascript želimo zmanjšati nepotrebne zahteve HTTP na minimum.

Za to sta datoteki .js in .css postrežena z glavami, ki zagotavljajo zanesljivo predpomnjenje.

Kaj pa, če se katera od teh datotek med razvojem spremeni? Vsi uporabniki imajo v predpomnilniku staro različico - dokler predpomnilnik ne bo zastarel, se bo pojavilo veliko pritožb zaradi pokvarjene integracije delov strežnika in odjemalca.

Pravilen način predpomnjenja in urejanja različic popolnoma odpravlja to težavo in zagotavlja zanesljivo, pregledno sinhronizacijo različic sloga/skripta.

Enostavno predpomnjenje ETag

Najlažji način za predpomnjenje statičnih virov je uporaba ETag.

Dovolj je, da omogočite ustrezno nastavitev strežnika (za Apache je privzeto omogočena) - in vsaki datoteki v glavah bo dodeljen ETag - hash, ki je odvisen od časa posodobitve, velikosti datoteke in (na datotečnih sistemih, ki temeljijo na inodu). ) inode.

Brskalnik predpomni takšno datoteko in ob poznejših zahtevah določi glavo If-None-Match iz oznake ETag predpomnjenega dokumenta. Po prejemu takšne glave lahko strežnik odgovori s kodo 304 - nato pa bo dokument vzet iz predpomnilnika.

Izgleda takole:

Prva zahteva za strežnik (čiščenje predpomnilnika) GET /misc/pack.js HTTP / 1.1 Host: spletno mesto

Na splošno brskalnik običajno doda kup glav, kot so User-Agent, Accept itd. Izrezane so zaradi kratkosti.

Odgovor strežnika Strežnik v odgovor pošlje dokument s kodo 200 in ETag: HTTP / 1.x 200 OK Kodiranje vsebine: gzip Vrsta vsebine: besedilo / javascript; charset = utf-8 Etag: "3272221997" Sprejemni obsegi: bajti Dolžina vsebine: 23321 Datum: petek, 02. maj 2008 17:22:46 GMT Strežnik: lighttpd Naslednja zahteva brskalnika Na naslednjo zahtevo brskalnik doda Če-Ni ujemanja: (predpomnjena oznaka ETag): GET /misc/pack.js HTTP / 1.1 Host: spletno mesto If-None-Match: "453700005" Odgovor strežnika Strežnik išče - da, dokument se ni spremenil. To pomeni, da lahko izdate kodo 304 in dokumenta ne pošljete več. HTTP / 1.x 304 Nespremenjeno kodiranje vsebine: gzip Etag: "453700005" Vrsta vsebine: besedilo / javascript; nabor znakov = utf-8 Sprejemni obsegi: bajti Datum: torek, 15. april 2008 10:17:11 GMT

Če pa se je dokument spremenil, strežnik preprosto pošlje 200 z novo oznako ET.

Sveženj Last-Modified + If-Modified-Since deluje na podoben način:

strežnik pošlje zadnji spremenjeni datum v glavi Last-Modified (namesto ETag)
brskalnik predpomni dokument in ob naslednji zahtevi za isti dokument pošlje datum predpomnjene različice v glavi If-Modified-Since (namesto If-None-Match)
strežnik preveri datume in če se dokument ni spremenil, pošlje samo kodo 304, brez vsebine.

Te metode delujejo stabilno in dobro, vendar mora brskalnik to tako ali tako narediti na zahtevo za vsak skript ali slog.

Pametno predpomnjenje. Različice

Splošni pristop k različicam je na kratko:

Različica (ali datum spremembe) je dodana vsem skriptom. Na primer, http://site/ my.js se bo spremenilo v http: // stran / my.v1.2.js
Vse skripte brskalnik shrani v predpomnilnik
Ko je skript posodobljen, se različica spremeni v novo: http://site/ my.v2.0.js
Naslov se je spremenil, zato bo brskalnik znova zahteval in predpomnil datoteko
Stara različica 1.2 bo postopoma izpadla iz predpomnilnika

Trdo predpomnjenje

Trdo predpomnjenje- nekakšno kladivo, ki v celoti pribije zahteve na strežnik za predpomnjene dokumente.

Če želite to narediti, samo dodajte glave Expires in Cache-Control: max-age.

Na primer, za predpomnilnik za 365 dni v PHP:

Glava ("Poteče:" .gmdate ("D, d M Y H: i: s", čas () + 86400 * 365). "GMT"); glava ("Cache-Control: max-age =" + 86400 * 365);

Ali pa lahko vsebino dalj časa predpomnite z uporabo mod_header v Apache:

Ko prejme takšne glave, bo brskalnik dolgo časa predpomnil dokument. Vsi nadaljnji klici v dokument bodo streženi neposredno iz predpomnilnika brskalnika, brez stika s strežnikom.

Večina brskalnikov (Opera, Internet Explorer 6+, Safari) NE predpomni dokumentov, če je v naslovu vprašaj, ker se štejejo za dinamične.

Zato imenu datoteke dodamo različico. Seveda morate pri takšnih naslovih uporabiti rešitev, kot je mod_rewrite, to bomo upoštevali kasneje v članku.

P.S. Toda Firefox predpomni naslove z vprašaji ..

Samodejno prevajanje imen

Poglejmo, kako samodejno in pregledno spremeniti različice brez preimenovanja samih datotek.

Ime različice -> Datoteka

Najpreprostejša stvar je pretvoriti različico imena v izvirno ime datoteke.

Na ravni Apache je to mogoče storiti z mod_rewrite:

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

To pravilo obdela vse datoteke css / js / gif / png / jpg in odstrani različico iz imena.

Na primer:

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

Toda poleg rezanja različice morate datotekam dodati tudi trdo predpomnjene glave. Za to se uporabljajo direktive mod_header:

Dodaj v glavo "Poteče" "pon, 28. julij 2014 23:30:00 GMT" Dodaj v glavo "Cache-Control" "max-age = 315360000"

In vse skupaj izvaja takšno konfiguracijo apache:

RewriteEngine na # odstrani različico in hkrati nastavi spremenljivko, da je datoteka različica RewriteRule ^ / (. * \.) V + \. (Css | js | gif | png | jpg) $ / $ 1 $ 2 # datoteke različic s trdim predpomnilnikom Glava add "Poteče" "Ponedeljek, 28. julij 2014 23:30:00 GMT" env = VERSIONED_FILE Glava dodaja "Cache-Control" "max-age = 315360000" env = VERSIONED_FILE

Zaradi načina delovanja modula mod_rewrite mora biti RewriteRule nameščen v glavno konfiguracijsko datoteko httpd.conf ali v datoteke, povezane z njo, nikakor pa v .htaccess, sicer se bodo ukazi Header zagnali najprej, preden je nameščena spremenljivka VERSIONED_FILE.

Glavne direktive so lahko kjerkoli, tudi v .htaccess - ni razlike.

Samodejno dodajte različico imenu datoteke na strani HTML

Kako vstaviti različico v ime skripte, je odvisno od vašega sistema predlog in na splošno od tega, kako dodate skripte (sloge itd.).

Na primer, če uporabljate datum spremembe kot različico in mehanizem predloge Smarty, lahko povezave nastavite tako:

Funkcija različice doda različico:

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

Rezultat na strani:

Optimizacija

Da bi se izognili nepotrebnim klicem statistike, lahko shranite matriko s seznamom trenutnih različic v ločeno spremenljivko.

$ različice ["css"] = matrika ("group.css" => "1.1", "other.css" => "3.0",)

V tem primeru se HTML preprosto nadomesti s trenutno različico iz matrike.

Lahko prekrižate oba pristopa in izdate različico glede na datum spremembe med razvojem - zaradi ustreznosti in v produkciji - različico iz matrike za učinkovitost.

Uporabnost

Ta metoda predpomnjenja deluje povsod, vključno z Javascriptom, CSS, slikami, flash filmi itd.

Uporabno je, ko se dokument spremeni, vendar mora brskalnik vedno imeti trenutno trenutno različico.

Pravilno konfigurirano predpomnjenje zagotavlja veliko povečanje zmogljivosti, prihrani pasovno širino in zmanjša stroške strežnika, vendar številna spletna mesta ne izvajajo dobro predpomnjenja, kar ustvarja pogoje za dirko, ki vodi do nesinhronizacije med povezanimi viri.

Velika večina najboljših praks predpomnjenja spada v enega od dveh vzorcev:

Vzorec # 1: nespremenljiva vsebina in dolga največja starost predpomnilnika

Nadzor predpomnilnika: največja starost = 31536000

Vsebina na URL-ju se ne spremeni, zato ...
Brskalnik ali CDN lahko brez težav predpomni vir eno leto
Predpomnjeno vsebino, ki je mlajša od navedene najvišje starosti, je mogoče uporabiti brez posvetovanja s strežnikom

stran : Hej, potrebujem "/script-v1.js", "/styles-v1.css" in "/cats-v1.jpg" 10:24

predpomnilnik : Jaz sem prazen, kaj pa ti Server? 10:24

Strežnik : OK, tam so. Mimogrede, Cash, jih je treba uporabiti v enem letu, ne več. 10:25

predpomnilnik : HVALA! 10:25

stran : Hura! 10:25

Naslednji dan

stran : Hej, potrebujem "/ script- v2.js "," / styles- v2.css "in" /cats-v1.jpg "08:14

predpomnilnik : Obstaja slika z mačkami, ostalo ne. Strežnik? 08:14

Strežnik : Preprosto - tukaj sta nova CSS & JS. Še enkrat, Cash: njihov rok uporabnosti ni daljši od enega leta. 08:15

predpomnilnik : Super! 08:15

stran : Hvala! 08:15

predpomnilnik : Hmm, "/script-v1.js" in "/styles-v1.css" nisem uporabljal dovolj dolgo. Čas je, da jih izbrišete. 12:32

S tem vzorcem nikoli ne spremenite vsebine določenega URL-ja, spremenite sam URL:

Vsak URL ima nekaj, kar se spreminja skupaj z vsebino. To je lahko številka različice, spremenjen datum ali razpršitev vsebine (to je možnost, ki sem jo izbral za svoj blog).

Večina ogrodij na strani strežnika ima orodja za to vrsto stvari z lahkoto (v Djangu uporabljam Manifest Static Files Storage); V Node.js obstajajo tudi zelo majhne knjižnice, ki opravljajo isto stvar, na primer gulp-rev.

Vendar ta vzorec ni primeren za stvari, kot so članki in objave v spletnem dnevniku. Njihovih URL-jev ni mogoče spreminjati različic in njihova vsebina se lahko spremeni. Resno, imam veliko slovničnih in ločilnih napak in moram biti sposoben hitro posodobiti vsebino.

Vzorec # 2: spremenljiva vsebina, ki je vedno znova potrjena na strežniku

Nadzor predpomnilnika: brez predpomnilnika

Vsebina URL-ja se bo spremenila, zato ...
Nobene lokalne predpomnjene različice ni mogoče uporabiti brez navedbe strežnika.

stran : Hej, potrebujem vsebino "/ about /" in "/sw.js" 11:32

predpomnilnik : Ne morem pomagati. Strežnik? 11:32

Strežnik : Obstajajo takšni. Gotovina, imejte jih pri sebi, vendar me vprašajte pred uporabo. 11:33

predpomnilnik : Ja, gospod! 11:33

stran : HVALA! 11:33

Naslednji dan

stran : Hej, spet potrebujem vsebino "/ about /" in "/sw.js" 09:46

predpomnilnik : Počakaj minuto. Strežnik, ali so moje kopije v redu? Kopija "/ about /" je od ponedeljka, "/sw.js" pa od včeraj. 09:46

Strežnik : "/sw.js" se ni spremenilo ... 09:47

predpomnilnik : Kul. Stran, pridržite "/sw.js". 09:47

Strežnik : ... toda "/ about /" imam novo različico. Cash, drži jo, ampak tako kot zadnjič, ne pozabi najprej vprašati mene. 09:47

predpomnilnik : Razumel! 09:47

stran : V redu! 09:47

Opomba: brez predpomnilnika ne pomeni "ne predpomni", pomeni "preveri" (ali ponovno potrdi) predpomnjeni vir iz strežnika. No-store naroči brskalniku, naj sploh ne predpomni. Prav tako must-revalidate ne pomeni obvezne ponovne veljavnosti, temveč dejstvo, da se predpomnjeni vir uporablja le, če je mlajši od navedene maksimalne starosti, in samo v nasprotnem primeru se ponovno potrdi. Tako se začne s predpomnjenjem ključnih besed.

V tem vzorcu lahko odgovoru dodate ETag (ID različice po vaši izbiri) ali glavo Last-Modified. Ob naslednji zahtevi odjemalca za vsebino izpiše If-None-Match oziroma If-Modified-Since, kar omogoča strežniku, da reče »Uporabi, kar imaš, vaš predpomnilnik je posodobljen«, kar naj vrne HTTP 304.

Če pošiljanje ETag / Last-Modified ni mogoče, strežnik vedno pošlje celotno vsebino.

Ta vzorec vedno zahteva omrežne zahteve, zato ni tako dober kot prvi vzorec, ki zmore brez omrežnih zahtev.

Nič nenavadnega ni, ko nimamo infrastrukture za prvi vzorec, lahko pa se pojavijo tudi težave z omrežnimi zahtevami v vzorcu 2. Posledično se uporabi vmesna možnost: kratka max-age in spremenljiva vsebina. To je slab kompromis.

Uporaba max-age s spremenljivo vsebino je običajno napačna izbira.

In na žalost je razširjena, za primer lahko vzamemo strani Github.

Predstavljajte si:

/ Članek /
/styles.css
/script.js

Z glavo na strani strežnika:

Nadzor predpomnilnika: treba ponovno preveriti, največja starost = 600

spremembe vsebine URL-ja
Če ima brskalnik predpomnjeno različico sveže 10 minut, se uporablja brez posvetovanja s strežnikom
Če takega predpomnilnika ni, se uporabi omrežna zahteva, po možnosti z If-Modified-Since ali If-None-Match

stran : Hej, potrebujem "/ article /", "/script.js" in "/styles.css" 10:21

predpomnilnik : Nimam nič takega kot ti, Server? 10:21

Strežnik : Ni problema, tukaj so. Ampak ne pozabite, Cash: lahko jih uporabite v naslednjih 10 minutah. 10:22

predpomnilnik : Tukaj je! 10:22

stran : HVALA! 10:22

stran : Hej, spet potrebujem "/ article /", "/script.js" in "/styles.css" 10:28

predpomnilnik : Ups, žal sem izgubil "/styles.css", vendar imam vse ostalo, vzemite. Strežnik, ali lahko prilagodiš "/styles.css" zame? 10:28

Strežnik : Preprosto, že se je spremenilo od zadnjega, ko ste ga vzeli v roke. Varno ga lahko uporabljate naslednjih 10 minut. 10:29

predpomnilnik : Ni problema. 10:29

stran : Hvala! Ampak videti je, da je šlo nekaj narobe! Vse je pokvarjeno! Kaj se dogaja? 10:29

Ta vzorec ima pravico živeti v testiranju, vendar v resničnem projektu razbije vse in ga je zelo težko slediti. V zgornjem primeru je strežnik posodobil HTML, CSS in JS, vendar je stran prikazana s starim HTML in JS iz predpomnilnika, kateremu je bil dodan posodobljen CSS iz strežnika. Neusklajenost različic pokvari vse.

Pogosto pri pomembnih spremembah HTML spremenimo CSS, da pravilno odraža novo strukturo, in JavaScript, da sledi vsebini in slogom. Vsi ti viri so neodvisni, vendar glave predpomnilnika tega ne morejo izraziti. Posledično imajo lahko uporabniki najnovejšo različico enega/dveh virov in staro različico ostalih.

max-age je nastavljena glede na odzivni čas, tako da, če so vsi viri preneseni kot del istega naslova, bodo potekli hkrati, vendar je še vedno majhna možnost desinhronizacije. Če imate strani, ki ne vključujejo JavaScript ali vključujejo druge sloge, datumi poteka njihovega predpomnilnika niso sinhronizirani. In še huje, brskalnik nenehno vleče vsebino iz predpomnilnika, ne da bi vedel, da so HTML, CSS in JS medsebojno odvisni, zato lahko z veseljem potegne enega s seznama in pozabi na vse ostalo. Če upoštevamo vse te dejavnike skupaj, morate razumeti, da je verjetnost neujemanja različic precej velika.

Za uporabnika je lahko rezultat pokvarjena postavitev strani ali druge težave. Od majhnih napak do popolnoma neuporabnih vsebin.

Na srečo imajo uporabniki izhod v sili ...

Osvežitev strani včasih shrani

Če se stran naloži z osvežitvijo, brskalniki vedno opravijo ponovno preverjanje veljavnosti na strani strežnika, pri čemer prezrejo največjo starost. Če ima torej uporabnik zaradi maksimalne starosti kaj pokvarjenega, lahko preprosto osvežitev strani vse popravi. Seveda pa bo po najdenih žlicah usedlina še vedno ostala in odnos do vašega mesta bo nekoliko drugačen.

Servisni delavec lahko podaljša življenjsko dobo teh hroščev.

Na primer, imate takšnega serviserja:

Const različica = "2"; self.addEventListener ("install", event => (event.waitUntil (caches.open (`static - $ (version)`) .theen (cache => cache.addAll (["/styles.css", "/ script .js "])));)); self.addEventListener ("aktiviraj", dogodek => (//… izbriši stare predpomnilnike...)); self.addEventListener ("pridobi", dogodek => (event.respondWith (caches.match (event.request) .then (response => response || fetch (event.request)));));

Ta serviser:

predpomni skript in sloge
uporablja predpomnilnik ob tekmi, sicer pa dostopa do omrežja

Če spremenimo CSS/JS, povečamo tudi številko različice, kar sproži posodobitev. Ker pa addAll najprej dostopa do predpomnilnika, se lahko zaradi največje starosti in neusklajenih različic CSS in JS končamo v stanju dirke.

Ko so predpomnjeni, bomo imeli nezdružljiva CSS & JS do naslednje posodobitve serviserja - in to je, če med posodobitvijo spet ne pridemo v stanje dirke.

Predpomnjenje v servisnem delavcu lahko preskočite:

Self.addEventListener ("install", event => (event.waitUntil (caches.open (`statično - $ (version)`) .theen (cache => cache.addAll ([nova zahteva ("/ styles.css", (cache: "no-cache")), nova zahteva ("/ script.js", (cache: "no-cache"))])));));

Žal možnosti za predpomnjenje niso podprte v Chromu/Operi in so bile pravkar dodane v nočno gradnjo Firefoxa, vendar lahko to storite sami:

Self.addEventListener ("install", event => (event.waitUntil (caches.open (`static - $ (version)`) .theen (cache => Promise.all (["/styles.css", "/ script) .js "] .map (url => (// cache-bust z uporabo naključnega niza poizvedbe vrnitev pridobivanja (` $ (url)? $ (Math.random ()) `) .then (response => (// neuspešno na 404, 500 itd, če (! response.ok) vrže napako ("Ni v redu"); vrni cache.put (url, odgovor);))))))))));));

V tem primeru izpiram predpomnilnik z naključno številko, vendar lahko nadaljujete in dodate zgoščeno vsebino pri gradnji (to je podobno tistemu, kar počne sw-precache). To je nekakšna implementacija JavaScript prvega vzorca, vendar deluje samo s serviserjem, ne pa z brskalniki in CDN-ji.

Service Workers in HTTP Cache odlično sodelujeta, ne silite jih v prepir!

Kot lahko vidite, lahko odpravite napake pri predpomnjenju v servisnem delavcu, vendar je bolje, da se lotite korenine težave. Pravilna nastavitev predpomnjenja ne le olajša delo serviserja, ampak tudi pomaga brskalnikom, ki ne podpirajo servisnih delavcev (Safari, IE / Edge), in vam omogoča, da kar najbolje izkoristite svoj CDN.

Pravilne glave predpomnilnika lahko tudi precej olajšajo posodobitev storitvenega delavca.

Const različica = "23"; self.addEventListener ("install", event => (event.waitUntil (caches.open (`statično - $ (različica)`) .theen (cache => cache.addAll (["/", "/ script-f93bca2c. js "," /styles-a837cb1e.css "," /cats-0e9a2ef4.jpg "])));));

Tukaj sem predpomnil korensko stran z vzorcem #2 (ponovna potrditev na strani strežnika) in vse druge vire z vzorcem #1 (nespremenljiva vsebina). Vsaka posodobitev serviserja bo povzročila zahtevo korenski strani, vsi drugi viri pa se bodo naložili le, če se je njihov URL spremenil. Dobra novica je, da prihrani promet in izboljša zmogljivost, ne glede na to, ali nadgrajujete s prejšnje ali zelo stare različice.

Tukaj je bistvena prednost pred izvorno implementacijo, kjer se celotna binarna datoteka prenese tudi z majhno spremembo ali pa se sklicuje na kompleksne binarne primerjave. Na ta način lahko posodobimo veliko spletno aplikacijo z relativno majhno obremenitvijo.

Servisni delavci delujejo bolje kot izboljšava in ne kot začasna bergla, zato delajte s predpomnilnikom, namesto da bi se borili proti njemu.

Ob previdni uporabi sta lahko največja starost in spremenljiva vsebina zelo dobra.

max-age je zelo pogosto napačna izbira za spremenljivo vsebino, vendar ne vedno. Na primer, izvirni članek ima največjo starost tri minute. Pogoji dirke niso problem, saj na strani ni odvisnosti, ki uporablja isti vzorec predpomnjenja (CSS, JS in slike uporabljajo vzorec # 1 - nespremenljiva vsebina), vse ostalo ne uporablja tega vzorca.

Ta vzorec pomeni, da mirno pišem priljubljen članek, moj CDN (Cloudflare) pa lahko prevzame obremenitev s strežnika, če sem seveda pripravljen počakati tri minute, da bo posodobljen članek na voljo uporabnikom.

Ta vzorec je treba uporabljati brez fanatizma. Če sem članku dodal nov razdelek in se nanj povezal iz drugega članka, sem ustvaril odvisnost, ki jo je treba razrešiti. Uporabnik lahko klikne na povezavo in dobi kopijo članka brez rubrike, ki jo išče. Če se želim temu izogniti, moram posodobiti članek, izbrisati predpomnjeno različico članka iz Cloudflareja, počakati tri minute in šele nato dodati povezavo do drugega članka. Da, ta vzorec zahteva previdnost.

Če se pravilno uporablja, lahko predpomnjenje zagotovi znatne prihranke zmogljivosti in pasovne širine. Posredujte nespremenljivo vsebino, če lahko preprosto spremenite URL ali uporabite ponovno preverjanje na strani strežnika. Zmešajte največjo starost in spremenljivo vsebino, če ste dovolj drzni, da se prepričate, da vaša vsebina nima nobenih odvisnosti, ki bi lahko ušle iz sinhronizacije.

Mnogi ljudje mislijo, da datoteke CSS, povezane prek povezave ali @import, privzeto niso predpomnjene. moram te razočarati. Prav css je predpomnjen v ločeni datoteki in je zelo dober, rekel bi odličen. Te informacije so zanesljivo preverjene v brskalnikih 6 in novejših ter drugih brskalnikih. Omeniti velja, da mnogi ljubljeni predpomnijo takšne datoteke s popolnoma divjo hitrostjo, tako rekoč, dobijo prvo mesto za ta primer. Mimogrede, prav zaradi tega mehanizma ima Opera v mnogih primerih znatno hitrost v primerjavi z drugimi brskalniki. Bom pa takoj rezerviral, da je to "super" predpomnjenje v Operi kruta šala z njim pri uporabi tehnologije AJAX. Medtem ko drugi prilagajajo chicky šopke, ko uporabljajo AJAX, Opera prevzame starega. Ampak to je pesem ločene teme.

Predpomnjenje CSS

AMPAK! V tej smeri je še vedno nekaj težav z žalostjo. To je praviloma posledica napačno konfiguriranega strežnika Apache, ki proizvaja napačne glave. In s pomočjo glave lahko nadzorujete predpomnjenje datotek. Privzeto je seveda predpomnilnik vedno omogočen. Toda včasih vam ni treba predpomniti datotek. Za to začnejo profesionalci plesati s tamburami o glavah HTTP. Če pa berete celoten članek, ste še vedno zelo daleč od upravljanja z glavo HTTP. Zagotavljam vam, da se v bližnji prihodnosti ne boste soočili s takšno nalogo. In vendar, če ste radovedni do jedra, vam bom na kratko povedal, kako se to zgodi.

pošlje HTTP glavo na WEB strežnik - pravijo, hej, sladka paprika, daj mi datoteko CSS, sicer imam CSS, ampak zadnjič je bila takšna sprememba.
In strežnik mu v odgovor reče, tako sladko, od tistega trenutka ni bilo nobenih sprememb, vzemi in pogumno uporabljaj svoj stari CSS.
Če se je CSS spremenil, brskalnik neumno posodobi CSS v svojem predpomnilniku.

No, zdaj, če ne utrujen, pa malo znanstvene smeti iz neke vrste eksperimenta.

Takoj vam povem, da bo spodnje besedilo začetnikom v SPLETU slabo razumljivo. V bistvu bo to koristno za tiste, ki se še vedno soočajo z nalogami onemogočanja in omogočanja predpomnilnika.

Vsi poskusi so bili izvedeni na pravi, plačani osnovi. Dober gostitelj, tako rekoč, ki vam omogoča spreminjanje strukture glav HTTP, ne da bi morali biti paranoji, da jih bo vdrla glava HTTP :)

Načini brskalnika

Tako ima vsak brskalnik 2 načina:

1. Privzeti način, vrnjeni naslov je:

Nadzor predpomnilnika: brez shranjevanja, brez predpomnilnika, potrebno ponovno potrditev, naknadno preverjanje = 0, predhodno preverjanje = 0

2. Omogočen način predpomnjenja, vrnjeni naslov je:

Nadzor predpomnilnika: zasebno, največja starost = 10800, predhodno preverjanje = 10800

Nato opisujem obnašanje brskalnikov

FireFox 3.5 in novejše

V prvi način trdno predpomni zunanje datoteke JavaScript in niti ne preverja posodobitev, razen če prisilite, da se stran osveži. CSS je potrjen z zahtevo glave.

If-Modified-Since: "trenutni datum" GMT If-None-Match: "lastna hash koda"

To pomeni, da se CSS znova naloži le, če je bil dejansko posodobljen.

Drugič način popolnoma ustavi osveževanje strani. To pomeni, da tudi če smo spremenili vsebino, prikazano na strani v bazi, tega ne prikaže, tudi če je prisiljena osvežiti, saj pošlje zahtevo:

GET / HTTP / 1.1 Host: xxx.com Če-Modified-Since: trenutni GMT datum

in dobi odgovor:

HTTP / 1.1 304 Ni spremenjeno

Internet Explorer 8 (IE8)

V prvi Način Internet Explorer pošilja zahtevi If-Modified-Since in If-None-Match za JavaScript in css, to pomeni, da naloži JavaScript in CSS le, če sta dejansko posodobljena. Enako velja, če je stran prisiljena osvežiti.

Drugič Način Internet Explorer pošilja tudi zahteve If-Modified-Since in If-None-Match za JavaScript in css. Toda hkrati niti ne poskuša naložiti / posodobiti same strani, torej niti ne pošlje zahteve, torej bo vaš js / css posodobljen, predloga in vsebina strani pa ne. Tudi prisilna osvežitev strani ne pomaga posodobiti vsebine.

Opera 10 in več

V prvi Način Opera, v prvem načinu je posodobitev js & CSS odvisna od vrednosti možnosti Preveri slike v nastavitvah. Če je možnost nastavljena na Vedno, opera pošlje zahteve z možnostjo If-Modified-Since & If-None-Match, da preveri posodobitve js in css. Če je vrednost nastavljena na primer 5 ur, se bo v skladu s tem preverila enkrat na vsakih 5 ur ali s prisilno osvežitvijo strani.

Drugič Opera ne preverja posodobitev js in CSS (ne izvaja zahtev GET) in tudi ne naredi zahteve GET za samo stran, to pomeni, da ne bomo videli posodobitev js in css ali posodobitev vsebine, kot je v druge stvari in v drugih brskalnikih. Toda s prisilno posodobitvijo je Opera boljša. Za razliko od IE in FF, Opera izrecno zahteva vsebino strani brez ujemanja If-Modified-Since & If-None-Match. Zahteve za posodobitev Js in CSS za prisilno posodobitev prihajajo z If-Modified-Since & If-None-Match.

sklepi

Predpomnjenje, če ne razumete natančno, kako deluje v različnih brskalnikih in kakšne so posledice, je precej nevarna stvar.
Predpomnjenje je mogoče omogočiti le, če se stran redko posodablja (to je, če spletno mesto nima strani, ki se posodabljajo v realnem času) in tudi v tem primeru je nujno določiti omejitev obdobja omejitve predpomnjenja (npr. , nekaj ur ali dan)
FireFox se po mojem mnenju obnaša nekoliko pametneje kot IE, saj tudi z onemogočenim predpomnjenjem ne preverja nenehno posodobitev JavaScripta, kar je logično, saj se JavaScript posodablja zelo redko.
Opera vam omogoča prilagodljiv nadzor nad posodabljanjem slik, JavaScript in CSS z uporabo nastavitve Preveri slike, kar je plus. Opera se obnaša tudi bolje kot IE in FF z omogočenim predpomnjenjem in prisilnim osveževanjem, saj naj vas spomnim, da Opera v tem primeru popolnoma osveži vsebino strani, IE & FF pa vas bosta pustila v srečni nevednosti.

Vso srečo in donosna spletna mesta.