Iekļaujot ārējos CSS un Javascript, mēs vēlamies līdz minimumam samazināt nevajadzīgos HTTP pieprasījumus.

Šim nolūkam .js un .css faili tiek apkalpoti ar galvenēm, kas nodrošina drošu kešatmiņu.

Bet ko jūs darāt, ja izstrādes laikā kāds no šiem failiem mainās? Visiem lietotājiem tas ir kešatmiņā vecā versija- kamēr kešatmiņa nav novecojusi, būs daudz sūdzību par servera un klienta daļu integrācijas traucējumiem.

Pareiza kešatmiņa un versiju izveide pilnībā novērš šo problēmu un nodrošina uzticamu, caurspīdīgu stila/skriptu versiju sinhronizāciju.

Vienkārša ETag kešatmiņa

Vienkāršākais veids, kā saglabāt statiskos resursus kešatmiņā, ir izmantot ETag.

Pietiek iespējot atbilstošo servera iestatījumu (Apache tas ir iespējots pēc noklusējuma) - un katram failam galvenēs tiks piešķirts ETag - hash, kas ir atkarīgs no atjaunināšanas laika, faila lieluma un (pamatojoties uz inode failu sistēmas) inode.

Pārlūkprogramma saglabā šādu failu kešatmiņā un pēc turpmākiem pieprasījumiem norāda If-None-Match galveni ar kešatmiņā saglabātā dokumenta ETag. Saņemot šādu galveni, serveris var atbildēt ar kodu 304 - un tad dokuments tiks izņemts no kešatmiņas.

Tas izskatās šādi:

Pirmais pieprasījums serverim (kešatmiņas tīrīšana) GET /misc/pack.js HTTP/1.1 Host: vietne

Parasti pārlūkprogramma parasti pievieno virkni galvenes, piemēram, User-Agent, Accept utt. Tie ir sagriezti īsuma labad.

Servera atbilde Serveris atbild ar dokumentu ar kodu 200 un ETag: HTTP/1.x 200 OK Content-Encoding: gzip Content-Type: text/javascript; charset=utf-8 Etag: "3272221997" Pieņemt diapazoni: baiti Satura garums: 23321 Datums: piektdien, 2008. gada 2. maijā 17:22:46 GMT Serveris: lighttpd Nākamais pārlūkprogrammas pieprasījums Pēc nākamā pieprasījuma pārlūkprogramma pievieno If-None -Atbilstība: (kešatmiņā saglabāts ETag): GET /misc/pack.js HTTP/1.1 Host: vietne If-None-Match: "453700005" Servera atbilde Servera izskats - jā, dokuments nav mainījies. Tas nozīmē, ka varat izsniegt 304 kodu un nesūtīt dokumentu atkārtoti. HTTP/1.x 304 nav modificēts satura kodējums: gzip Etag: "453700005" Satura veids: teksts/javascript; charset=utf-8 Pieņemt diapazoni: baiti Datums: otrdien, 2008. gada 15. aprīlī 10:17:11 GMT

Alternatīva iespēja- ja dokuments ir mainījies, tad serveris vienkārši nosūta 200 ar jauno ETag.

Kombinācija Pēdējoreiz modificēts + Ja-Modified-Since darbojas līdzīgi:

serveris nosūta pēdējās modifikācijas datumu galvenē Last-Modified (ETag vietā)

pārlūkprogramma saglabā dokumentu kešatmiņā, un nākamreiz, kad tiek veikts pieprasījums par to pašu dokumentu, tā nosūta kešatmiņā saglabātās versijas datumu galvenē If-Modified-Since (nevis If-None-Match)

serveris pārbauda datumus un, ja dokuments nav mainījies, nosūta tikai 304 kodu, bez satura.

Šīs metodes darbojas droši un labi, taču pārlūkprogrammai joprojām ir jāiesniedz pieprasījums katram skriptam vai stilam.

Viedā kešatmiņa. Versionēšana

Vispārējā pieeja versiju veidošanai - īsumā:

Versija (vai modifikācijas datums) tiek pievienota visiem skriptiem. Piemēram, http://site/my.js kļūs par http://site/my.v1.2.js

Visus skriptus pārlūkprogramma saglabā kešatmiņā

Atjauninot skriptu, versija tiek mainīta uz jaunu: http://site/my.v2.0.js

Adrese ir mainīta, tāpēc pārlūkprogramma vēlreiz pieprasīs un saglabās failu kešatmiņā

Vecā versija 1.2 pakāpeniski izkritīs no kešatmiņas

Cieta kešatmiņa

Cieta kešatmiņa- sava veida āmurs, kas pilnībā pienaglo serverim kešatmiņā saglabāto dokumentu pieprasījumus.

Lai to izdarītu, vienkārši pievienojiet galvenes Expires un Cache-Control: max-age.

Piemēram, lai kešatmiņā saglabātu 365 dienas PHP:

Header("Expires: ".gmdate("D, d M Y H:i:s", time()+86400*365)." GMT"); header("Cache-Control: max-age="+86400*365);

Vai arī varat pastāvīgi saglabāt saturu kešatmiņā, izmantojot mod_header programmā Apache:

Saņemot šādas galvenes, pārlūkprogramma ilgstoši saglabā dokumentu kešatmiņā. Visa turpmākā piekļuve dokumentam tiks nodrošināta tieši no pārlūkprogrammas kešatmiņas, nesazinoties ar serveri.

Lielākā daļa pārlūkprogrammu (Opera, Internet Explorer 6+, Safari) NEDRĪKST kešatmiņā saglabāt dokumentus, ja adresē ir jautājuma zīme, jo tie tiek uzskatīti par dinamiskiem.

Tāpēc mēs pievienojam versiju faila nosaukumam. Protams, ar šādām adresēm jums ir jāizmanto tāds risinājums kā mod_rewrite, mēs to aplūkosim vēlāk rakstā.

P.S Bet Firefox kešatmiņā saglabā adreses ar jautājuma zīmēm...

Automātiska nosaukuma izšķirtspēja

Apskatīsim, kā automātiski un pārskatāmi mainīt versijas, nepārdēvējot pašus failus.

Nosaukums ar versiju -> Fails

Visvienkāršākā lieta ir pārvērst nosaukumu ar versiju sākotnējā faila nosaukumā.

Apache līmenī to var izdarīt ar mod_rewrite:

RewriteEngine uz RewriteRule ^/(.*\.)v+\.(css|js|gif|png|jpg)$ /$1$2 [L]

Šī kārtula apstrādā visus css/js/gif/png/jpg failus, noņemot versiju no nosaukuma.

Piemēram:

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

Bet ne tikai versijas izgriešanai, bet arī failiem jāpievieno cietās kešatmiņas galvenes. Šim nolūkam tiek izmantotas mod_header direktīvas:

Virsraksta pievienošana "Derīguma termiņš"

Un kopā tas ievieš šādu Apache konfigurāciju:

RewriteEngine on # noņem versiju un tajā pašā laikā iestata mainīgo, ka failam ir versijas RewriteRule ^/(.*\.)v+\.(css|js|gif|png|jpg)$ /$1$2 # cietā kešatmiņa versijas faili Galvenes pievienošana "Derīguma termiņš" "Pr, 2014. gada 28. jūlijs 23:30:00 GMT" env=VERSIONED_FILE Galvene pievienot "Cache-Control" "max-age=315360000" env=VERSIONED_FILE

Sakarā ar mod_rewrite moduļa darbības veidu, RewriteRule ir jāievieto galvenajā konfigurācijas fails httpd.conf vai iekļautos failus, bet nekad .htaccess , pretējā gadījumā vispirms tiks izpildītas Header komandas, pirms tiek iestatīts mainīgais VERSIONED_FILE.

Galvenes direktīvas var būt jebkur, pat .htaccess — tam nav nozīmes.

Automātiski pievienojot versiju faila nosaukumam HTML lapā

Tas, kā ievietot versiju skripta nosaukumā, ir atkarīgs no jūsu veidņu sistēmas un kopumā no skriptu pievienošanas veida (stilus utt.).

Piemēram, izmantojot modifikācijas datumu kā versiju un Smarty veidņu dzinēju, saites var iestatīt šādi:

Versijas funkcija pievieno versiju:

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

Rezultāts lapā:

Optimizācija

Lai izvairītos no nevajadzīgiem statistikas izsaukumiem, atsevišķā mainīgā varat saglabāt masīvu ar pašreizējo versiju sarakstu

$versions["css"] = masīvs("group.css" => "1.1", "other.css" => "3.0", )

Šajā gadījumā pašreizējā masīva versija tiek vienkārši aizstāta ar HTML.

Varat šķērsot abas pieejas un izstrādes laikā izveidot versiju pēc modifikācijas datuma — atbilstības labad, bet ražošanā — versiju no masīva veiktspējai.

Piemērojamība

Šī kešatmiņas metode darbojas visur, ieskaitot Javascript, CSS, attēlus, Flash filmas utt.

Tas ir noderīgi ikreiz, kad dokuments tiek mainīts, taču pārlūkprogrammai vienmēr jābūt jaunākajai versijai.

Kešatmiņai ir svarīga loma gandrīz jebkuras tīmekļa lietojumprogrammas darbībā darba ar datu bāzēm, tīmekļa serveriem un arī klienta līmenī.

Šajā rakstā mēs centīsimies izprast klienta kešatmiņu. Jo īpaši mēs apskatīsim, kādas HTTP galvenes izmanto pārlūkprogrammas un tīmekļa serveri un ko tās nozīmē.

Bet vispirms noskaidrosim, kāpēc klienta puses kešatmiņa vispār ir nepieciešama? .

Tīmekļa lapas sastāv no daudzām dažādi elementi: attēli, css un js faili utt. Daži no šiem elementiem tiek izmantoti vairākās (daudzās) vietnes lapās. Klienta puses kešatmiņa attiecas uz pārlūkprogrammu spēju saglabāt failu kopijas (servera atbildes), lai tās vairs nelejupielādētu. Tas ļauj ievērojami paātrināt lapas atkārtotu ielādi, ietaupīt trafiku un arī samazināt servera slodzi.

Ir vairākas dažādas HTTP galvenes, lai kontrolētu klienta puses kešatmiņas procesus. Parunāsim par katru no tiem.

Http galvenes, lai kontrolētu klienta kešatmiņu

Vispirms apskatīsim, kā serveris un pārlūkprogramma mijiedarbojas, ja nav kešatmiņas. Skaidras izpratnes labad es mēģināju iztēloties un vizualizēt viņu savstarpējās komunikācijas procesu teksta tērzēšanas veidā. Uz dažām minūtēm iedomājieties, ka serveris un pārlūkprogramma ir cilvēki, kas saraksti viens ar otru :)

Bez kešatmiņas (ja nav kešatmiņas http galvenes)

Kā redzam, katru reizi, kad tiek parādīts cat.png attēls, pārlūkprogramma to atkal lejupielādēs no servera. Es domāju, ka nav nepieciešams skaidrot, ka tas ir lēns un neefektīvs.

Pēdējā modificētā atbildes galvene un pieprasījuma galvene “Modified-Since”.

Ideja ir tāda, ka serveris failam (atbildei), ko tas sniedz pārlūkprogrammai, pievieno galveni Last-modified.

Tagad pārlūkprogramma zina, ka fails tika izveidots (vai pārveidots) 2014. gada 1. decembrī. Nākamreiz, kad pārlūkprogrammai būs nepieciešams tas pats fails, tas nosūtīs pieprasījumu ar galveni if-Modified-Since.

Ja fails nav modificēts, serveris pārlūkprogrammai nosūta tukšu atbildi ar statusu 304 (Nav modificēts). Šādā gadījumā pārlūkprogramma zina, ka fails nav atjaunināts, un var parādīt pēdējo reizi saglabāto kopiju.

Tādējādi, izmantojot Last-modified, mēs ietaupām uz ielādi liels fails, izkāpjot ar tukšu ātru atbildi no servera.

Etag atbildes galvene un pieprasījuma galvene If-None-Match.

Etag darbības princips ir ļoti līdzīgs Last-modified, taču atšķirībā no tā tas nav saistīts ar laiku. Laiks ir relatīva lieta.

Ideja ir tāda, ka, kad tas tiek izveidots un katru reizi, kad tas mainās, serveris atzīmē failu ar īpašu tagu, ko sauc par ETag, kā arī pievieno failam (atbildei) galveni, ko tas nosūta pārlūkprogrammai:

ETag: "686897696a7c876b7e"

Tagad pārlūkprogramma zina, ka pašreizējās versijas failam ir ETag, kas vienāds ar “686897696a7c876b7e”. Nākamreiz, kad pārlūkprogrammai būs nepieciešams tas pats fails, tā nosūtīs pieprasījumu ar galveni If-None-Match: "686897696a7c876b7e" .

Ja — nav — atbilst: "686897696a7c876b7e"

Serveris var salīdzināt etiķetes un, ja fails nav modificēts, nosūtīt pārlūkprogrammai tukšu atbildi ar statusu 304 (Nav modificēts). Tāpat kā ar pēdējo modificēto versiju, pārlūkprogramma noskaidros, ka fails nav atjaunināts, un varēs parādīt kopiju no kešatmiņas.

Nosaukums beidzies

Šīs galvenes darbības princips atšķiras no iepriekš aprakstītā Etag un Last-modified. Izmantojot Expired, tiek noteikts faila “derīguma termiņš” (“atbilstības periods”). Tie. Pirmajā ielādes reizē serveris dara zināmu pārlūkprogrammai, ka tas neplāno mainīt failu līdz datumam, kas norādīts sadaļā Expired:

Nākamajā reizē pārlūkprogramma, zinot, ka “derīguma termiņš” vēl nav pienācis, pat nemēģinās veikt pieprasījumu serverim un parādīs failu no kešatmiņas.

Šāda veida kešatmiņa ir īpaši svarīga rakstu ilustrācijām, ikonām, faviconiem, dažiem css un js failiem utt.

Kešatmiņas kontroles galvene ar maksimālā vecuma direktīvu.

Cache-control darbības princips: max-age ir ļoti līdzīgs Expired. Šeit tiek noteikts arī faila “derīguma termiņš”, taču tas tiek iestatīts sekundēs un nav piesaistīts konkrētam laikam, kas vairumā gadījumu ir daudz ērtāk.

Uzziņai:

• 1 diena = 86400 sekundes
• 1 nedēļa = 604800 sekundes
• 1 mēnesis = 2629000 sekundes
• 1 gads = 31536000 sekundes

Piemēram:

Kešatmiņas kontrole: max-age=2629000;

Kešatmiņas vadības galvenē ir ne tikai maksimālais vecums, bet arī citas direktīvas. Īsi apskatīsim populārākos:

publiski
Fakts ir tāds, ka pieprasījumus kešatmiņā var saglabāt ne tikai lietotāja gala klients (pārlūks), bet arī dažādi starpniekserveri, CDN tīkli utt. Tātad publiskā direktīva ļauj absolūti jebkuram starpniekserverim veikt kešatmiņu tāpat kā pārlūkprogrammā.

Privāts
Direktīvā ir teikts, ka šo failu(servera atbilde) ir atkarīgs no galalietotāja, un to nevajadzētu saglabāt kešatmiņā ar dažādiem starpniekserveriem. Tajā pašā laikā tas ļauj saglabāt kešatmiņu gala klientam (lietotāja pārlūkprogrammai). Piemēram, tas attiecas uz iekšējām lietotāja profila lapām, pieprasījumiem sesijas laikā utt.

Ļauj norādīt, ka klientam katru reizi ir jāiesniedz pieprasījums serverim. Dažreiz tiek izmantots kopā ar iepriekš aprakstīto Etag galveni.

bez veikala
Norāda klientam, ka tas nekādā gadījumā nedrīkst paturēt pieprasījuma kopiju vai pieprasījuma daļas. Šī ir visstingrākā galvene, kas ignorē visas kešatmiņas. Tas tika izgudrots īpaši darbam ar konfidenciālu informāciju.

obligāti jāapstiprina
Šī direktīva uzdod pārlūkprogrammai veikt obligātu pieprasījumu serverim, lai atkārtoti apstiprinātu saturu (piemēram, ja izmantojat eTag). Fakts ir tāds, ka http noteiktā konfigurācijā ļauj kešatmiņā saglabāt saturu, kas jau ir novecojis. must-revalidate uzliek pārlūkprogrammai pienākumu jebkurā gadījumā pārbaudīt satura svaigumu, iesniedzot pieprasījumu serverim.

starpniekserveris atkārtoti apstiprināt
Tas ir tas pats, kas obligāti jāvalidē, bet attiecas tikai uz kešatmiņas starpniekserveriem.

s-maksāža
Praktiski neatšķiras no max-age , izņemot to, ka šo direktīvu ņem vērā tikai dažādu starpniekserveru kešatmiņa, bet ne pati lietotāja pārlūkprogramma. Burts “s -” nāk no vārda “koplietots” (piemēram, CDN). Šī direktīva ir īpaši paredzēta CDN un citām starpnieku kešatmiņām. Norādot to, tiek ignorētas maksimālā vecuma direktīvas un galvenes Expired vērtības. Tomēr, ja neveidojat CDN tīklus, s-maxage diez vai kādreiz būs nepieciešams.

Kā es varu redzēt, kādas galvenes tiek izmantotas vietnē?

Varat skatīt http pieprasījumu galvenes un atbilžu galvenes savas iecienītākās pārlūkprogrammas atkļūdotājs. Tālāk ir sniegts piemērs tam, kā tas izskatās pārlūkā Chrome:

To pašu var redzēt jebkurā sevi cienošā pārlūkprogrammā vai http sniffer.

Kešatmiņas iestatīšana Apache un Nginx

Mēs nepārstāstīsim populāro serveru iestatīšanas dokumentāciju. Jūs vienmēr varat to noskatīties un. Tālāk mēs sniegsim dažus reālas dzīves piemērus, lai parādītu, kā izskatās konfigurācijas faili.

Piemērs Apache konfigurācijas lai kontrolētu Beidzas

Mēs iestatījām dažādus “derīguma termiņus”. dažādi veidi failus. Viens gads attēliem, viens mēnesis skriptiem, stiliem, PDF failiem un ikonām. Par visu pārējo – 2 dienas.

Derīgs pēc veida mēnesis" ExpiresByType lietojumprogramma/pdf "piekļuve plus 1 mēnesis" ExpiresByType teksts/x-javascript "piekļuve plus 1 mēnesis" ExpiresByType attēls/x-icon "piekļuve plus 1 gads" Derīguma termiņšNoklusējums "piekļuve plus 2 dienas"

Nginx konfigurācijas piemērs, lai kontrolētu Derīguma termiņu

Mēs iestatām dažādus “derīguma termiņus” dažāda veida failiem. Viena nedēļa attēliem, viena diena stiliem un skriptiem.

Servera ( #... atrašanās vieta ~* \.(gif|ico|jpe?g|png)(\?+)?$ ( derīguma termiņš beidzas 1 w; ) atrašanās vieta ~* \.(css|js)$ ( derīguma termiņš beidzas 1 d; ) #... )

Apache konfigurācijas piemērs kešatmiņas kontrolei (maksimālais vecums un publisks/privāts/bez kešatmiņas) Galvenes kopa Cache-Control "max-age=2592000, public" Header set Cache-Control "max-age=88000, private, must- atkārtoti apstiprināt" Galvenes kopa Kešatmiņas kontrole ( #... atrašanās vieta ~* \.(?:ico|css|js|gif|jpe?g|png)$ ( add_header Cache-Control "max-age=88000, public"; ) #... ) In secinājums

“Saglabāt kešatmiņā visu, ko var saglabāt kešatmiņā” ir labs tīmekļa izstrādātāja devīze. Dažreiz jūs varat pavadīt tikai dažas stundas konfigurēšanai un tajā pašā laikā ievērojami uzlabot vietnes lietošanas pieredzi, ievērojami samazināt servera slodzi un ietaupīt trafiku. Galvenais ir nepārspīlēt un iestatīt visu pareizi, ņemot vērā jūsu resursa īpašības.

Pareizi konfigurēta kešatmiņa nodrošina milzīgas veiktspējas priekšrocības, ietaupa joslas platumu un samazina servera izmaksas, taču daudzas vietnes slikti ievieš kešatmiņu, radot sacīkšu apstākļus, kas izraisa savstarpēji savienoto resursu sinhronizāciju.

Pārliecinošs vairākums labākā pieredze kešatmiņa attiecas uz vienu no diviem modeļiem:

Modelis Nr. 1: nemainīgs saturs un liela maksimālā vecuma kešatmiņa Kešatmiņas kontrole: max-age=31536000

• URL saturs nemainās, tāpēc...
• Pārlūkprogramma vai CDN var viegli saglabāt resursu kešatmiņā gadu
• Kešatmiņā saglabāto saturu, kas ir jaunāks par norādīto maksimālo vecumu, var izmantot bez konsultēšanās ar serveri

Lapa: Sveiki, man vajag "/script-v1.js" , "/styles-v1.css" un "/cats-v1.jpg" 10:24

Cash: Es esmu tukšs, kā ar tevi, serveri? 10:24

Serveris: Labi, šeit viņi ir. Starp citu, Cash, tos vajadzētu lietot gadu, ne vairāk. 10:25

Cash: Paldies! 10:25

Lapa: Urā! 10:25

Nākošajā dienā

Lapa: Sveiki, man vajag "/script-v2 .js" , "/styles-v2 .css" un "/cats-v1.jpg" 08:14

Skaidra nauda: Ir bilde ar kaķiem, bet ne pārējo. Serveris? 08:14

Serveris: vienkārši — šeit ir jaunais CSS un JS. Vēlreiz skaidra nauda: to glabāšanas laiks nav ilgāks par gadu. 08:15

Skaidra nauda: Lieliski! 08:15

Lapa: Paldies! 08:15

Skaidra nauda: Hmm, es ilgu laiku neesmu izmantojis "/script-v1.js" un "/styles-v1.css". Ir pienācis laiks tos noņemt. 12:32

Izmantojot šo modeli, jūs nekad nemaināt konkrēta URL saturu, jūs maināt pašu URL:

Katram URL ir kaut kas, kas mainās līdz ar saturu. Tas varētu būt versijas numurs, modificēts datums vai satura jaukts (to es izvēlējos savam emuāram).

Lielākajai daļai servera puses sistēmu ir rīki, kas ļauj viegli veikt šādas darbības (Django es izmantoju Manifest Static Files Storage); Node.js ir arī ļoti mazas bibliotēkas, kas atrisina tās pašas problēmas, piemēram, gulp-rev.

Tomēr šis modelis nav piemērots rakstiem un emuāra ziņām. Viņu vietrāžus URL nevar versēt, un to saturs var mainīties. Ja nopietni, man bieži ir gramatikas un pieturzīmju kļūdas, un man ir jāspēj ātri atjaunināt saturu.

Pattern #2: mainīgs saturs, kas vienmēr tiek pārbaudīts serverī Cache-Control: bez kešatmiņas

• Mainīsies URL saturs, kas nozīmē...
• Nevienu lokāli saglabāto versiju nevar izmantot, nenorādot serveri.

Lapa: Sveiki, man vajag "/about/" un "/sw.js" saturu 11:32

Cash: Es nevaru jums palīdzēt. Serveris? 11:32

Serveris: Ir daži. Skaidrā nauda, ​​turiet tos pie sevis, bet pirms lietošanas pajautājiet man. 11:33

Skaidra nauda: Tieši tā! 11:33

Lapa: Paldies! 11:33

Nākošajā dienā

Lapa: Sveiki, man atkal vajadzīgs "/about/" un "/sw.js" saturs 09:46

Skaidra nauda: tikai minūti. Server, vai manas kopijas ir kārtībā? "/about/" kopija ir no pirmdienas, bet "/sw.js" ir no vakardienas. 09:46

Serveris: "/sw.js" nav mainījies... 09:47

Skaidra nauda: Forši. Lapā saglabājiet "/sw.js" . 09:47

Serveris: … bet man ir “/about/” jauna versija. Nauda, ​​turiet to, bet tāpat kā pagājušajā reizē neaizmirstiet man vispirms pajautāt. 09:47

Cash: Sapratu! 09:47

Lapa: Lieliski! 09:47

Piezīme: bez kešatmiņas nenozīmē "neglabāt kešatmiņā", tas nozīmē "pārbaudīt" (vai atkārtoti apstiprināt) servera kešatmiņā saglabāto resursu. Un no-store liek pārlūkprogrammai vispār neveikt kešatmiņu. Turklāt obligāta atkārtota apstiprināšana nenozīmē obligātu atkārtotu validāciju, bet gan to, ka kešatmiņā esošais resurss tiek izmantots tikai tad, ja tas ir jaunāks par norādīto maksimālo vecumu , un tikai pretējā gadījumā tas tiek atkārtoti apstiprināts. Tā tas viss sākās atslēgvārdi kešatmiņai.

Šajā modelī atbildei varam pievienot ETag (versijas ID pēc jūsu izvēles) vai galveni Last-Modified. Nākamajā reizē, kad klients pieprasīs saturu, tiek izvadīts attiecīgi If-None-Match vai If-Modified-Since, ļaujot serverim pateikt “Izmantojiet to, kas jums ir, jūsu kešatmiņa ir atjaunināta”, t.i., atgriezt HTTP 304.

Ja nav iespējams nosūtīt ETag / Last-Modified, serveris vienmēr nosūta visu saturu.

Šim modelim vienmēr ir nepieciešami tīkla zvani, tāpēc tas nav tik labs kā pirmais modelis, kas var iztikt bez tīkla pieprasījumiem.

Nav nekas neparasts, ka mums nav infrastruktūras pirmajam modelim, taču var rasties problēmas ar tīkla pieprasījumiem modelī 2. Rezultātā tiek izmantota starpposma opcija: īss max-age un mainīgs saturs. Tas ir slikts kompromiss.

Maksimālā vecuma izmantošana ar mainīgu saturu parasti ir nepareiza izvēle

Un diemžēl tas ir izplatīts; Github lapas ir piemērs.

Iedomājieties:

• /raksts/
• /styles.css
• /script.js

Ar servera galveni:

Kešatmiņas kontrole: atkārtoti jāapstiprina, maksimālais vecums = 600

• URL satura izmaiņas
• Ja pārlūkprogrammai ir kešatmiņā saglabātā versija, kas ir jaunāka par 10 minūtēm, tā tiek izmantota bez konsultēšanās ar serveri
• Ja šādas kešatmiņas nav, tiek izmantots tīkla pieprasījums, ja iespējams ar If-Modified-Since vai If-None-Match

Lapa: Sveiki, man vajag "/article/", "/script.js" un "/styles.css" 10:21

Cash: Man nav nekā, tāpat kā tev, serveri? 10:21

Serveris: Nav problēmu, šeit viņi ir. Bet atcerieties, Cash: tos var izmantot nākamo 10 minūšu laikā. 10:22

Skaidra nauda: Jā! 10:22

Lapa: Paldies! 10:22

Lapa: Hei, man atkal vajag "/article/" , "/script.js" un "/styles.css" 10:28

Cash: Atvainojiet, bet es pazaudēju "/styles.css", bet man ir viss pārējais, lūk. Server, vai varat pielāgot failu "/styles.css" man? 10:28

Serveris: Viegli, viņš jau ir mainījies kopš pēdējās reizes, kad tu viņu paņēmi. Varat to droši lietot nākamās 10 minūtes. 10:29

Skaidra nauda: nav problēmu. 10:29

Lapa: Paldies! Bet šķiet, ka kaut kas nogāja greizi! Viss ir salauzts! Kas notiek? 10:29

Šim modelim ir tiesības uz dzīvību testēšanas laikā, taču tas salauž visu reālā projektā un ir ļoti grūti izsekot. Iepriekš minētajā piemērā serveris ir atjauninājis HTML, CSS un JS, bet lapa tiek renderēta ar veco kešatmiņā saglabāto HTML un JS, kā arī atjaunināto CSS no servera. Versiju neatbilstība visu sabojā.

Bieži vien, veicot būtiskas izmaiņas HTML, mēs mainām gan CSS, lai pareizi atspoguļotu jauno struktūru, gan JavaScript, lai neatpaliktu no satura un stila. Visi šie resursi ir neatkarīgi, taču kešatmiņas galvenes to nevar izteikt. Tā rezultātā lietotāji var atrast sevi jaunākā versija viens/divi resursi un pārējo vecā versija.

max-age ir iestatīts attiecībā pret reakcijas laiku, tādēļ, ja visi resursi tiek pārsūtīti kā daļa no vienas adreses, to derīguma termiņš beigsies vienlaikus, taču joprojām pastāv neliela desinhronizācijas iespēja. Ja jums ir lapas, kurās nav iekļauts JavaScript vai ir ietverti citi stili, to kešatmiņas derīguma termiņi netiks sinhronizēti. Un vēl ļaunāk, pārlūkprogramma pastāvīgi izvelk saturu no kešatmiņas, nezinot, ka HTML, CSS un JS ir savstarpēji atkarīgi, tāpēc tā var laimīgi izņemt vienu lietu no saraksta un aizmirst par visu pārējo. Apsverot visus šos faktorus kopā, jums vajadzētu saprast, ka neatbilstošu versiju iespējamība ir diezgan augsta.

Lietotājam rezultāts var būt bojāts lapas izkārtojums vai citas problēmas. No mazām kļūmēm līdz pilnīgi neizmantojamam saturam.

Par laimi lietotājiem ir avārijas izeja...

Dažkārt palīdz lapas atsvaidzināšana

Ja lapa tiek ielādēta atsvaidzinot, pārlūkprogrammas vienmēr veic servera puses atkārtotu validāciju, ignorējot maksimālo vecumu . Tāpēc, ja lietotājam kaut kas ir bojāts max-age dēļ, vienkārša lapas atsvaidzināšana var visu izlabot. Bet, protams, pēc tam, kad karotes ir atrastas, nogulsnes joprojām saglabāsies un attieksme pret jūsu vietni būs nedaudz atšķirīga.

Servisa darbinieks var pagarināt šo kļūdu kalpošanas laiku

Piemēram, jums ir šāds pakalpojumu darbinieks:

Const versija = "2"; self.addEventListener("install", event => ( event.waitUntil(caches.open(`static-$(version)`)) .then(cache => cache.addAll([ "/styles.css", "/script .js" ]))); )); self.addEventListener("aktivizēt", notikums => ( // ...dzēst vecās kešatmiņas... )); self.addEventListener("atnest", notikums => ( notikums.respondWith(caches.match(event.request) .then(response => response || fetch(event.request))); ));

Šis servisa darbinieks:

• kešatmiņas skripts un stili
• izmanto kešatmiņu, ja ir atbilstība, pretējā gadījumā piekļūst tīklam

Ja mainām CSS/JS, mēs palielināsim arī versijas numuru, kas aktivizē atjauninājumu. Tomēr, tā kā addAll vispirms piekļūst kešatmiņai, mēs varam nonākt sacensību stāvoklī maksimālā vecuma un neatbilstošu CSS un JS versiju dēļ.

Kad tie tiks saglabāti kešatmiņā, mums būs nesaderīgs CSS un JS līdz nākamajam servisa darbinieka atjauninājumam — ja vien atjaunināšanas laikā mēs atkal nenonāksim sacīkšu stāvoklī.

Varat izlaist kešatmiņu pakalpojumu darbiniekā:

Self.addEventListener("instalēt", notikums => ( event.waitUntil(caches.open(`static-$(version)`)) .then(cache => cache.addAll([ new Request("/styles.css", ( kešatmiņa: "no-cache" )), new Request("/script.js", ( cache: "no-cache" )) ]))); ));

Diemžēl pārlūkprogrammā Chrome/Opera netiek atbalstītas kešatmiņas iespējas, un tās ir tikko pievienotas Firefox nakts versijai, taču varat to izdarīt pats:

Self.addEventListener("install", event => ( event.waitUntil(caches.open(`static-$(version)`)) .then(cache => Promise.all([ "/styles.css", "/script" .js" ].map(url => ( // cache-bust, izmantojot nejaušu vaicājuma virkni return fetch(`$(url)?$(Math.random())`).then(response => ( // neizdodas uz 404, 500 utt if (!response.ok) throw Error("Nav ok"); return cache.put(url, response); )) ))))); ));

Šajā piemērā es atiestatīju kešatmiņu, izmantojot nejaušu skaitļu, bet jūs varat iet tālāk un pievienot satura jauktu, veidojot (tas ir līdzīgi tam, ko dara sw-precache). Tas ir sava veida pirmā modeļa ieviešana, izmantojot JavaScript, bet darbojas tikai ar pakalpojumu darbinieku, nevis pārlūkprogrammām un CDN.

Servisa darbinieki un HTTP kešatmiņa lieliski sadarbojas, nelieciet viņiem cīnīties!

Kā redzat, jūs varat apiet kešatmiņas kļūdas savā pakalpojumu darbiniekā, taču labāk ir atrisināt problēmas sakni. Pareizs iestatījums Kešatmiņa ne tikai atvieglo apkalpojošā darbinieka darbu, bet arī palīdz pārlūkprogrammām, kas neatbalsta pakalpojumu sniedzējus (Safari, IE/Edge), kā arī ļauj maksimāli izmantot CDN.

Pareizas kešatmiņas galvenes var arī ievērojami atvieglot servisa darbinieka atjaunināšanu.

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

Šeit es kešatmiņā saglabāju saknes lapu ar modeli #2 (servera puses atkārtota validācija) un visus citus resursus ar modeli #1 (nemainīgs saturs). Katrs servisa darbinieka atjauninājums izraisīs pieprasījumu saknes lapai, un visi pārējie resursi tiks ielādēti tikai tad, ja ir mainījies to URL. Tas ir labi, jo tas ietaupa trafiku un uzlabo veiktspēju neatkarīgi no tā, vai veicat jaunināšanu no iepriekšējās vai ļoti vecā versija.

Šeit ir ievērojama priekšrocība salīdzinājumā ar vietējo ieviešanu, kad viss binārais fails tiek lejupielādēts pat ar nelielām izmaiņām vai rada sarežģītu salīdzinājumu. binārie faili. Tādā veidā mēs varam atjaunināt lielu tīmekļa lietojumprogrammu ar salīdzinoši nelielu slodzi.

Servisa darbinieki labāk darbojas kā uzlabojums, nevis pagaidu kruķis, tāpēc strādājiet ar kešatmiņu, nevis cīnieties ar to.

Ja to lieto uzmanīgi, maksimālais vecums un mainīgais saturs var būt ļoti labs

max-age ļoti bieži ir nepareiza izvēle mainīgam saturam, bet ne vienmēr. Piemēram, oriģinālā raksta maksimālais vecums ir trīs minūtes. Sacensību nosacījums nav problēma, jo lapā nav atkarību, izmantojot to pašu kešatmiņas modeli (CSS, JS un attēli izmanto modeli Nr. 1 — nemainīgs saturs), viss pārējais neizmanto šo modeli.

Šis modelis nozīmē, ka es varu ērti uzrakstīt populāru rakstu, un mans CDN (Cloudflare) var noņemt slodzi no servera, ja vien esmu gatavs gaidīt trīs minūtes, līdz atjauninātais raksts būs pieejams. pieejams lietotājiem.

Šis modelis jāizmanto bez fanātisma. Ja rakstam pievienoju jaunu sadaļu un saiti uz to no cita raksta, es izveidoju atkarību, kas ir jāatrisina. Lietotājs var noklikšķināt uz saites un iegūt raksta kopiju bez vajadzīgās sadaļas. Ja vēlos no tā izvairīties, man vajadzētu atsvaidzināt rakstu, dzēst kešatmiņā saglabāto raksta versiju no Cloudflare, pagaidīt trīs minūtes un tikai tad pievienot saiti uz citu rakstu. Jā, šis modelis prasa piesardzību.

Pareizi lietojot, kešatmiņa nodrošina ievērojamus veiktspējas uzlabojumus un joslas platuma ietaupījumu. Pasniedziet nemainīgu saturu, ja varat viegli mainīt URL, vai izmantojiet servera puses atkārtotu validāciju. Ja esat pietiekami drosmīgs un pārliecināts, ka jūsu saturam nav atkarību, kas varētu izkļūt no sinhronizācijas, sajauciet saturu ar maksimālo vecumu un mainīgu saturu.

Veicot izmaiņas vietnēs, mēs bieži sastopamies ar to, ka lapu saturs, css faili un skripti (.js) tiek saglabāti pārlūkprogrammas kešatmiņā un paliek nemainīgi diezgan ilgu laiku. Tas noved pie tā, ka, lai veiktās izmaiņas tiktu atspoguļotas visās pārlūkprogrammās, ir nepieciešams pieradināt klientus pie sarežģītām F5 vai Ctrl + F5 kombinācijām. Un laiku pa laikam pārliecinieties, ka tie ir nospiesti.

Process ir diezgan nogurdinošs un neērts. Protams, jūs varat izkļūt no situācijas, katru reizi pārdēvējot failus, taču tas atkal ir neērti.

Tomēr ir veids, kas ļaus mums palikt ar tādiem pašiem nosaukumiem un atiestatīt .css vai .js failu kešatmiņu brīdī, kad mums tas ir nepieciešams. Un aizmirstiet par Ctrl + F5 uz visiem laikiem.

Būtība ir tāda, ka mēs saviem .css vai .js failiem beigās pievienosim pseidoparametru, ko mēs laiku pa laikam mainīsim, tādējādi atiestatot pārlūkprogrammas kešatmiņu.

Tādējādi ieraksts iekšā avota kods tagad izskatīsies šādi:

Kur 186485 ir patvaļīga kombinācija, kas izvadīs to pašu failu, bet pārlūkprogramma to interpretē kā jaunu, pateicoties pseidoparametram ?186485

Tagad, lai katru reizi nemainītu visus mūsu parametra gadījumus, mēs to iestatīsim php failā, kuru savienosim ar visām mums nepieciešamajām vietām: