Beste fremgangsmåter for innstillinger for cache-kontroll på nettstedet ditt

Du har kanskje lagt merke til at det noen ganger, når du går inn på et nettsted for andre gang, ikke ser ut som forventet, og noen stilarter er ødelagte, noe som gjør at alt ser rart ut. Vanligvis er årsaken til dette problemet dårlig definerte retningslinjer for hurtigkontroll som hindrer deg i å motta de siste endringene etter den siste distribusjonen. I denne artikkelen vil jeg vise de riktige cacheinnstillingene og teknikkene dine for å hjelpe deg med å holde nettstedet ditt oppdatert for alle brukere etter hver distribusjon.

For dere som bare vil få den beste fremgangsmåten og begynne å bruke dem, følg lenken her til slutten av artikkelen.

Hvordan fungerer cachen bak kulissene?

Nettleseren din prøver på hver forespørsel til nettstedet / ressursen å laste inn så lite data som mulig ved å lese hurtigbufret informasjon fra lokalt minne. Dette er bare mulig vi gir nok instruksjoner til nettleseren, for å forklare hvilke ressurser den trenger å beholde og hvor lenge.

Disse instruksjonene fungerer som direktiver; Hvis du vil fortelle nettleseren din om dem, må du legge dem til svarinformasjon om HTTP-header. De vanligste direktivene involvert i cache-prosessen er "Cache-Control", "Expires", "Etag" og "Last-Modified".

Nesten alle webservere har noen cacheinnstillinger som overskriftssvar som standard, men det er ikke klart hva vi får hvis det ikke er noen cache-policyer.

Uten cache-kontrollinnstillinger går nettleseren til webserveren for hver forespørsel om ressurser og leser informasjon fra den. Dette øker lastetidene for det berørte nettstedet, legger til ekstra belastning på webserveren når du overfører informasjon og øker antall samtaler til backend.

Forespørsler flyter uten cacheinnstillinger

Det er opp til nettleseren å bestemme hva de skal gjøre og hvordan cache-informasjon skal gis uten instruksjoner fra serveren. For øyeblikket laster Chrome og Safari ned data fra backend hver gang, uten cacheinstruksjon. Dette kan imidlertid endre og føre til ulik atferd, spesielt på andre plattformer.

For å tydelig definere hva du skal gjøre med bestemte filer, la oss gjøre et dypt dykk i å lære cache-direktiver, og legge dem trinn for trinn til svaroverskrifter og se på resultatet.

Etag (enhetskode)

Etag er en av cacheinnstillingene. Hovedideen bak denne HTTP-overskriften er å la nettleseren din være klar over endringer i relevante ressurser uten å laste ned fulle filer. Serveren kunne beregne noe lignende med hash sum av hver fil og deretter sende denne hash summen til klienten. Neste gang klienten prøver å få tilgang til denne ressursen, i stedet for å laste ned filen, vil nettleseren sende noe slikt i HTTP-overskriften: If-None-Match: W / “1d2e7–1648e509289”. Serveren vil da sjekke denne hash-summen mot hash-summen av den gjeldende filen, og hvis det er forskjellen, tving klienten til å laste ned en ny fil. Ellers vil klienten bli informert om at den skal bruke en hurtigbufret versjon.

Forespørsler flyt med Etag - 1. belastningForespørsler flyt med Etag - 2. belastning

Når en Etag-cache-policy er slått på, går vi alltid til serveren for å sjekke hash-summen av en fil, og først etter det vil nettleseren bestemme å ta den fra cachen eller laste den helt inn. Når en ressurs ikke er endret, tar det bare 80–100 byte for å bekrefte uansett hva du ber om, enten en 10KB eller 10MB fil.

Sist endret

En annen innstilling for cache-kontroll er HTTP-overskriften "Sist endret". Hovedideen er veldig lik Etag, men nettleserens oppførsel er litt annerledes. Serverne har en tidsstempel for den sist endrede datoen for hver fil; Etter den første filbelastningen har klienten muligheten til å spørre serveren om ressursen har blitt endret siden det bestemte øyeblikket filene sist fikk tilgang til av klienten. For å gjøre dette sender nettleseren If-Modified-Since: Fri, 13 Jul 2018 10:49:23 GMT i HTTP-overskriften. Hvis ressursen er endret, må nettleseren laste ned en ny fil, ellers bruker den en hurtigbufret versjon.

Realiteten er at nettlesere har sine interne hurtigbufferpolitikk og selv kan bestemme om de vil ta en ressurs fra cachen eller ikke laste ned en ny kopi.

Last-Modified er en svak hurtigbufring, ettersom nettleseren bruker en heuristikk for å avgjøre om elementet skal hentes fra cachen eller ikke. Og heuristikker varierer mellom nettlesere.
Googles guide for beste fremgangsmåter for hurtigbufring
Forespørsler flyt med sist endret - 1. belastningForespørsel flyter med sist-modifisert - 2. belastning (Perfect Scenario)Forespørsler flyt med sist endret - 2. belastning (vanlig sak)

Som et resultat kan vi ikke bare stole på sist endret, så jeg foretrekker å fjerne det helt fra serverinnstillingene mine for å redusere trafikken, selv om det bare er noen få byte.

Cache-Control maks-alder

Dette direktivet lar oss fortelle nettleseren hvor lenge den skal holde filen i hurtigbufferen siden første lasting. Tiden som nettleseren skal holde filen i cache, bør defineres i sekunder, vanligvis presentert som denne Cache-Control: max-age = 31536000. Med denne policyen hopper nettleseren fullstendig over prosessen med å sende forespørsler til serveren din og åpner filer veldig raskt. Men hvordan kan vi være sikre på at filen ikke vil endres så lenge? Det gjør vi ikke.

Så for å tvinge nettleseren til å laste ned en ny versjon av den nødvendige filen, bruker vi en teknikk implementert av mange verktøy for byggherrer, for eksempel Webpack eller Gulp. Hver fil vil bli forhåndskompilert på serveren og hash-summer legges til filnavnene, for eksempel “app-72420c47cc.css”. Selv små endringer i filen gjenspeiles i hash-summen, som garanterer at den blir anerkjent som annerledes. Så, etter neste distribusjon, vil du få en ny versjon av filen. Dette kan gjelde alle css-, js- og bildefiler (max-age = 31536000); etter at vi har endret noe, vil nettleseren bare be om en ny fil med en ny hash-sum, som den deretter hurtigbuffer.

no-cache

Den vanskelige delen av teknikken ovenfor er at du ikke kan glemme HTML-filene dine; Hvis du bruker den innstillingen på disse også, vil du aldri få nye lenker for css-, js- eller bildefiler før du tvinger en lasting på nytt.

Jeg anbefaler at du bruker Cache-Control: no-cache på html-filer. Å bruke “no-cache” betyr ikke at det ikke er noen cache i det hele tatt, det ber ganske enkelt nettleseren om å validere ressurser på serveren før du bruker den fra cachen. Det er grunnen til at vi trenger å bruke den med Etag, så nettlesere vil sende en enkel forespørsel og last de ekstra 80 byte for å bekrefte filtilstanden.

Endelige innstillinger

  • Bruk Gulp, Webpack eller lignende for å legge til unike hash-sifre til css-, js- og bildefiler (som app-67ce7f3483.css);
  • For js-, css- og bildefiler, angi Cache-Control: public, max-age = 31536000, no Etag, no Last-Modified innstillinger.
  • For html-filer bruker du Cache-Control: no-cache og Etag.

Så som vi kan se, til og med åpenbare og vanlige ting, som å lagre statiske filer, er kanskje ikke opplagt hvis vi dykker dypere. God forskning kan forhindre at du gjør feil og reduserer trafikken på serveren din, og reduserer belastningstidene for nettstedets hastighet.

Trykk på -knappen hvis du synes denne artikkelen var nyttig!

Noen spørsmål eller tilbakemelding? Koble til via Pixel Point