Bufferstiler. Grunnleggende om klientbufring i klare ord og eksempler
Ved å inkludere ekstern CSS og Javascript ønsker vi å redusere unødvendige HTTP-forespørsler til et minimum.
Til dette formålet serveres .js- og .css-filer med overskrifter som sikrer pålitelig hurtigbufring.
Men hva gjør du når en av disse filene endres under utviklingen? Alle brukere har den gamle versjonen i cachen - inntil cachen er utdatert vil det komme mange klager på den ødelagte integrasjonen av server- og klientdelene.
Riktig hurtigbufring og versjonskontroll eliminerer dette problemet fullstendig og gir pålitelig, gjennomsiktig synkronisering av stil-/skriptversjoner.
Enkel ETag-bufring
Den enkleste måten å bufre statiske ressurser på er å bruke ETag.
Det er nok å aktivere riktig serverinnstilling (for Apache er den aktivert som standard) - og for hver fil i overskriftene vil en ETag bli gitt - en hash som avhenger av oppdateringstid, filstørrelse og (på inodebasert fil) systemer) inode.
Nettleseren bufrer en slik fil og spesifiserer ved påfølgende forespørsler en If-None-Match-overskrift med ETag-en til det hurtigbufrede dokumentet. Etter å ha mottatt en slik header kan serveren svare med kode 304 - og da vil dokumentet bli hentet fra cachen.
Det ser slik ut:
Første forespørsel til serveren (cache clean) GET /misc/pack.js HTTP/1.1 Host: nettsted
Generelt legger nettleseren vanligvis til en haug med overskrifter som User-Agent, Accept, etc. De er kuttet for korthet.
Serverrespons Serveren svarer med et dokument med kode 200 og ETag: HTTP/1.x 200 OK Content-Encoding: gzip Content-Type: text/javascript; charset=utf-8 Etag: "3272221997" Accept-Ranges: bytes Content-Length: 23321 Dato: Fre, 02 May 2008 17:22:46 GMT Server: lighttpd Neste nettleserforespørsel Ved neste forespørsel legger nettleseren til If-None -Match: (bufret ETag): GET /misc/pack.js HTTP/1.1 Host: site If-None-Match: "453700005" Serverrespons Serveren ser ut - ja, dokumentet er ikke endret. Dette betyr at du kan utstede en 304-kode og ikke sende dokumentet på nytt. HTTP/1.x 304 Ikke endret innholdskoding: gzip Etag: "453700005" Innholdstype: text/javascript; charset=utf-8 Accept-Ranges: bytes Dato: Tue, 15 Apr 2008 10:17:11 GMT
Et alternativ er at hvis dokumentet er endret, så sender serveren ganske enkelt 200 med den nye ETag.
Kombinasjonen Last-Modified + If-Modified-Since fungerer på en lignende måte:
- serveren sender datoen for siste endring i overskriften Last-Modified (i stedet for ETag)
- nettleseren bufrer dokumentet, og neste gang det sendes en forespørsel om det samme dokumentet, sender den datoen for den hurtigbufrede versjonen i If-Modified-Since-overskriften (i stedet for If-None-Match)
- serveren sjekker datoene, og hvis dokumentet ikke er endret, sender den kun 304-koden, uten innholdet.
Disse metodene fungerer pålitelig og godt, men nettleseren må fortsatt lage en forespørsel for hvert skript eller stil.
Smart caching. Versjonskontroll
Den generelle tilnærmingen for versjonering - i et nøtteskall:
- Versjonen (eller endringsdatoen) legges til alle skript. For eksempel http://site/ min.js blir til http://site/ min.v1.2.js
- Alle skript lagres hardt av nettleseren
- Ved oppdatering av skriptet endres versjonen til en ny: http://site/ min.v2.0.js
- Adressen er endret, så nettleseren vil be om og hurtigbufre filen igjen
- Den gamle versjonen 1.2 vil gradvis falle ut av cachen
Hard caching
Hard caching- en slags slegge som spikrer fullstendig forespørsler til serveren om bufrede dokumenter.
For å gjøre dette, legg bare til Expires og Cache-Control: max-age overskriftene.
For eksempel, for å bufre i 365 dager i PHP:
Header("Utløper: ".gmdate("D, d M Y H:i:s", tid()+86400*365)." GMT"); header("Cache-Control: max-age="+86400*365);
Eller du kan bufre innholdet permanent ved å bruke mod_header i Apache:
Etter å ha mottatt slike overskrifter, lagrer nettleseren dokumentet hardt i lang tid. All videre tilgang til dokumentet vil bli servert direkte fra nettleserbufferen, uten å kontakte serveren.
De fleste nettlesere (Opera, Internet Explorer 6+, Safari) cacher IKKE dokumenter hvis det er et spørsmålstegn i adressen, fordi de anser dem som dynamiske.
Det er derfor vi legger til versjonen i filnavnet. Selvfølgelig, med slike adresser må du bruke en løsning som mod_rewrite, vi skal se på dette senere i artikkelen.
P.S. Men Firefox cacher adresser med spørsmålstegn...
Automatisk navneoppløsning
La oss se på hvordan du automatisk og transparent endrer versjoner uten å gi nytt navn til selve filene.
Navn med versjon -> Fil
Det enkleste er å gjøre om navnet med versjonen til det originale filnavnet.
På Apache-nivå kan dette gjøres med mod_rewrite:
RewriteEngine på RewriteRule ^/(.*\.)v+\.(css|js|gif|png|jpg)$ /$1$2 [L]
Denne regelen behandler alle css/js/gif/png/jpg-filer, og fjerner versjonen fra navnet.
For eksempel:
/images/logo.v2.gif -> /images/logo.gif
/css/style.v1.27.css -> /css/style.css
/javascript/script.v6.js -> /javascript/script.js
Men i tillegg til å kutte ut versjonen, må du også legge til harde caching-overskrifter til filene. Mod_header-direktivene brukes til dette:
Overskrift legg til "Utløper" "man, 28. jul 2014 23:30:00 GMT" Overskrift legg til "Cache-Control" "max-age=315360000"
Og alt sammen implementerer den følgende Apache-konfigurasjon:
RewriteEngine on # fjerner versjonen, og setter samtidig variabelen at filen er versjonert RewriteRule ^/(.*\.)v+\.(css|js|gif|png|jpg)$ /$1$2 # hard cache versjonerte filer Overskrift legg til "Utløper" "man, 28. jul 2014 23:30:00 GMT" env=VERSIONED_FILE Header legg til "Cache-Control" "max-age=315360000" env=VERSIONED_FILE
På grunn av måten mod_rewrite-modulen fungerer på, må RewriteRule plasseres i hovedkonfigurasjonsfilen httpd.conf eller i filer inkludert (inkludert), men ikke i noe tilfelle i .htaccess , ellers kjøres Header-kommandoene først, før den installeres VERSIONED_FILE variabel.
Header-direktiver kan være hvor som helst, selv i .htaccess - det spiller ingen rolle.
Legger automatisk til versjon til filnavn på HTML-side
Hvordan du legger versjonen i navnet på skriptet avhenger av malsystemet ditt og generelt måten du legger til skript (stiler osv.).
For eksempel, når du bruker endringsdatoen som en versjon og Smarty-malmotoren, kan koblinger settes slik:
Versjonsfunksjonen legger til versjonen:
Funksjon smarty_version($args)( $stat = stat($GLOBALS["config"]["site_root"].$args["src"]); $version = $stat["mtime"]; echo preg_replace("! \.(+?)$!", ".v$versjon.\$1", $args["src"]); )
Resultat på siden:
Optimalisering
For å unngå unødvendige stat-anrop kan du lagre en matrise med en liste over gjeldende versjoner i en egen variabel
$versions["css"] = array("group.css" => "1.1", "other.css" => "3.0", )
I dette tilfellet erstattes den gjeldende versjonen fra arrayen ganske enkelt i HTML-en.
Du kan krysse begge tilnærmingene, og under utvikling produsere en versjon etter modifikasjonsdato - for relevans, og i produksjon - en versjon fra en matrise, for ytelse.
Anvendbarhet
Denne bufringsmetoden fungerer overalt, inkludert Javascript, CSS, bilder, Flash-filmer, etc.
Det er nyttig når dokumentet endres, men nettleseren bør alltid ha den gjeldende, oppdaterte versjonen.
- htaccess caching lagrer innholdet på en nettside på den lokale datamaskinen når en bruker besøker den;
- Bruke nettleserbufferen – Webmasteren instruerer nettlesere hvordan de skal behandle ressurser.
Når nettleseren gjengir en nettside, må den laste inn logoen, CSS-filen og andre ressurser:
Nettleserbufferen "husker" ressurser som nettleseren allerede har lastet ned. Når en besøkende går til en annen side på nettstedet, logo, CSS-filer osv. bør ikke lastes ned igjen fordi nettleseren allerede har "husket" dem (lagret dem). Dette er grunnen til at nettsiden tar lengre tid å laste ved ditt første besøk enn ved gjentatte besøk.
Når du bruker caching, vil nettsidefilene lagres i nettleserens cache. Sidene lastes mye raskere ved gjentatte besøk. Det vil også skje med andre sider som bruker de samme ressursene.
Hvordan aktivere nettleserbufring
- Endre ressursforespørselhoder for å bruke caching;
- Optimaliser bufringsstrategien din.
Endre forespørselshoder
For de fleste er den eneste måten å bufre et nettsteds htaccess på å legge til kode i .htaccess-filen på webserveren.
.htaccess-filen kontrollerer mange viktige innstillinger for nettstedet ditt.
Nettleserbufring via .htaccess-fil
Koden nedenfor forteller nettleseren hva den skal bufre og hvor lenge den skal "huske" den. Den bør legges til i begynnelsen av .htaccess-filen:
## UTLØPER CACHING ##
Lagre .htaccess-filen og oppdater deretter nettsiden.
Hvordan stille inn hurtigbuffertid for forskjellige filtyper
Koden ovenfor spesifiserer tidsintervaller. For eksempel 1 år (1 år) eller 1 måned (1 måned). De er relatert til filtyper. Koden ovenfor sier at .jpg-filer (bilder) skal bufres i et år.
Hvis du ville endre dette slik at JPG-bilder også ble bufret i en måned, så ville du ganske enkelt byttet ut "1 år" med "1 måned". Ovennevnte htaccess-bufringsverdier er optimale for de fleste nettsider.
Alternativ bufringsmetode for .htaccess
Metoden beskrevet ovenfor kalles " Utløper", hjelper det de fleste nybegynnere med caching. Når du blir komfortabel med caching, kan du prøve en annen cachingmetode kalt Cache-Control, som gir deg flere alternativer.
Det er mulig at Expires-metoden ikke vil fungere på serveren din, i så fall vil du kanskje prøve å bruke Cache-Control.
Cache-kontroll
Denne metoden lar deg få mer kontroll over sidebufring i nettleseren, men mange synes det er lettere å spesifisere alle innstillingene én gang.
Eksempelbruk i en .htaccess-fil:
#1 måned for de fleste statiske eiendeler
Koden ovenfor setter Cache-Control-overskriften avhengig av filtypen.
Hvordan fungerer Cache-Control?
Vurder linjen ovenfor med bufringskode i htaccess-nettleseren:
#1 måned for de fleste statiske eiendeler
Denne linjen er bare en merknad. .htaccess-filen ignorerer linjer som begynner med #-tegnet. Dette notatet anbefales fordi du kan ha flere forskjellige datasett som filbuffringsløsning:
Linjen nevnt ovenfor sier at " hvis filen er en av disse typene, vil vi gjøre noe med den...»
Det viktigste med denne linjen er at den viser de forskjellige filtypene ( CSS, JS, JPEG, PNG etc. ) og at bufringsinstruksjoner bør brukes på disse filtypene. Hvis du for eksempel ikke vil at JPG-filer skal bufres i en bestemt tidsperiode, kan du fjerne " JPG". Hvis du vil legge til HTML, må du angi på denne linjen " HTML«:
Overskriftssett Cache-Control "max-age=2592000, public"
Linjen nevnt ovenfor setter de faktiske overskriftene og verdiene:
- Del " Header sett Cache-Control» — setter tittelen;
- Variabel " maks-alder=2592000"—indikerer hvor lang tid bufringsprosessen vil ta (i sekunder). I dette tilfellet cacher vi i én måned (2592000) sekunder;
- Del " offentlig” rapporterer at den er offentlig tilgjengelig.
Denne htaccess cache-linjen lukker setningen og avslutter kodeblokken.
Generelt bufferproblem
Hvis du kompilerer en liste over bilder som skal bufres i et år eller mer, husk at hvis du gjør endringer på sidene dine, kan det hende at de ikke er synlige for alle brukere. Fordi brukere vil få tilgang til bufrede filer i stedet for eksisterende. Hvis det er en fil du med jevne mellomrom redigerer ( for eksempel - CSS-fil), så kan du overvinne bufferproblemet ved å bruke URL-fingeravtrykk.
URL-fingeravtrykk
Å skaffe en ny (ikke-bufret) filressurs er mulig hvis det er et unikt navn. For eksempel, hvis CSS-filen heter "main.css", kan vi kalle den "main_1.css" i stedet. Neste gang vi endrer navnet, kan vi gi filen navnet "main_2.css". Dette er nyttig for filer som endres med jevne mellomrom.
For en tid siden var det behov for å cache serversvar på klienten. Jeg vil si med en gang at jeg vet om nettleserbuffere, men dette var ikke mitt tilfelle. Uten å nøle begynte jeg å supplere koden for lasting av data, slik at før jeg sendte en forespørsel til serveren, ville det bli sjekket om det allerede var et resultat med en slik forespørsel.
For klarhets skyld vil jeg gi et eksempel før:
funksjon loadData(url, fn) ( ajax.get(url, function (err, result) ( //her behandler vi svaret og returnerer resultatet var data = "..."; fn(null, data); )) ;)
og etter:
var cache = (); funksjon loadCacheData(url, fn) ( var cacheData = cache; //sjekk hurtigbufferen if (cacheData) ( fn(null, cacheData); ) else ( ajax.get(url, funksjon (feil, resultat) ( //behandle den svar her og returner resultatet var data = "..."; //save to cache cache = fn(null, data ));
Etter å ha skrevet om noen flere funksjoner i denne stilen, ble jeg lei, og denne metoden har ikke mye funksjonalitet, for eksempel kan du ikke tilbakestille cachen. Etter litt googling (kanskje jeg googlet dårlig), kunne jeg ikke finne et bibliotek som ville tillate meg å legge ved en hurtigbuffer til eksisterende kode med en enkel håndbevegelse.
Dette satte scenen for å skrive en enkel wrapper-funksjon som ville gjøre loadData til loadCacheData.
Det skal se omtrent slik ut:
funksjon loadData(url, fn) ( ajax.get(url, function (err, result) ( //her behandler vi svaret og returnerer resultatet var data = "..."; fn(null, data); )) ; ) var loadCacheData = cache(loadData);
"loadCacheData"-funksjonen oppnådd på denne måten skal selv bufre resultatet, samt gi funksjonalitet for å administrere cachen.
Etter en tid klarte vi å implementere en mer eller mindre fungerende versjon av «cache»-funksjonen. Alle kilder er tilgjengelige på github.
Hva denne funksjonen lar deg gjøre:
1. Tilbakestill cache.
var loadCacheData = cache(loadData); loadCacheData.clearCache();
2. Still inn levetiden for hurtigbufferen. Standard er satt til 1 år.
var loadCacheData = cache(( utløper: 10 * 1000 ), loadData);
3. Angi maksimal cachestørrelse (hvor mange svar som skal lagres i cachen). Standard er 10.
var loadCacheData = cache((max: 10 ), loadData);
4. Velge en bufferlagringsmetode. Standard er "app".
app - lagre cache i minnet.
lokal - lagre cachen i localStorage og er tilgjengelig mellom alle sidene på nettstedet.
var loadCacheData = cache((lagring: "local" ), loadData);
Når du angir "local", kan du valgfritt angi "cacheKey" - navnet på nøkkelen i localStorage der cachen er lagret.
5. Installere din egen cache-lagring.
var loadCacheData = cache((lagring: new MyCacheStorage() ), loadData);
I dette tilfellet må MyCacheStorage() implementere tre metoder:
"få(nøkkel, fn);" - metoden velger resultater fra hurtigbufferen etter nøkkel.
"sett(nøkkel, val, fn);" - metoden setter verdien til cachen.
"clear(fn);" - metoden tilbakestiller cachen.
"fn" er en tilbakeringingsfunksjon som tar "feil" som det første argumentet og "resultatet" (hvis noen) av funksjonsutførelsen som det andre.
Å bruke "cache-js" påfører én begrensning: funksjoner hvis resultater må "bufres" må følge regelen: "Den siste parameteren må være en tilbakeringingsfunksjon!"
- Nå legges "cache"-funksjonen til det globale området, det er planlagt å flytte den til et eget
- Legg til cache ved hjelp av sessionStorage
- Globale alternativer, for eksempel for å deaktivere cachen helt under utvikling
- Støtte for eldre nettlesere. For øyeblikket er metodene som brukes parse/stringify av JSON-objektet, getItem/setItem/removeItem av localStorage-objektet
- !? Port til nodejs (tvilsomt)
Eksempler på bruk er tilgjengelig på
Cachen spiller en viktig rolle i driften av nesten alle nettapplikasjoner på nivået for arbeid med databaser, webservere og også på klienten.
I denne artikkelen vil vi prøve å forstå klientbufring. Spesielt skal vi se på hvilke HTTP-hoder som brukes av nettlesere og webservere og hva de betyr.
Men først, la oss finne ut av det Hvorfor trenger du i det hele tatt caching på klientsiden?.
Nettsider består av mange forskjellige elementer: bilder, css- og js-filer, etc. Noen av disse elementene brukes på flere (mange) sider på nettstedet. Caching på klientsiden refererer til nettlesernes evne til å lagre kopier av filer (serversvar) for ikke å laste dem ned igjen. Dette lar deg øke hastigheten på ominnlasting av sider betydelig, spare trafikk og også redusere belastningen på serveren.
Det er flere forskjellige HTTP-hoder for å kontrollere bufferprosesser på klientsiden. La oss snakke om hver av dem.
Http-overskrifter for å kontrollere klientbufring
La oss først se på hvordan serveren og nettleseren samhandler i fravær av caching. For en klar forståelse prøvde jeg å forestille meg og visualisere prosessen med kommunikasjon mellom dem i form av en tekstprat. Tenk deg i noen minutter at serveren og nettleseren er personer som korresponderer med hverandre :)
Uten hurtigbuffer (i fravær av bufring av http-overskrifter)
Som vi kan se, vil nettleseren laste det ned igjen fra serveren hver gang cat.png-bildet vises. Jeg tror det ikke er nødvendig å forklare at dette er tregt og ineffektivt.
Sist endret svaroverskrift og if-Modified-Since-forespørselsoverskrift.
Tanken er at serveren legger til en Last-modified header til filen (svaret) den gir til nettleseren.
Nettleseren vet nå at filen ble opprettet (eller endret) 1. desember 2014. Neste gang nettleseren trenger den samme filen, vil den sende en forespørsel med en if-Modified-Since-overskrift.
Hvis filen ikke er endret, sender serveren et tomt svar til nettleseren med status 304 (Ikke endret). I dette tilfellet vet nettleseren at filen ikke er oppdatert og kan vise kopien den lagret forrige gang.
Dermed sparer vi ved å bruke Last-modified på å laste ned en stor fil, og kommer av med et tomt raskt svar fra serveren.
Etag-svar-header og If-None-Match-forespørselsheader.
Driftsprinsippet til Etag er veldig likt Last-modified, men i motsetning til det er det ikke bundet til tid. Tid er en relativ ting.
Tanken er at når den er opprettet og hver gang den endres, merker serveren filen med en spesiell kode kalt ETag, og legger også til en overskrift til filen (svaret) som den gir til nettleseren:
ETag: "686897696a7c876b7e"
Nå vet nettleseren at den gjeldende versjonsfilen har en ETag lik "686897696a7c876b7e". Neste gang nettleseren trenger den samme filen, vil den sende en forespørsel med overskriften If-None-Match: "686897696a7c876b7e" .
If-None-Match: "686897696a7c876b7e"
Serveren kan sammenligne etikettene og, hvis filen ikke er endret, sende et tomt svar til nettleseren med status 304 (Ikke endret). Som med Sist endret, vil nettleseren finne ut at filen ikke er oppdatert og vil kunne vise en kopi fra hurtigbufferen.
Tittel utløpt
Prinsippet for drift av denne overskriften skiller seg fra Etag og Last-modified beskrevet ovenfor. Ved å bruke Expired, bestemmes "utløpsdatoen" ("relevansperiode") for filen. De. Ved første lasting lar serveren nettleseren vite at den ikke planlegger å endre filen før datoen spesifisert i Utløpt:
Neste gang vil nettleseren, vel vitende om at "utløpsdatoen" ennå ikke har kommet, ikke en gang prøve å sende en forespørsel til serveren og vise filen fra hurtigbufferen.
Denne typen cache er spesielt relevant for illustrasjoner for artikler, ikoner, favorittikoner, noen css- og js-filer osv.
Cache-kontroll overskrift med maks-alder direktiv.
Prinsippet for drift av Cache-control: max-age er veldig likt Expired. Her bestemmes også "utløpsdatoen" for filen, men den settes i sekunder og er ikke knyttet til en bestemt tid, noe som er mye mer praktisk i de fleste tilfeller.
For referanse:
- 1 dag = 86400 sekunder
- 1 uke = 604800 sekunder
- 1 måned = 2629000 sekunder
- 1 år = 31536000 sekunder
For eksempel:
Cache-kontroll: maks-alder=2629000;
Cache-kontroll-overskriften har andre direktiver i tillegg til maks-alder. La oss ta en rask titt på de mest populære:
offentlig
Faktum er at ikke bare brukerens sluttklient (nettleser), men også ulike mellomfullmektiger, CDN-nettverk, etc. kan cache forespørsler. Så det offentlige direktivet tillater absolutt enhver proxy-server å utføre caching akkurat som en nettleser.
privat
Direktivet sier at denne filen (serverrespons) er spesifikk for sluttbrukeren og ikke skal bufres av ulike mellomfullmektiger. Samtidig tillater den caching til sluttklienten (brukerens nettleser). Dette er for eksempel relevant for interne brukerprofilsider, forespørsler innenfor en sesjon osv.
Lar deg spesifisere at klienten skal sende en forespørsel til serveren hver gang. Noen ganger brukt med Etag-overskriften beskrevet ovenfor.
ingen butikk
Instruerer klienten om at den ikke under noen omstendigheter skal beholde en kopi av forespørselen eller deler av forespørselen. Dette er den strengeste overskriften, som overstyrer eventuelle cacher. Den ble oppfunnet spesielt for å jobbe med konfidensiell informasjon.
må revalideres
Dette direktivet instruerer nettleseren om å sende en obligatorisk forespørsel til serveren om å validere innholdet på nytt (for eksempel hvis du bruker eTag). Faktum er at http i en bestemt konfigurasjon lar cachen lagre innhold som allerede er utdatert. must-revalidate forplikter nettleseren til å sjekke oppdateringen av innhold under alle omstendigheter ved å sende en forespørsel til serveren.
proxy-revalidate
Dette er det samme som må-revalidere, men gjelder kun for caching proxyer.
s-maks
Praktisk talt ikke forskjellig fra maks-alder , bortsett fra at dette direktivet kun tas i betraktning av cachen til forskjellige proxyer, men ikke av brukerens nettleser selv. Bokstav " s-" kommer fra ordet " s hared" (f.eks. CDN). Dette direktivet er ment spesielt for CDN-er og andre mellomliggende cacher. Hvis du spesifiserer det, overstyrer du verdiene til direktivet om maksimal alder og overskriften Utløpt. Men hvis du ikke bygger CDN-nettverk, er det usannsynlig at du noen gang trenger s-maxage.
Hvordan kan jeg se hvilke overskrifter som brukes på et nettsted?
Du kan se http-forespørselshodene og svarhodene i feilsøkeren til favorittnettleseren din. Her er et eksempel på hvordan det ser ut i Chrome:
Det samme kan sees i enhver nettleser eller http-sniffer som respekterer seg selv.
Sette opp caching i Apache og Nginx
Vi vil ikke gjenfortelle dokumentasjonen for å sette opp populære servere. Du kan alltid se den og. Nedenfor vil vi gi noen eksempler fra virkeligheten for å vise hvordan konfigurasjonsfiler ser ut.
Apache-konfigurasjonseksempel for å kontrollere utløper
Vi setter forskjellige "utløpsdatoer" for forskjellige typer filer. Ett år for bilder, en måned for skript, stiler, pdf-er og ikoner. For alt annet – 2 dager.
Eksempel på Nginx-konfigurasjon for å kontrollere Expires
Vi setter forskjellige "utløpsdatoer" for forskjellige typer filer. En uke for bilder, en dag for stiler og manus.
Server ( #... plassering ~* \.(gif|ico|jpe?g|png)(\?+)?$ ( utløper 1w; ) plassering ~* \.(css|js)$ ( utløper 1d; ) #...)
Eksempel Apache-konfigurasjon for cache-kontroll (maks-alder og offentlig/privat/ikke-cache)
Nginx-konfigurasjonseksempel for cache-kontroll av statiske filer
server ( #... plassering ~* \.(?:ico|css|js|gif|jpe?g|png)$ ( add_header Cache-Control "max-age=88000, public"; ) #... )Endelig
"Cache alt som kan bufres" er et godt motto for en webutvikler. Noen ganger kan du bruke bare noen få timer på konfigurering og samtidig forbedre brukeropplevelsen av nettstedet ditt betydelig, redusere serverbelastningen betydelig og spare trafikk. Det viktigste er ikke å overdrive det og sette opp alt riktig, med tanke på egenskapene til ressursen din.