Videre til indhold 
HTTP betinget Anmodninger reducerer transmissionsomkostningerne ved at sikre, at klienten kun indlæser en ressource fuldstændigt, hvis den faktisk er blevet ændret siden sidste anmodning. Jeg vil vise, hvordan Cache-validering med ETag, Last-Modified, If-None-Match, If-Modified-Since og 304 Not Modified fungerer pålideligt, og indlæsningstiden er mærkbart reduceret.
Centrale punkter
- Validering i stedet for fuld download: 304 sparer båndbredde og tid.
- ETag og Last-Modified arbejder sammen for ren kontrol.
- Cache-kontrol definerer friskhed, udløber kun kosttilskud.
- Forudsætninger såsom If-Match sikre skriveprocesser.
- Sikkerhed kræver private/no-store for følsomt indhold.
Hvad betingede anmodninger gør i hverdagen
Jeg sætter Betinget anmoder om at stille serveren et klart spørgsmål: Har jeg virkelig brug for at overføre nye data, eller er min cache tilstrækkelig? Browseren eller en proxy sender betingelser, serveren kontrollerer, om en fil er ændret, og svarer med 304 Not Modified uden body. Dette mønster holder HTML, CSS, JavaScript, billeder og API-svar opdaterede og reducerer belastningen på infrastrukturen betydeligt. Til længere gyldige aktiver bruger jeg lange max-age-værdier og sikrer, at de er opdaterede gennem validering. Hvis du har de rigtige Cache-kontrolstrategier får det maksimale ud af cachen uden at risikere forældet indhold.
Headere, der muliggør cache-validering
For pålidelig Cache-Klienten har brug for klare signaler fra svaret for at kunne træffe beslutninger. Jeg bruger Cache-Control til friskhed og regler, Expires lejlighedsvis som supplement og Last-Modified og ETag til den egentlige validering. Last-Modified giver et ændringstidspunkt, der hurtigt kan kontrolleres, mens ETag giver en versionsidentifikator, der også bruges til dynamisk indhold. Det er stadig vigtigt: no-cache betyder validering før brug, ikke sletning. Hvis du anvender denne semantik korrekt, vil du opnå mærkbart mindre datatrafik, samtidig med at dit indhold holdes opdateret. Indhold.
Sekvensen af en betinget anmodning uden omveje
Ved det første kald gemmer klienten filen og valideringsværdier som f.eks. ETag eller Last-Modified i cachen. Senere udløber ressourcen eller kræver et nyt tjek før brug, og klienten sender If-None-Match eller If-Modified-Since. Serveren sammenligner oplysningerne med den aktuelle status og returnerer enten 200 OK med en ny body eller 304 Not Modified uden payload. Klienten fortsætter derefter med at bruge den eksisterende kopi og sparer transmission, TLS-arbejdsbyrde og tid. Denne ping-pong virker upåfaldende, men den Effekt på belastningsfølelse og serverbelastning er tydelig.
ETag vs. Last-Modified i direkte sammenligning
Jeg bruger Sidst ændret Jeg kan godt lide at bruge tidsstempler som en hurtig, enkel reference, men bruger ETags til finkornet kontrol. Tidsstempler kan nå deres grænser med meget korte ændringsintervaller eller forfalske dynamiske outputs. Jeg opretter ETags ud fra filhashes, databaseversioner eller render-varianter, hvor hver ændring i indholdet genererer en ny identifikator. Begge mekanismer kan kombineres: Klienten kan sende If-None-Match og If-Modified-Since parallelt, og serveren vælger den passende kontrol. Hvordan sikrer man en pålidelig Validering, hvilket gælder både for statiske og dynamiske ressourcer.
| Kriterium | Sidst ændret | ETag |
|---|---|---|
| Nøjagtighed | Anden opløsning, velegnet til filer | Versionsidentifikator for hver indholdsændring |
| Dynamik | Svag med hyppige, ikke-filbaserede ændringer | Stærk til API'er og gengivet indhold |
| Udgifter | Lav, tilgængelig fra filsystemet | Lav til moderat, generering i app/proxy |
| Konflikter | Urafvigelser er mulige | Forkert konfigurerede weak/strong-tags mulige |
Korrekte indstillinger for browser-caching og API'er
Til statiske aktiver bruger jeg lange max-alder og gemme via ETag eller filnavnets hash, så opdateringer genkendes med det samme. Jeg markerer ofte HTML- og API-svar med no-cache, så klienten validerer før brug uden at skulle genindlæse alt hver gang. Jeg markerer personlige sider med private, så delte cacher ikke udsender noget, der er blevet gemt til andre. Fejl skyldes ofte modstridende direktiver eller manglende valideringshoveder, som jeg undgår med klare regler. Hvis du kender de typiske snublesten, kan du nemt undgå dem; artiklen om Header-traps i caching, som jeg kan lide at orientere mig efter.
Brug statuskoder og betingelser effektivt
Jeg organiserer Statuskoder Det er tydeligt: 200 OK leverer indhold, 304 Not Modified bekræfter brug af cache, og 412 Precondition Failed annullerer, hvis en betingelse ikke er opfyldt. Til sikre skriveoperationer bruger jeg If-Match, så opdateringer kun træder i kraft, hvis ETag'en svarer til den forventede version. Læsning med If-None-Match eller If-Modified-Since forhindrer overflødige payloads og holder klienterne synkroniserede. Konsekvent adfærd er vigtig: Det samme slutpunkt bør svare identisk på identiske forudsætninger. For SEO og bots er jeg opmærksom på, hvordan cacher og crawlere fortolker statusmeddelelser; et godt overblik over HTTP-statuskoder og crawling hjælper med rene beslutninger.
Sikkerhed og databeskyttelse til caching
Jeg behandler følsomt indhold med ingen opbevaring og giver dem dermed ingen chance for at ende i browserens eller proxyens cache. Jeg markerer personaliserede sider med Cache-Control: private og kontrollerer, at der ikke vises personlige data i langtidscachelagrede URL'er. Jeg designer ETags neutralt uden at tillade, at der drages konklusioner om brugerkonti eller interne ID'er. Jeg deaktiverer konsekvent al caching for loginvisninger og bankflow. Hvis du kombinerer dataminimering, passende direktiver og rene headere, reducerer du risikoen og beskytter dine data. Fortrolighed.
Implementering: Skridt til server og applikation
I begyndelsen adskiller jeg statisk af dynamiske ressourcer og beslutter, hvor lange deadlines giver mening, og hvor validering har prioritet. I Nginx, Apache eller en app-server konfigurerer jeg cache-kontrol og aktiverer last-modified og ETags, hvorved jeg placerer ETag-generering i applikationen for dynamiske endpoints. Når jeg behandler indgående anmodninger, evaluerer jeg If-None-Match og If-Modified-Since og svarer med 304, hvis betingelsen matcher. Til skriveoperationer bruger jeg If-Match og returnerer 412 i tilfælde af afvigelser for at forhindre overskrivning. Dette skaber en konsekvent adfærd, der bruger cacher effektivt og samtidig Korrekthed sikrer.
Brug metrikker, tests og overvågning fornuftigt
Jeg tjekker Netværk-tab i DevTools for at tjekke, om ressourcerne kommer fra cachen, bliver valideret eller lige er blevet indlæst. Jeg overvåger status, aldersværdier, ETags og størrelsen på det overførte svar. Under belastning måler jeg latenstid, overførselsvolumen og server-CPU for at se den faktiske effekt af 304 svar. Logfiler fra den omvendte proxy viser, om delte cacher gør deres arbejde, og hvor mange valideringer der er vellykkede. Jeg bruger disse data til at justere max-age, cachekontroldirektiver og ETag-strategier, indtil svartider og Træfprocent stemme.
Hosting-performance: Hvorfor betingede anmodninger sparer penge
Hver enkelt 304Det delte cachesvar sparer båndbredde, reducerer TLS-overhead og forkorter svartiden, hvilket er særligt vigtigt for mange lignende anmodninger. I hostingopsætninger med reverse proxies, load balancers og CDN'er opnår jeg den største effekt, når jeg klart tillader eller specifikt udelukker delte cacher. Mindre overførsel betyder ofte også lavere trafikomkostninger i euro og flere reserver til reelle spidsbelastninger. Brugeroplevelsen forbedres også, fordi gentagne sidevisninger og API-afstemninger reagerer hurtigere. På den måde realiserer jeg et ydelsespotentiale, som rene hardwareopgraderinger alene ikke kan levere, og bruger eksisterende Infrastruktur Det er bedre.
Almindelige fejl og pragmatiske løsninger
Selvmodsigende Overskrift som no-cache parret med expires langt ude i fremtiden forvirrer cacher; jeg sætter klare regler uden overlapning. Manglende ETags for dynamiske endpoints fører til unødvendige fulde downloads; jeg tilføjer en pålidelig identifikator og evaluerer if-none-match. For korte max-age-værdier spilder potentiale med filer, der sjældent ændres; jeg strækker deadlines og sikrer dem stadig med validering. Aggressiv caching af HTML forsinker synlige ændringer; jeg kombinerer no-cache med ETag og holder indholdet opdateret. Med klare beslutninger om friskhed, validering og gyldighed løser jeg disse snublesten og styrker Planlægbarhed.
Brug Vary rent og kontroller repræsentationer
For at sikre, at betingede anmodninger fungerer sikkert i delte cacher, sørger jeg for at bruge den korrekte Varierer. Headeren definerer, hvilke request-headers der påvirker repræsentationen. Typiske eksempler er Accept-Encoding (gzip, br), Accept-sprog og Accepter. Hvis jeg leverer indhold pr. sprog, indstiller jeg Vary: Accept-Language, så en proxy ikke deler den tyske version som svar på en fransk anmodning. Til personaliseret indhold undlader jeg bevidst Vary: Cookie og bruger i stedet Cache-kontrol: privat, for at undgå en ukontrollerbar eksplosion af cachenøgler. For ressourcer, der kun leveres med gyldig autorisation, bruger jeg enten private eller sikrer en klar adskillelse med Vary: Authorisation eller Vary på relevante headere. Konsistens er vigtig: Det valgte sæt af Vary-dimensioner skal forblive stabilt, ellers vil cache-hitraten og valideringsfordelene kollapse, fordi der hele tiden oprettes nye varianter.
Stærke vs. svage ETags, komprimering og byte-lighed
Stærke ETags karakteriserer byte-for-byte identiske repræsentationer og giver mulighed for præcis validering, også i kombination med rækkeviddeanmodninger. Svage ETags (W/...) signalerer kun indholdsmæssig lighed, ikke nødvendigvis identiske bytes. I praksis bruger jeg stærke ETags, hvis jeg kan generere en unik identifikator for hver repræsentation (inklusive komprimering). Så snart en reverse proxy bruger gzip eller brotli on-the-fly, tilpasser jeg ETag-generationen eller skifter til svage ETags, så serveren og klienten ikke fejlagtigt genkender forskellige bytes som identiske. En robust variant er at skabe ETag'et ud fra de sidste bytes i det leverede svar og samtidig bruge Vary: Accept-kodning skal indstilles. Det sikrer, at „gzip“ og „br“ får hver deres gyldige ETags. Hvor jeg ikke kan sikre byte-lighed (f.eks. forskellige tidsstempler i HTML), vælger jeg svage ETags, som stadig tillader pålidelige 304-svar, så længe sidens betydning ikke har ændret sig.
Cache-kontrol i finjustering: s-maxage, must-revalidate, stale-while-revalidate
Ud over max-alder Jeg bruger specifikt finere direktiver. s-maxage henvender sig udelukkende til Delte cacher (CDN'er, proxyer) og giver mig mulighed for at cache mere aggressivt der end i browseren. skal-revalidere tvinger kunderne til ikke at bruge udløbet indhold heuristisk, men til altid at validere det - nyttigt for kritiske data. proxy-revalidate adresserer denne forpligtelse specifikt til delte cacher. Med stale-while-revalidate Jeg tillader, at en lidt forældet kopi leveres kortvarigt, mens valideringen kører i baggrunden; brugerne ser noget med det samme, og den næste anmodning drager fordel af friske metadata. stale-if-fejl som et sikkerhedsnet: Hvis Origin fejler eller returnerer fejl, får cachen lov til at levere den sidst kendte kopi i et defineret tidsrum. For build-hashed-aktiver kombinerer jeg lang max-age med uforanderlig, da filnavnet ændres med indholdet, og mellemliggende valideringer er unødvendige. For HTML og API'er er no-cache plus validator fortsat guldstandarden for at sikre aktualitet og stadig spare båndbredde.
Yderligere betingelser og metoder: HEAD, rækkevidde og skrivekonflikter
Betingede anmodninger er ikke begrænset til GET. A HEAD-request giver kun headers og er ideel til hurtige valideringer uden body. Til store filer bruger jeg Rækkevidde-anmodninger; med If-område Jeg sørger for, at delområder kun sendes, hvis ressourcen stadig matcher den forventede version - ellers svarer jeg med 200 og en komplet body. For skriveoperationer sikrer jeg konsistens med Hvis-match ab: PUT, PATCH eller DELETE virker kun, hvis klientens ETag matcher den aktuelle version; ellers svarer jeg med 412 Precondition Failed. Når jeg vil håndhæve forhåndsbetingelser, f.eks. med konfliktramte ressourcer, bruger jeg 428 Precondition Required for at få klienterne til at bruge If-Match. Jeg vælger bevidst mellem 409 Conflict og 412: 412 signalerer overtrådte forudsætninger, 409 fremhæver indholdskonflikter (f.eks. regler for forretningslogik). Denne klarhed gør det lettere for klienterne at implementere og undgår blind overstyring.
Personalisering, cookies og databeskyttelse i praksis
På personlige sider markerer jeg svar med privat eller ingen opbevaring. Jeg undgår at kode brugertilstande i e-tags, fordi sådanne „per-bruger“-e-tags ufrivilligt kan blive sporingsmarkører. I stedet skelner jeg skarpt mellem offentlige og private repræsentationer. Jeg indstiller kun cookies i cachenøglen (Vary: Cookie), hvis det er absolut nødvendigt, fordi de øger antallet af varianter og reducerer hitraten dramatisk. For autoriserede API-svar holder jeg mig til Cache-kontrol: privat og om nødvendigt til Vary på Authorisation header-formatet. Det er sådan, jeg sikrer, at delte cacher ikke utilsigtet deler fortrolige svar. I applikationer med blandet indhold (offentlig basisramme, personaliserede underområder) bruger jeg fragmenteret caching eller edge ESI/SSI, mens kritiske dele forbliver private. Resultatet er databeskyttelse uden fald i performance.
Drift: CDN'er, surrogater og ugyldiggørelser
I CDN-opsætninger kombinerer jeg s-maxage med klare validatorer og - hvis det er muligt - bruge surrogatspecifikke direktiver til at styre edge caches separat fra browseren. Revalidering reducerer belastningen på Origin, men af og til er det nødvendigt med en hård validering (f.eks. en sikkerhedsrettelse). Jeg planlægger så to måder: Cache-brydning via filnavnehashes for statiske aktiver og Udrensning/Invalidation for HTML og API'er. Dette forhindrer „rensningsstorme“ og opretholder stadig en kort tid til opdatering. Det er også vigtigt at have en konsekvent cachenøgle i CDN'et (inklusive host, sti, forespørgselsparametre og relevante Vary-headere). For forespørgselsparametre skelner jeg bevidst mellem semantiske (f.eks. ?lang=) og rent sporingsrelaterede parametre; jeg ignorerer sidstnævnte i cachenøglen for at undgå fragmentering. Dette holder kæden af browsercache, mellemliggende proxy og CDN gennemsigtig og forudsigelig.
304 i detaljer: Opdater header og metadata korrekt
Også en 304-Svaret indeholder vigtige metadata. Jeg leverer Date, Cache-Control, ETag/Last-Modified og - hvis det er relevant - Expires og Vary igen, så klienten kan opdatere sine cache-poster. Content-Type og Content-Encoding behøver ikke nødvendigvis at blive gentaget, men kan bidrage til klarhed. Det er vigtigt, at 304 ikke indeholder en body payload, og at jeg sender konsistente validatorer: Ændring af ETag i 304 uden at ændre repræsentationen fører til forvirring. Hvis retningslinjerne justeres (f.eks. længere max-age), kan klienten tage metadataene til sig uden at skulle genindlæse kroppen - et lille greb med en stor indvirkning på den opfattede ydeevne.
Test- og fejlfindingsstrategier til ren validering
Jeg tjekker specifikt følgende punkter i DevTools: fra diskcache vs. fra hukommelsescache vs. revalideret; Status 200/304; Age-header i svar fra delte cacher; ETag/Last-Modified-konsistens og effekten af Vary. For reproducerbare tests deaktiverer jeg midlertidigt browserens cache eller bruger en privat tilstand. På serversiden evaluerer jeg logs på 200/304-forholdet, den gennemsnitlige svarstørrelse og CPU-udnyttelse. Advarselssignaler er f.eks. mange 200-svar på ressourcer med korte ændringsintervaller (manglende validatorer), revalideringsløkker (afvigende tider/urdrift) eller et usædvanligt stort antal varianter pr. URL (overdreven Vary). Jeg bruger belastningstests til at tjekke, hvordan s-maxage, stale-while-revalidate og if-none-match opfører sig under pres - og justerer direktiverne, indtil throughput og latency matcher.
Kanttilfælde og robuste standardindstillinger
Ikke alle ressourcer har klare regler for ændringer. Jeg indstiller omhyggelige standarder for genererede sitemaps, feeds eller dashboards: no-cache plus ETag/Last-Modified. Med ustabile ure mellem upstream-systemer undgår jeg stive sekundsammenligninger og foretrækker ETags, der er uafhængige af tidsstempler. Hvis komprimeringen er variabel (forskellige gzip-niveauer), inkluderer jeg resultatet af komprimeringen i ETag-generationen eller skifter til svage ETags. Og hvis klienter anmoder uden validatorer, sender jeg klare signaler: Enten klar friskhed (max-age/immutable) eller klar validering (no-cache + ETag). Disse robuste standardindstillinger sikre, at selv ufuldstændige eller defekte klienter ikke udløser uønskede belastningsspidser.
Kort resumé
Forbind betingede anmodninger Hastighed og aktualitet ved kun at lade klienter hente komplette ressourcer, når indholdet er ændret. Jeg bruger cache-kontrol til at sikre friskhed, kombinerer last-modified og ETag til pålidelig kontrol og svarer konsekvent med 304, hvis betingelserne er opfyldt. Jeg isolerer personligt og fortroligt indhold med private eller no-store, så ingen data ender i delte cacher. Målinger i DevTools, logs og metrics viser mig, hvor jeg kan strække deadlines eller stramme op på valideringslogikken. Hvis du tænker på disse byggesten sammen, vil du opnå hurtigere sider, reduceret serverbelastning og en mere rund Brugeroplevelse uden spild af data.
