A gyorsítótár szinte minden webes alkalmazás működésében fontos szerepet játszik az adatbázisokkal, webszerverekkel és a kliensekkel való munka szintjén.
Ebben a cikkben megpróbáljuk az ügyféloldali gyorsítótárazással foglalkozni. Különösen nézzük meg, hogy a böngészők és webszerverek milyen http fejléceket használnak, és mit jelentenek.
De először nézzük meg, miért van egyáltalán szükség kliensoldali gyorsítótárazásra? .
A weboldalak sok különböző elemből állnak: képek, css és js fájlok stb. Ezen elemek némelyike a webhely több (sok) oldalán használatos. Az ügyféloldali gyorsítótárazás a böngészők azon képessége, hogy megtartsák a fájlok másolatait (szerverválaszokat), hogy ne töltsék le őket újra. Ezzel jelentősen felgyorsíthatja az oldalak újratöltését, megtakaríthatja a forgalmat, és csökkentheti a szerver terhelését is.
Számos különböző HTTP-fejléc létezik az ügyféloldali gyorsítótár vezérlésére. Beszéljünk mindegyikről.
Http fejlécek az ügyféloldali gyorsítótár vezérléséhezElőször is nézzük meg, hogyan működik együtt a szerver és a böngésző gyorsítótárazás hiányában. A vizuális megértés érdekében megpróbáltam elképzelni és megjeleníteni a köztük zajló kommunikáció folyamatát egy szöveges chat formájában. Képzeld el néhány percre, hogy a szerver és a böngésző olyan emberek, akik leveleznek egymással :)
Gyorsítótár nélkül (a http fejlécek gyorsítótárazásának hiányában)Amint látjuk, minden alkalommal, amikor megjelenik a cat.png kép, a böngésző újra letölti azt a szerverről. Azt hiszem, nem kell magyaráznom, hogy lassú és nem hatékony.
A válaszfejléc utolsó módosítása, a kérés fejléce pedig if-Modified-Since.Az ötlet az, hogy a szerver hozzáad egy Last-modified fejlécet a fájlhoz (válasz), amelyet a böngészőnek ad.
A böngésző most már tudja, hogy a fájlt 2014. december 1-jén hozták létre (vagy módosították). Amikor legközelebb a böngészőnek szüksége lesz ugyanerre a fájlra, kérést küld egy if-Modified-Since fejléccel.
Ha a fájlt nem módosították, a szerver üres választ küld a böngészőnek 304 (Nem módosított) állapottal. Ebben az esetben a böngésző tudja, hogy a fájl nem frissült, és képes megjeleníteni a legutóbb mentett másolatot.
Így a Last-modified használatával spórolunk a betöltéskor nagy fájl, kiszáll egy üres gyors válasz a szervertől.
Etag válaszfejléc és If-None-Match kérésfejléc.Az Etag működési elve nagyon hasonlít a Last-modified-re, de vele ellentétben nincs időhöz kötve. Az idő relatív dolog.
Az ötlet az, hogy létrehozáskor és minden módosításkor a szerver megjelöli a fájlt egy speciális ETag címkével, és egy fejlécet is hozzáad a fájlhoz (válasz), amelyet a böngészőnek ad:
Ecímke: "686897696a7c876b7e"
Most a böngésző tudja, hogy a fájl jelenlegi verzió egy ET-címke „686897696a7c876b7e”. Amikor legközelebb a böngészőnek szüksége lesz ugyanerre a fájlra, egy If-None-Match kérést küld: "686897696a7c876b7e" fejléc.
If-None-Match: "686897696a7c876b7e"
A szerver összehasonlíthatja a címkéket, és ha a fájl nem módosult, üres választ küld a böngészőnek 304 (Nem módosított) állapottal. Az Utolsó módosításhoz hasonlóan a böngésző megállapítja, hogy a fájl nem frissült, és képes lesz megjeleníteni a gyorsítótárazott példányt.
Fejléc lejártEnnek a fejlécnek a működése eltér a fenti Etag-től és a Last-modified -től. Az Expired segítségével a fájl „lejárati dátuma” („relevancia dátuma”) kerül meghatározásra. Azok. első betöltéskor a szerver tudatja a böngészővel, hogy nem tervezi módosítani a fájlt az Expired részben megadott dátum előtt:
A következő alkalommal a böngésző, tudva, hogy még nem érkezett meg a "lejárati dátum", meg sem próbál kérést intézni a szerverhez, és a gyorsítótárból jeleníti meg a fájlt.
Ez a fajta gyorsítótár különösen fontos cikkek, ikonok, kedvenc ikonok, egyes css és js fájlok stb. illusztrációinál.
Cache-control fejléc max-age direktívával.A Cache-control: max-age működése nagyon hasonlít az Expired funkcióhoz. Itt van meghatározva a fájl „lejárati dátuma” is, de ez másodpercekben van megadva, és nincs konkrét időponthoz kötve, ami a legtöbb esetben sokkal kényelmesebb.
Tájékoztatásul:
Például:
Cache-Control: max-age=2629000;
A Cache-control fejlécnek a max-age mellett más utasításai is vannak. Vessünk egy pillantást a legnépszerűbbekre:
nyilvános
A helyzet az, hogy nem csak a felhasználó (böngésző) végkliense tudja gyorsítótárazni a kéréseket, hanem különféle köztes proxy-k, CDN hálózatok stb. Tehát a nyilvános direktíva minden proxyszerver számára lehetővé teszi, hogy a böngészővel egyenrangú gyorsítótárazást hajtson végre.
magán
Az irányelv ezt mondja adott fájl(szerverválasz) végfelhasználó specifikus, és nem szabad különböző köztes proxykkal gyorsítótárazni. Azonban lehetővé teszi a gyorsítótárazást a végklienshez (a felhasználó böngészőjéhez). Ez például igaz a belső felhasználói profiloldalakra, a munkameneten belüli kérésekre stb.
Lehetővé teszi annak megadását, hogy az ügyfélnek minden alkalommal kérést kell küldenie a szervernek. Néha a fent leírt Etag fejléccel együtt használják.
nincs bolt
Jelzi az ügyfélnek, hogy semmilyen körülmények között nem őrizheti meg a kérelem másolatát vagy annak egyes részeit. Ez a legszigorúbb fejléc, amely felülír minden gyorsítótárat. Kifejezetten bizalmas információk kezelésére tervezték.
újra kell érvényesíteni
Ez az utasítás arra utasítja a böngészőt, hogy küldjön kötelező kérést a szervernek a tartalom újraellenőrzésére (például ha eTag-et használ). A tény az, hogy a http egy bizonyos konfigurációban lehetővé teszi, hogy a gyorsítótár olyan tartalmat tároljon, amely már elavult. A must-revalidate kötelezi a böngészőt, hogy minden körülmények között ellenőrizze a tartalom frissességét a szerver lekérésével.
proxy-revalidate
Ez ugyanaz, mint a must-revalidate , de csak a gyorsítótárazott proxykra vonatkozik.
s-max
Majdnem ugyanaz, mint a max-age , kivéve, hogy ezt az irányelvet csak a különböző proxy-gyorsítótárak veszik figyelembe, maga a felhasználó böngészője nem. Az „s -” betű az „s shared” szóból származik (például CDN). Ez az irányelv kifejezetten a CDN-ekre és más közvetítő gyorsítótárra vonatkozik. Megadása felülírja a max-age direktívát és az Expired fejlécet. Ha azonban nem épít CDN-hálózatokat, akkor valószínűleg nem lesz szüksége s-maxage-re.
A http kérés fejléceit és válaszfejléceit kedvenc böngészője hibakeresőjében tekintheti meg. Íme egy példa, hogyan néz ki krómban:
Ugyanez látható minden önbecsülő böngészőben vagy http szippantóban.
A gyorsítótárazás beállítása Apache-ban és NginxbenNem mondjuk el újra a népszerű szerverek beállításához szükséges dokumentációt. Mindig meg lehet nézni és. Az alábbiakban néhány valós példát mutatunk be, amelyek megmutatják, hogyan néznek ki a konfigurációs fájlok.
Apache konfigurációs példa az Expires vezérléshezA különböző típusú fájlokhoz eltérő „lejárati dátumot” állítunk be. Egy év a képeknek, egy hónap a szkripteknek, stílusoknak, pdf-eknek és ikonoknak. Minden másra - 2 nap.
ExpiresActive On ExpiresByType image/jpg "hozzáférés plusz 1 év" ExpiresByType image/jpeg "access plus 1 év" ExpiresByType image/gif "access plus 1 year" ExpiresByType image/png "access plus 1 year" ExpiresByType "access text/css1y" hónap" ExpiresByType alkalmazás/pdf "hozzáférés plusz 1 hónap" ExpiresByType szöveg/x-javascript "hozzáférés plusz 1 hónap" ExpiresByType image/x-icon "hozzáférés plusz 1 év" ExpiresDefault "hozzáférés plusz 2 nap"
Példa az Nginx vezérlési konfigurációjára lejárA különböző típusú fájlokhoz eltérő „lejárati dátumot” állítunk be. Egy hét a képekre, egy nap a stílusokra és forgatókönyvekre.
Szerver ( #... hely ~* \.(gif|ico|jpe?g|png)(\?+)?$ ( 1 hét múlva lejár; ) hely ~* \.(css|js)$ ( 1 nap múlva lejár; ) #... )
Apache konfigurációs példa a gyorsítótár-vezérléshez (max-age és public/private/no-cache) Header set Cache-Control "max-age=2592000, public" Header set Cache-Control "max-age=88000, private, must- revalidate" Fejléckészlet Cache-Control "private, no-store, no-cache, must-revalidate, no-transform, max-age=0" Fejléckészlet Pragma "no-cache" Példa Nginx konfigurációra a Cache-control statikus fájlkiszolgálóhoz ( #... hely ~* \.(?:ico|css|js|gif|jpe?g|png)$ ( add_header Cache-Control "max-age=88000, public"; ) #... ) következtetés„Gyorsítótárazzon mindent, ami gyorsítótárazható” egy jó mottó egy webfejlesztő számára. Néha csak néhány órát tölthet a konfigurálással, és így is jelentősen javíthatja webhelye felhasználói élményét, jelentősen csökkentheti a szerverterhelést, és megtakaríthatja a forgalmat. A lényeg az, hogy ne vigye túlzásba, és mindent helyesen állítson be, figyelembe véve az erőforrás jellemzőit.
A külső CSS és Javascript beépítésével minimálisra szeretnénk csökkenteni a szükségtelen HTTP kéréseket.
Ehhez a .js és .css fájlok fejlécekkel vannak ellátva, amelyek megbízható gyorsítótárat biztosítanak.
De mi a teendő, ha a fájlok egyike megváltozik a fejlesztés során? A gyorsítótárban lévő összes felhasználónak a régi verziója van - amíg a gyorsítótár nem elavult, sok panasz lesz a szerver és a kliens részek megszakadt integrációjával kapcsolatban.
A gyorsítótárazás és a verziókezelés helyes módja teljesen kiküszöböli ezt a problémát, és megbízható, átlátható szinkronizálást biztosít a stílus/szkript verziók között.
Egyszerű ETag gyorsítótárA statikus erőforrások gyorsítótárazásának legegyszerűbb módja az ETag használata.
Elegendő engedélyezni a megfelelő szerver beállítást (az Apache-nál ez alapértelmezés szerint engedélyezve van) - és a fejlécekben minden fájl kap egy ETag-et - egy hash-t, amely függ a frissítési időtől, a fájl méretétől és (az inode alapútól fájlrendszerek) inode.
A böngésző gyorsítótárazza az ilyen fájlokat, és a későbbi kérések esetén megadja az If-None-Match fejlécet a gyorsítótárazott dokumentum ETag-jével. Miután megkapta az ilyen fejlécet, a szerver 304-es kóddal válaszolhat - majd a dokumentum a gyorsítótárból kerül ki.
Ez így néz ki:
Első kérés a szerverhez (gyorsítótár törlése) GET /misc/pack.js HTTP/1.1 Host: webhely
Általánosságban elmondható, hogy a böngésző általában egy csomó fejlécet ad hozzá, például User-Agent, Accept és így tovább. A rövidség kedvéért le vannak vágva.
Szerver válasza A szerver visszaküld egy dokumentumot 200 kóddal és ETag: HTTP/1.x 200 OK Content-Encoding: gzip Tartalomtípus: text/javascript; charset=utf-8 Etag: "3272221997" Accept-Tartományok: bájt Tartalom-hossz: 23321 Dátum: Péntek, 2008. május 2. 17:22:46 GMT Szerver: lighttpd Következő böngészőkérés A következő kérésre a böngésző hozzáadja az If-None-t -Egyezés: (gyorsítótárazott ETag): GET /misc/pack.js HTTP/1.1 Gazda: site Ha-Nincs-Egyezés: "453700005" Szerver válasza A szerver keres – igen, a dokumentum nem változott. Így kiadhat egy 304-es kódot, és nem küldheti el újra a dokumentumot. HTTP/1.x 304 Nem módosított tartalom-kódolás: gzip Etag: "453700005" Tartalomtípus: szöveg/javascript; charset=utf-8 Elfogadási tartományok: bájtok Dátum: kedd, 2008. április 15. 10:17:11 GMT
Alternatív lehetőség- ha a dokumentum megváltozott, akkor a szerver egyszerűen 200-at küld az új ETag-vel.
A Last-Modified + If-Modified-Since csomag hasonló módon működik:
Ezek a módszerek stabilan és jól működnek, de a böngészőnek továbbra is kérésre meg kell tennie minden szkriptet vagy stílust.
Intelligens gyorsítótár. VerziószámításA verziókészítés általános megközelítése - dióhéjban:
Kemény gyorsítótár- egyfajta kalapács, amely a gyorsítótárazott dokumentumokra vonatkozó kéréseket teljesen a szerverhez szegezi.
Ehhez csak adja hozzá az Expires és a Cache-Control: max-age fejlécet.
Például 365 napig gyorsítótárazáshoz PHP-ben:
Header("Expires: ".gmdate("D, d M Y H:i:s", time()+86400*365)." GMT"); header("Cache-Control: max-age="+86400*365);
Vagy véglegesen gyorsítótárba helyezheti a tartalmat az Apache mod_header használatával:
Miután megkapta az ilyen fejléceket, a böngésző hosszú ideig keményen tárolja a dokumentumot. A dokumentumhoz való minden további hozzáférés közvetlenül a böngésző gyorsítótárából történik, a szerver hívása nélkül.
A legtöbb böngésző (Opera, internet böngésző 6+, Safari) NE gyorsítótárazzon dokumentumokat, ha a címben kérdőjel van, mert dinamikusnak számítanak.
Ezért adjuk hozzá a verziót a fájlnévhez. Természetesen az ilyen címeknél olyan megoldást kell használni, mint a mod_rewrite, ezt a cikk későbbi részében megvizsgáljuk.
Ui.: De a Firefox kérdőjelekkel gyorsítótárazza a címeket.
Automatikus névfeloldásNézzük meg, hogyan lehet automatikusan és átláthatóan módosítani a verziókat a fájlok átnevezése nélkül.
Név a verzióval -> FájlA legegyszerűbb, ha a verziószámú nevet az eredeti fájlnévvé alakítja.
Apache szinten ezt a mod_rewrite paranccsal lehet megtenni:
RewriteEngine on RewriteRule ^/(.*\.)v+\.(css|js|gif|png|jpg)$ /$1$2 [L]
Egy ilyen szabály az összes css/js/gif/png/jpg fájlt feldolgozza, és levonja a verziót a névből.
Például:
/images/logo.v2.gif -> /images/logo.gif
/css/style.v1.27.css -> /css/style.css
/javascript/script.v6.js -> /javascript/script.js
De a verzió kivágása mellett kemény gyorsítótárazási fejléceket is kell hozzáadnia a fájlokhoz. Ehhez a mod_header direktívákat használjuk:
Fejléc hozzáadása "Lejár" "Hétfő, 2014. július 28. 23:30:00 GMT" Fejléc hozzáadása "Cache-Control" "max-age=315360000"
És mindez együtt a következő Apache konfigurációt valósítja meg:
A RewriteEngine on # eltávolítja a verziót, és egyúttal beállítja a fájl verziószámának változóját RewriteRule ^/(.*\.)v+\.(css|js|gif|png|jpg)$ /$1$2 # merev gyorsítótár verziójú fájlok Fejléc hozzáadása "Lejár" "Hétfő, 2014. július 28. 23:30:00 GMT" env=VERSIONED_FILE Fejléc hozzáadása "Cache-Control" "max-age=315360000" env=VERSIONED_FILE
A mod_rewrite modul működése miatt a RewriteRule-t a főbe kell helyezni konfigurációs fájl A httpd.conf vagy annak include fájlok, de soha nem a .htaccess fájlban, különben a fejléc parancsok futnak először, mielőtt a VERSIONED_FILE változót beállítanák.
A fejléc direktívák bárhol lehetnek, még a .htaccess-ben is – ez nem számít.
Verzió automatikus hozzáadása a fájlnévhez a HTML oldalonA verziónak a szkriptnévben való elhelyezése a sablonrendszertől és általában a szkriptek hozzáadásának módjától (stílusok stb.) függ.
Például, ha a módosítás dátumát használja verzióként és a Smarty sablonmotort, a hivatkozások a következőképpen állíthatók be:
A verzió függvény hozzáad egy verziót:
függvény smarty_version($args)( $stat = stat($GLOBALS["config"]["site_root"].$args["src"]); $verzió = $stat["mtime"]; echo preg_replace("! \.(+?)$!", ".v$verzió.\$1", $args["src"]); )
Eredmény az oldalon:
Optimalizálás
A stat szükségtelen hívásainak elkerülése érdekében tárolhat egy tömböt az aktuális verziók listájával egy külön változóban
$versions["css"] = array("group.css" => "1.1", "other.css" => "3.0", )
Ebben az esetben a HTML egyszerűen lecserélődik Jelenlegi verzió egy tömbből.
Mindkét megközelítést keresztezheti, és a fejlesztés során kiadhat egy verziót a módosítás dátuma szerint - a relevancia szempontjából, élesben pedig - a teljesítmény érdekében egy tömbből származó verziót.
AlkalmazhatóságEz a fajta gyorsítótárazás mindenhol működik, beleértve a Javascriptet, a CSS-t, a képeket, a flash filmeket és így tovább.
Hasznos, amikor a dokumentum változik, de a böngészőnek mindig az aktuális, naprakész verzióval kell rendelkeznie.
A HTML5 lehetővé tette olyan webes alkalmazások létrehozását, amelyek internetkapcsolat nélkül is működnek.
Továbbfejlesztett oldal gyorsítótárMegjegyzés: Az IE10+, a Chrome, a Firefox, az Opera és a Safari támogatja ezt a technológiát.
A HTML5 kibővíti a böngésző gyorsítótárazásának lehetőségeit. A weboldalak mostantól internetkapcsolat nélkül is teljes mértékben elérhetőek a felhasználók számára.
A HTML5 gyorsítótár használata a következő előnyökkel jár:
...Dokumentum tartalma...
HTML5 gyorsítótár deklarálásaA gyorsítótárazási mechanizmus weboldalain való használatához hozzá kell adnia a jegyzék attribútumot a címkéhez, és meg kell adnia egy speciális fájl elérési útját, amelyben a gyorsítótárazási paraméterek értékként deklarálva vannak.
Ha ez az attribútum nincs beállítva a weboldalon, és a rá mutató hivatkozás nem található a gyorsítótárfájlban, akkor az oldal nem kerül gyorsítótárba.
A gyorsítótár fájl bármilyen kiterjesztéssel rendelkezhet (például .appcache vagy .mf), de rendelkeznie kell egy speciális MIME-típussal: "text/cache-manifest".
Egyes esetekben a webszervernek további konfigurációra lehet szüksége egy adott MIME-típus kiszolgálásához. Például az Apache webszerver beállításához hozzá kell adnia a következő kódot a .htaccess fájlhoz:
AddType text/cache-manifest .appcache
A cache fájl tartalmaA cache fájl normális szöveges fájl, amely megmondja a böngészőnek, hogy mely fájlokat tárolja a gyorsítótárban.
A fájl három részből állhat:
A CACHE MANIFEST szakasznak minden gyorsítótárfájlban jelen kell lennie. A NETWORK és a FALLBACK szakaszok hiányozhatnak.
Példa gyorsítótár fájl:
CACHE MANIFEST #Ez a szakasz felsorolja azokat a fájlokat, amelyek gyorsítótárba kerülnek index.html flower.png HÁLÓZAT #Ezen a listán találhatók azok a fájlok, amelyek internetkapcsolatot igényelnek login-page.php VISSZA #Ha a mob.html nem érhető el, a felhasználó át lesz irányítva a következő helyre: offline.html /mob .html /offline.html #Ha valamelyik HTML fájlok a nem elérhető felhasználó át lesz irányítva az offline.html *.html /offline.html oldalra
Ne feledje, hogy a gyorsítótárfájlra hivatkozó weboldal automatikusan gyorsítótárba kerül, ezért a gyorsítótárfájlba való belefoglalása nem kötelező, de ennek ellenére ajánlott.
Kérjük, vegye figyelembe, hogy egyes böngészők korlátozhatják az egyetlen webhelyen tárolt tartalom méretét.
Frissítse a gyorsítótárazott fájlokatA fájlok gyorsítótárazása után a böngésző továbbra is újra és újra megjeleníti a gyorsítótárazott verziójukat, még akkor is, ha módosítja a fájlok tartalmát a szerveren.
A gyorsítótárazott tartalom frissítéséhez a következők egyikét kell tennie:
Egy fájl tartalmának frissítéséhez a következő trükköt használhatja: a fájl tartalmának közvetlen frissítése helyett megjegyzést fűzhet hozzá a módosítás dátumával és/vagy a fájl verziójával, és a jövőben csak módosíthatja. a megjegyzés tartalmát, amikor csak akarja. Frissítse a gyorsítótárazott tartalmat.
Amikor egy böngésző megjelenít egy weboldalt, be kell töltenie a logót, a CSS-fájlt és egyéb erőforrásokat:
A böngésző gyorsítótára „emlékezik” azokra az erőforrásokra, amelyeket a böngésző már letöltött. Amikor egy látogató a webhely másik oldalára lép, megjelenik a logó, a CSS-fájlok stb. nem szabad újra letölteni, mert a böngésző már "megjegyezte" őket (mentve ). Ez az oka annak, hogy egy weboldal hosszabb ideig tölt be az első látogatáskor, mint az ismételt látogatások alkalmával.
Ha gyorsítótárat használ, a weboldal fájljai a böngésző gyorsítótárában tárolódnak. Az oldalak sokszor gyorsabban töltődnek be ismételt látogatások alkalmával. Ez más oldalakon is így lesz, amelyek ugyanazokat az erőforrásokat használják.
A gyorsítótárazás engedélyezése a böngészőbenAz emberek többségének az egyetlen módja A htaccess webhely gyorsítótárazása kód hozzáadása a webszerveren található .htaccess fájlhoz.
A .htaccess fájl sok mindent vezérel fontos beállításokat webhelyéhez.
A böngésző gyorsítótárazása .htaccess fájlon keresztülAz alábbi kód megmondja a böngészőnek, hogy mit kell gyorsítótáraznia, és mennyi ideig kell "emlékeznie". Hozzá kell adni a .htaccess fájl tetejéhez:
## LEJÁRA A GYORSÍTÁSRA ## ExpiresActive On ExpiresByType image/jpg "access 1 year" ExpiresByType image/jpeg "access 1 year" ExpiresByType image/gif "access 1 year" ExpiresByType image/png "access/accesss By. 1 hónap" ExpiresByType text/html "hozzáférés 1 hónap" ExpiresByType alkalmazás/pdf "hozzáférés 1 hónap" ExpiresByType szöveg/x-javascript "hozzáférés 1 hónap" ExpiresByType alkalmazás/x-shockwave-flash "hozzáférés 1 hónap" Lejárat B-xy ikon "hozzáférés 1 év" LejárAlapértelmezett "hozzáférés 1 hónap" ## A GYORSÍTÁS LEJÁRA ##
Mentse el a .htaccess fájlt, majd frissítse a weboldalt.
A gyorsítótár idők beállítása a különböző fájltípusokhozA fenti kódban az időintervallumok vannak beállítva. Például 1 év (1 év) vagy 1 hónap (1 hónap). Fájltípusokhoz vannak társítva. A fenti kód kimondja, hogy a .jpg fájlokat (képeket) egy évig gyorsítótárban kell tárolni.
Ha ezt úgy szeretné megváltoztatni, hogy a JPG-képek is gyorsítótárban legyenek egy hónapig, akkor egyszerűen cserélje le az „1 évet” az „1 hónap”-ra. A fenti htaccess gyorsítótárazási értékek a legtöbb weboldalhoz optimálisak.
Alternatív gyorsítótárazási módszer a .htaccess számáraA fent leírt módszert "Lejáratnak" hívják, ez segít a legtöbb kezdőnek a gyorsítótárazásban. Ha már megszokta a gyorsítótárazást, kipróbálhat egy másik gyorsítótárazási módszert, a Cache-Control-t, amely több lehetőséget kínál.
Lehetséges, hogy az Expires metódus nem működik a kiszolgálón, ebben az esetben érdemes megpróbálni a Cache-Control használatával.
Cache-ControlEzzel a módszerrel jobban ellenőrizheti a böngésző oldalak gyorsítótárazását, de sokan könnyebben egyszer írják le az összes beállítást.
Használati példa a .htaccess fájlban:
# 1 hónap a legtöbb statikus eszközhöz Fejléckészlet Cache-Control "max-age=2592000, public"
A fenti kód beállítja a Cache-Control fejlécet a fájltípustól függően.
Hogyan működik a gyorsítótár-vezérlésTekintsük a böngésző gyorsítótárazási kódjának fenti sorát a htaccess-ben:
#1 hónap a legtöbb statikus eszköz számára
Ez a sor csak egy megjegyzés. A .htaccess fájl figyelmen kívül hagyja a # karakterrel kezdődő sorokat. Ez a megjegyzés azért ajánlott, mert előfordulhat, hogy több különböző adatkészletet használhat fájlok gyorsítótárazási megoldásaként:
A fent említett sor azt mondja, hogy "ha a fájl ilyen típusú, akkor csinálunk vele valamit..."
A legfontosabb dolog ebben a sorban az, hogy felsorol Különféle típusok fájlokat (CSS , JS , JPEG , PNG stb.), és hogy a gyorsítótárazási utasításokat alkalmazni kell ezekre a fájltípusokra. Ha például nem szeretné, hogy a JPG fájlok egy meghatározott ideig gyorsítótárban legyenek, törölheti a „JPG” fájlt. Ha HTML-t szeretne hozzáadni, akkor ebben a sorban meg kell adnia a "HTML"-t:
Fejléckészlet Cache-Control "max-age=2592000, public"
A fent említett sor a tényleges fejléceket és értékeket tartalmazza:
Ez a htaccess-en keresztüli gyorsítótárazási sor bezárja az utasítást és befejezi a kódblokkot.
Általános gyorsítótárazási problémaHa olyan képeket ad meg, amelyeket egy évig vagy tovább gyorsítótárban tárolunk, ne feledje, hogy ha módosítja oldalait, előfordulhat, hogy nem minden felhasználó láthatja azokat. Mivel a felhasználók a gyorsítótárazott fájlokra hivatkoznak, nem a meglévőkre. Ha van egy fájlja, amelyet rendszeresen szerkeszt (például egy CSS-fájl), akkor az URL-ujjlenyomattal megoldhatja a gyorsítótár-problémát.
URL ujjlenyomatÚj (nem gyorsítótárazott) fájlerőforrás beszerzése lehetséges, ha egyedi név van. Például, ha a CSS-fájl neve „main.css”, akkor helyette „main_1.css”-nek nevezhetjük. Amikor legközelebb megváltoztatjuk a nevét, a fájlt "main_2.css"-nek nevezhetjük el. Ez olyan fájlok esetén hasznos, amelyek rendszeresen változnak.
A megfelelően konfigurált gyorsítótárazás hatalmas teljesítménynövekedést biztosít, sávszélességet takarít meg, és csökkenti a szerverköltségeket, de sok webhely nem valósítja meg megfelelően a gyorsítótárazást, ami versenyhelyzetet teremt, ami miatt az összekapcsolt erőforrások nem szinkronizálódnak.
A gyorsítótárazási bevált gyakorlatok túlnyomó többsége a következő két minta egyikébe esik:
1. minta: Változatlan tartalom és hosszú gyorsítótár max-age Cache-Control: max-age=31536000Oldal: Szia, szükségem van "/script-v1.js" , "/styles-v1.css" és "/cats-v1.jpg" 10:24
Cash: Üres vagyok, mi van veled, kiszolgáló? 10:24
Szerver: Rendben, itt vannak. Mellesleg, Cash, egy évig kellene őket használni, nem tovább. 10:25
Készpénz: Pss! 10:25
Oldal: Hurrá! 10:25
A következő nap
Oldal: Szia, szükségem van "/script-v2 .js" , "/styles-v2 .css" és "/cats-v1.jpg" 08:14
Cash: Van egy kép macskákkal, a többi nem. Szerver? 08:14
Szerver: Egyszerű – ennyi új css&js. Még egyszer Cash: nem bírják tovább egy évnél. 08:15
Cash: Remek! 08:15
Oldal: Köszönöm! 08:15
Gyorsítótár: Hmm, már jó ideje nem használtam a "/script-v1.js" és a "/styles-v1.css" fájlokat. Ideje eltávolítani őket. 12:32
Ezzel a mintával soha nem módosítja egy adott URL tartalmát, hanem magát az URL-t:
Minden URL-nek van valami, ami a tartalommal együtt változik. Ez lehet egy verziószám, egy módosított dátum vagy a tartalom hash-je (ezt a lehetőséget választottam a blogomhoz).
A legtöbb szerveroldali keretrendszer rendelkezik olyan eszközökkel, amelyek megkönnyítik az ilyesmit (én a Manifest Static Files Storage-ot használom a Django-ban); A Node.js-ben nagyon kicsi könyvtárak is vannak, amelyek ugyanezt teszik, például a gulp-rev .
Ez a minta azonban nem alkalmas cikkekhez és blogbejegyzésekhez. URL-jeik nem verziózhatók, és tartalmuk változhat. Komolyan mondom, gyakran vannak nyelvtani és központozási hibáim, ezért szükségem van a tartalom gyors frissítésének képességére.
2. minta: a változtatható tartalom mindig újra érvényesül a szerveren Cache-Control: nincs gyorsítótárOldal: Hé, szükségem van a "/about/" és a "/sw.js" tartalmára 11:32
Cash: Nem tehetek róla. Szerver? 11:32
Szerver: Vannak. Készpénz, tartsa magánál, de használat előtt kérdezze meg. 11:33
Cash: Így van! 11:33
Oldal: ATP! 11:33
A következő nap
Oldal: Hé, megint "/about/" és "/sw.js" tartalomra van szükségem 09:46
Készpénz: Várj egy percet. Szerver, a másolataim rendben vannak? A „/about/” egy példánya hétfői, a „/sw.js” pedig tegnapi. 09:46
Szerver: "/sw.js" nem változott… 09:47
Készpénz: Jó. oldal, tartsa meg a "/sw.js" fájlt. 09:47
Szerver: ...de van "/about/" új verzió. Készpénz, tartsa meg, de csakúgy, mint legutóbb, először ne felejtsen el megkérdezni. 09:47
Cash: Értem! 09:47
Oldal: Kiváló! 09:47
Megjegyzés: a no-cache nem azt jelenti, hogy „ne gyorsítótárazzon”, hanem azt, hogy „ellenőrizze” (vagy érvényesítse újra) a gyorsítótárazott erőforrást a szerverről. A gyorsítótárazás helyett a böngésző a no-store parancsot rendeli el. A must-revalidate továbbá nem kötelező újraellenőrzést jelent, hanem azt, hogy a gyorsítótárazott erőforrás csak akkor kerül felhasználásra, ha fiatalabb, mint a megadott max-age , és csak egyébként érvényesítik újra. Így kezdődött minden kulcsszavakat gyorsítótárazáshoz.
Ebben a mintában hozzáadhatunk egy ETag-et (az Ön által választott verzióazonosító) vagy egy Last-Modified fejlécet a válaszhoz. A következő alkalommal, amikor a kliens kéri a tartalmat, az If-None-Match vagy If-Modified-Since kimenet jelenik meg, lehetővé téve a szerver számára, hogy azt mondja: „Használja, ami van, a gyorsítótár naprakész”, azaz HTTP-t küld vissza. 304.
Ha az ETag / Last-Modified küldése nem lehetséges, a szerver mindig a teljes tartalmat küldi el.
Ez a minta mindig hálózati kéréseket igényel, így nem olyan jó, mint az első minta, amely hálózati kérések nélkül is megoldható.
Nem ritka, ha nem rendelkezünk az első mintához szükséges infrastruktúrával, de ugyanilyen valószínű, hogy problémái vannak a 2. mintában lévő hálózati kérésekkel. Ennek eredményeként egy köztes opciót használnak: egy rövid max-age és változtatható tartalom. Ez egy rossz kompromisszum.
A maximális életkor változó tartalommal történő használata általában rossz választás.És sajnos gyakori, a Github oldalakat lehet példaként felhozni.
Képzeld el:
Szerver fejléccel:
Cache-Control: újra kell érvényesíteni, max-age=600
Oldal: Hé, szükségem van "/article/" , "/script.js" és "/styles.css" 10:21
Cash: Nincs hozzád hasonlóm, szerver? 10:21
Szerver: Semmi gond, itt vannak. De ne feledje, Cash, a következő 10 percen belül felhasználhatók. 10:22
Készpénz: Igen! 10:22
Oldal: ATP! 10:22
Oldal: Hé, újra kell "/article/" , "/script.js" és "/styles.css" 10:28
Gyorsítótár: Hoppá, sajnálom, de elvesztettem a "/styles.css" fájlt, de minden más megvan, tartsa meg. Szerver, be tudod illeszteni nekem a "/styles.css" fájlt? 10:28
Szerver: Nyugi, már megváltozott, mióta legutóbb elvitted. Biztonságosan használhatja a következő 10 percben. 10:29
Készpénz: Semmi gond. 10:29
Oldal: Köszönöm! De úgy tűnik, valami elromlott! Minden elromlott! Mi folyik itt? 10:29
Ennek a mintának joga van az élethez a tesztelés során, de egy valódi projektben mindent megtör, és nagyon nehéz nyomon követni. A fenti példában a szerver frissítette a HTML-t, a CSS-t és a JS-t, de az oldal a gyorsítótárból a régi HTML-lel és JS-vel, valamint a szerver frissített CSS-jével jelenik meg. A verziók közötti eltérés mindent tönkretesz.
Amikor jelentős változtatásokat végzünk a HTML-ben, gyakran módosítjuk a CSS-t is, hogy megfelelően tükrözze az új struktúrát, és a JavaScriptet is, hogy lépést tudjunk tartani a tartalommal és a stílusokkal. Mindezek az erőforrások függetlenek, de a gyorsítótárazási fejlécek ezt nem tudják kifejezni. Ennek eredményeként a felhasználók rendelkezhetnek legújabb verzió egy/két erőforrás és a többi régi verziója.
A max-age a válaszidőhöz viszonyított, tehát ha minden erőforrást ugyanannak a címnek a részeként küldenek el, akkor azok egyszerre járnak le, de még mindig van egy kis esély a deszinkronizálásra. Ha olyan oldalai vannak, amelyek nem tartalmaznak JavaScriptet, vagy más stílusokat tartalmaznak, a gyorsítótár lejárati dátuma nem lesz szinkronban. És ami még rosszabb, a böngésző folyamatosan húzza ki a tartalmat a gyorsítótárból, nem tudja, hogy a HTML, CSS és JS kölcsönösen függenek egymástól, így boldogan kihúzhat egyet a listából, és minden mást elfelejthet. Mindezen tényezők együttes figyelembevételével meg kell értenie, hogy az össze nem illő verziók valószínűsége meglehetősen magas.
A felhasználó számára az eredmény hibás oldalelrendezés vagy egyéb probléma lehet. Az apró hibáktól a teljesen használhatatlan tartalomig.
Szerencsére a felhasználóknak van vészkijáratuk...
Az oldal frissítése néha segítHa az oldal frissítéssel töltődik be, a böngészők mindig szerveroldali újraellenőrzést végeznek, figyelmen kívül hagyva a max-age értéket. Ezért ha valami elromlik a felhasználónak a max-age miatt, akkor egy egyszerű oldalfrissítés mindent megjavíthat. De természetesen a kanalak megtalálása után az üledék továbbra is megmarad, és a webhelyhez való hozzáállás némileg eltérő lesz.
A szervizmunkás meghosszabbíthatja ezeknek a hibáknak az élettartamátPéldául van egy ilyen szervizmunkásod:
constversion="2"; self.addEventListener("telepítés", esemény => ( event.waitUntil(caches.open(`static-$(verzió)`)) .then(cache => cache.addAll([ "/styles.css", "/script .js" ])))); )); self.addEventListener("aktiválás", event => ( // …régi gyorsítótárak törlése… )); self.addEventListener("fetch", event => ( event.respondWith(caches.match(event.request) .then(response => response || fetch(event.request))); ));
Ez a szervizmunkás:
Ha megváltoztatjuk a CSS/JS-t, akkor a verziószámot is növeljük, ami frissítést indít el. Mivel azonban az addAll először éri el a gyorsítótárat, versenyhelyzetbe kerülhetünk a max-age és a nem megfelelő CSS és JS verziók miatt.
Amint gyorsítótárba kerültek, inkompatibilis CSS- és JS-ünk lesz a szervizmunkás következő frissítéséig – és ez akkor van, ha a frissítés során nem kerülünk ismét versenyhelyzetbe.
A gyorsítótárazást kihagyhatja a szervizmunkásban:
Self.addEventListener("install", event => ( event.waitUntil(caches.open(`static-$(verzió)`)) .then(cache => cache.addAll([ new Request("/styles.css", ( cache: "no-cache" )), new Request("/script.js", ( cache: "no-cache" )) ]))); ));
Sajnos a gyorsítótárazási beállításokat a Chrome/Opera nem támogatja, és csak most adták hozzá a Firefox éjszakai buildjéhez, de ezt saját maga is megteheti:
Self.addEventListener("install", event => ( event.waitUntil(caches.open(`static-$(verzió)`)) .then(cache => Promise.all([ "/styles.css", "/script .js" ].map(url => ( // cache-bust véletlenszerű lekérdezési karakterlánc használatával return fetch(`$(url)?$(Math.random())`).then(response => ( // sikertelen 404-en, 500-on stb if (!response.ok) throw Error("Not ok"); return cache.put(url, response); )) ))))))));
Ebben a példában a gyorsítótárat ezzel ürítem ki véletlen szám, de továbbléphetsz, és hozzáadhatsz egy tartalomkivonatot a buildhez (ez hasonló ahhoz, amit az sw-precache csinál). Ez az első minta egyfajta megvalósítása JavaScript használatával, de csak a szervizmunkással működik, böngészőkkel és CDN-ekkel nem.
A szervizmunkások és a HTTP-gyorsítótár remekül működnek együtt, ne kényszerítsd őket verekedésre!Amint látja, megkerülheti a szervizmunkás gyorsítótárazási hibáit, de jobb, ha kijavítja a probléma gyökerét. A gyorsítótárazás megfelelő konfigurálása nemcsak a szervizmunkás munkáját könnyíti meg, hanem a szervizmunkásokat nem támogató böngészőknek is (Safari, IE/Edge), és lehetővé teszi, hogy a legtöbbet hozza ki a CDN-ből.
A megfelelő gyorsítótárazási fejlécek a szervizmunkás frissítését is sokkal könnyebbé tehetik.
constversion="23"; self.addEventListener("telepítés", event => ( event.waitUntil(caches.open(`static-$(verzió)`)) .then(cache => cache.addAll([ "/", "/script-f93bca2c. js", "/styles-a837cb1e.css", "/cats-0e9a2ef4.jpg" ])))); ));
Itt gyorsítótáraztam a gyökéroldalt a 2. mintával (szerveroldali újraellenőrzés), az összes többi erőforrást pedig az 1. mintával (változatlan tartalom). A szervizmunkás minden frissítése kérést küld a gyökéroldalnak, és az összes többi erőforrás csak akkor töltődik be, ha megváltozik az URL-címük. Ez azért jó, mert forgalmat takarít meg és javítja a teljesítményt, függetlenül attól, hogy frissít egy korábbiról vagy nagyon régi verzió.
Jelentős előnye van itt a natív implementációval szemben, amikor a teljes binárist kis változtatással is letölti, vagy a bináris fájlok összetett összehasonlítását okozza. Így tudunk egy nagy webalkalmazást viszonylag kis terheléssel frissíteni.
A szervizmunkások jobban dolgoznak továbbfejlesztésként, nem pedig ideiglenes mankóként, ezért a gyorsítótárral dolgozzanak ahelyett, hogy harcolnának ellene.
Óvatos használat esetén a max-age és a változtatható tartalom nagyon szép lehet.A max-age nagyon gyakran rossz választás a változtatható tartalomhoz, de nem mindig. Például az eredeti cikk maximális korhatára három perc. A versenyfeltételek nem jelentenek problémát, mivel az oldalon nincsenek függőségek ugyanazt a gyorsítótárazási mintát használva (CSS, JS és képek az 1-es mintát használják - megváltoztathatatlan tartalom), minden más nem ezt a mintát használja.
Ez a minta azt jelenti, hogy nyugodtan írhatok egy népszerű cikket, és a CDN-em (Cloudflare) le tudja venni a terhelést a szerverről, ha természetesen hajlandó vagyok három percet várni, amíg a frissített cikk megjelenik. elérhető a felhasználók számára.
Ezt a mintát fanatizmus nélkül kell használni. Ha új szakaszt adok egy cikkhez, és egy másik cikkből hivatkozom rá, akkor létrehoztam egy függőséget, amelyet meg kell oldani. A felhasználó rákattinthat a hivatkozásra, és másolatot kaphat a cikkről a kívánt rész nélkül. Ha ezt el akarom kerülni, frissítenem kell a cikket, törölnöm kell a cikk Cloudflare gyorsítótárazott verzióját, várnom kell három percet, és csak ezután kell hozzáadnom a hivatkozást egy másik cikkhez. Igen, ez a minta óvatosságot igényel.
Helyes használat esetén a gyorsítótárazás jelentős teljesítménynövekedést és forgalommegtakarítást eredményez. Adjon át változatlan tartalmat, ha könnyen módosíthatja az URL-t, vagy használjon szerveroldali újraérvényesítést. Keverje össze a maximális korhatárt és a változtatható tartalmat, ha elég bátor ahhoz, hogy megbizonyosodjon arról, hogy tartalmaiban nincsenek olyan függőségek, amelyek kiléphetnek a szinkronból.
