Bedste fremgangsmåder til indstillinger for cache-kontrol til dit websted

Du har måske bemærket, at det nogle gange, når du går ind på et websted for anden gang, ikke ser ud som forventet, og at nogle stilarter er ødelagte, så alt ser underligt ud. Normalt er årsagen til dette problem dårligt definerede cache-kontrolpolitikker, der forhindrer dig i at modtage de seneste ændringer efter den seneste installation. I denne artikel vil jeg vise dig de rigtige cacheindstillinger og teknikker til at hjælpe dig med at holde dit websted opdateret for alle brugere efter hver installation.

For dem af jer, der bare ønsker at få den bedste praksis og begynde at bruge dem, følg linket her til slutningen af ​​artiklen.

Hvordan fungerer cachen bag kulisserne?

Din browser forsøger på hver anmodning til webstedet / ressourcen at indlæse så få data som muligt ved at læse cache-oplysninger fra den lokale hukommelse. Dette er kun muligt, så vi leverer tilstrækkelige instruktioner til browseren, til at forklare, hvilke ressourcer den har brug for at holde og hvor længe.

Disse instruktioner fungerer som direktiver; for at fortælle din browser om dem, skal du tilføje dem til svar HTTP-headeroplysninger. De mest almindelige direktiver involveret i cache-processen er “Cache-Control”, “Expires”, “Etag” og “Last-Modified”.

Næsten hver webserver har som standard nogle cacheindstillinger i header-svar, men det er ikke klart, hvad vi får, hvis der ikke er nogen cache-politikker.

Uden cache-kontrolindstillinger går browseren til webserveren for hver anmodning om ressourcer og læser information fra den. Dette øger belastningstiderne for det berørte sted, tilføjer ekstra belastning til din webserver, når du overfører information, og øger antallet af opkald til din backend.

Anmodninger flow uden cacheindstillinger

Det er op til browseren at bestemme, hvad man skal gøre, og hvordan man cache-oplysninger uden instruktioner fra serveren. I øjeblikket downloader Chrome og Safari data fra backend hver gang uden cacheinstruktion. Dette kan ændre og føre til forskellige opførsler, dog især på andre platforme.

For tydeligt at definere, hvad der skal gøres med bestemte filer, skal vi lave et dybt dyb ned i indlæring af cache-direktiver, tilføje dem trin for trin til responsoverskrifter og se efter resultatet.

Etag (Enhedskode)

Etag er en af ​​cacheindstillingerne. Hovedideen bag denne HTTP-header er at tillade din browser at være opmærksom på ændringer til relevante ressourcer uden at downloade fulde filer. Serveren kunne beregne noget lignende med hash summen af ​​hver fil og derefter sende denne hash sum til klienten. Næste gang klienten forsøger at få adgang til denne ressource, i stedet for at downloade filen, sender browseren noget lignende i HTTP-overskriften: If-None-Match: W / “1d2e7–1648e509289”. Serveren vil derefter kontrollere denne hash-sum mod hash-summen af ​​den aktuelle fil, og hvis der er forskellen, tvinger klienten til at downloade en ny fil. Ellers bliver klienten informeret om, at den skal bruge en cache-version.

Anmodninger flow med Etag - 1. belastningAnmodninger flow med Etag - 2. belastning

Når en Etag-cache-politik er slået til, går vi altid til serveren for at kontrollere hash-summen af ​​en fil, og først derefter beslutter browseren at tage den fra cachen eller indlæse den helt. Når en ressource ikke er ændret, tager det kun 80–100 bytes for at verificere, uanset hvad du beder om, hvad enten det er en 10KB eller 10MB fil.

Sidst ændret

En anden indstilling af cache-kontrol er HTTP-overskriften "Sidste ændring". Hovedideen ligner meget Etag, men browserens opførsel er lidt anderledes. Servere har et tidsstempel for den sidst ændrede dato for hver fil; Efter den første filindlæsning har klienten mulighed for at spørge serveren, om ressourcen er blevet ændret siden det specifikke øjeblik, hvor filerne sidst fik adgang til klienten. For at gøre dette sender browseren If-Modified-Since: Fri, 13 Jul 2018 10:49:23 GMT i HTTP-overskriften. Hvis ressourcen er blevet ændret, skal browseren downloade en ny fil, ellers bruger den en cache-version.

Virkeligheden er, at browsere har deres interne cache-politikker og selv kan beslutte, om de vil tage en ressource fra cachen eller downloade en ny kopi.

Last-Modified er en svag cache-overskrift, da browseren anvender en heuristik til at bestemme, om emnet skal hentes fra cachen eller ej., Og heuristik varierer mellem browsere.
Guide til god praksis for Google-cache
Forespørgsel flow med sidst ændret - 1. belastningAnmodninger om flow med sidst ændret - 2. belastning (perfekt scenarie)Anmodninger om strøm med sidst ændret - 2. belastning (almindelig sag)

Som et resultat kan vi ikke kun stole på sidst ændret, så jeg foretrækker at fjerne det helt fra mine serverindstillinger for at reducere trafikken, selvom det kun er få byte.

Cache-kontrol max-alder

Dette direktiv giver os mulighed for at fortælle browseren, hvor længe den skal holde filen i cachen siden den første indlæsning. Den tid, browseren skal holde filen i cache, bør defineres i sekunder, typisk præsenteres som denne Cache-Control: max-age = 31536000. Med denne politik springer browseren fuldstændigt over processen med at fremsætte anmodninger til din server og åbner filer meget hurtigt. Men hvordan kan vi være sikre på, at filen ikke ændres så længe? Det gør vi ikke.

Så for at tvinge browseren til at downloade en ny version af den nødvendige fil, bruger vi en teknik implementeret af mange værktøjsbyggeres værktøjer, som Webpack eller Gulp. Hver fil forkompileres på serveren, og hash-summer tilføjes filnavne, f.eks. “App-72420c47cc.css”. Selv små ændringer i filen afspejles i hash-summen, som garanterer, at den vil blive anerkendt som anderledes. Så efter næste implementering får du en ny version af filen. Dette kan gælde for alle vores css-, js- og billedfiler (max-age = 31536000); Når vi har ændret noget, vil browseren bare anmode om en ny fil med en ny hash-sum, som den derefter cache.

no-cache

Den vanskelige del af ovenstående teknik er, at du ikke kan glemme dine html-filer; hvis du anvender denne indstilling også til disse, får du aldrig nye links til dine css-, js- eller billedfiler, før du tvinger en genindlæsning.

Jeg anbefaler, at du anvender Cache-Control: no-cache til html-filer. Anvendelse af "no-cache" betyder ikke, at der overhovedet ikke er nogen cache, det fortæller simpelthen browseren at validere ressourcer på serveren, før den bruges fra cachen. Derfor har vi brug for det med Etag, så browsere vil sende en enkel anmodning og indlæs de ekstra 80 byte for at bekræfte filtilstanden.

Endelige indstillinger

  • Brug Gulp, Webpack eller lignende for at tilføje unikke hash-cifre til dine css-, js- og billedfiler (som app-67ce7f3483.css);
  • For js-, css- og billedfiler skal du indstille cache-kontrol: offentlig, max-age = 31536000, ingen Etag, ingen sidst ændrede indstillinger.
  • For html-filer skal du bruge Cache-Control: no-cache og Etag.

Så som vi kan se, er selv åbenlyse og almindelige ting, som cache-statiske filer, muligvis ikke åbenlyse, hvis vi dykker dybere. God forskning kan forhindre dig i at begå fejl og reducere trafikken på din server og reducere belastningstider for webstedshastighed.

Tryk på knappen , hvis du fandt, at denne artikel var nyttig!

Har du spørgsmål eller feedback? Opret forbindelse via Pixel Point