Hoppa till innehåll 
HTTP Villkorlig Förfrågningar minskar överföringskostnaderna genom att säkerställa att klienten bara laddar en resurs helt och hållet om den faktiskt har ändrats sedan den senaste förfrågan. Jag kommer att visa hur Cache-validering med ETag, Last-Modified, If-None-Match, If-Modified-Since och 304 Not Modified fungerar tillförlitligt och laddningstiderna förkortas märkbart.
Centrala punkter
- Validering istället för fullständig nedladdning: 304 sparar bandbredd och tid.
- ETag och Last-Modified fungerar tillsammans för ren kontroll.
- Cache-kontroll definierar färskhet, upphör endast att gälla tillägg.
- Förutsättningar till exempel If-Match säkra skrivprocesser.
- Säkerhet kräver privat/no-store för känsligt innehåll.
Vad villkorliga förfrågningar gör i vardagen
Jag ställer in Villkorlig begär att få ställa en tydlig fråga till servern: Behöver jag verkligen överföra nya data eller räcker det med min cache? Webbläsaren eller en proxy skickar villkor, servern kontrollerar om en fil har ändrats och svarar med 304 Not Modified utan kropp. Det här mönstret håller HTML, CSS, JavaScript, bilder och API-svar uppdaterade och minskar belastningen på infrastrukturen avsevärt. För tillgångar med längre giltighetstid använder jag långa max-age-värden och säkerställer att de är uppdaterade genom validering. Om du har rätt Strategier för kontroll av cacheminnet får ut maximalt av cacheminnet utan att riskera föråldrat innehåll.
Headers som möjliggör validering av cache
För pålitlig Cache-Kunden behöver tydliga signaler från svaret för att kunna fatta beslut. Jag använder Cache-Control för färskhet och regler, Expires ibland som ett komplement och Last-Modified och ETag för den faktiska valideringen. Last-Modified ger en ändringstid som kan kontrolleras snabbt, medan ETag ger en versionsidentifierare som också används för dynamiskt innehåll. Det är fortfarande viktigt: no-cache betyder validera före användning, inte ta bort. Om du tillämpar denna semantik korrekt kommer du att uppnå märkbart mindre datatrafik samtidigt som innehållet hålls uppdaterat. Innehåll.
Sekvensen för en villkorad begäran utan omvägar
Vid det första anropet sparar klienten filen och valideringsvärden som t.ex. ETag eller Last-Modified i cacheminnet. Senare löper resursen ut eller kräver en ny kontroll före användning, och klienten skickar If-None-Match eller If-Modified-Since. Servern jämför informationen med den aktuella statusen och returnerar antingen 200 OK med en ny body eller 304 Not Modified utan nyttolast. Klienten fortsätter sedan att använda den befintliga kopian och sparar överföring, TLS-arbetsbelastning och tid. Denna ping-pong verkar oansenlig, men den Effekt på belastningskänsla och serverbelastning är tydlig.
ETag vs. Last-Modified i direkt jämförelse
Jag använder Senast modifierad Jag gillar att använda tidsstämplar som en snabb och enkel referens, men använder ETags för finkornig kontroll. Tidsstämplar kan nå sina gränser med mycket korta förändringsintervall eller förfalska dynamiska utdata. Jag skapar ETags från filhashar, databasversioner eller renderings-varianter, varigenom varje förändring i innehållet genererar en ny identifierare. Båda mekanismerna kan kombineras: Klienten kan skicka If-None-Match och If-Modified-Since parallellt, och servern väljer lämplig kontroll. Det är så här jag säkerställer en tillförlitlig Validering, vilket gäller både för statiska och dynamiska resurser.
| Kriterium | Senast modifierad | ETag |
|---|---|---|
| Noggrannhet | Andra upplösningen, lämplig för filer | Versionsidentifierare för varje innehållsändring |
| Dynamik | Svag med frekventa, icke filbaserade förändringar | Stark för API:er och renderat innehåll |
| Utgifter | Låg, tillgänglig från filsystemet | Låg till måttlig, generering i app/proxy |
| Konflikter | Klockavvikelser möjliga | Felaktigt konfigurerade weak/strong-taggar möjliga |
Korrekta inställningar för webbläsarens cachelagring och API:er
För statiska tillgångar använder jag långa max-ålder och spara via ETag eller filnamnshash så att uppdateringar känns igen omedelbart. Jag markerar ofta HTML- och API-svar med no-cache så att klienten validerar före användning utan att behöva ladda om allt varje gång. Jag markerar personliga sidor med private så att delade cacher inte visar något som har behållits för andra. Fel orsakas ofta av motsägelsefulla direktiv eller saknade valideringsheaders, vilket jag undviker med tydliga regler. Om man känner till de typiska stötestenarna kan man lätt undvika dem; bra exempel på detta finns i artikeln om Header-traps i cachning, som jag gillar att orientera mig efter.
Använd statuskoder och villkor på ett effektivt sätt
Jag organiserar Statuskoder tydligt: 200 OK levererar innehåll, 304 Not Modified bekräftar cache-användning och 412 Precondition Failed avbryter om ett villkor inte uppfylls. För säkra skrivoperationer använder jag If-Match så att uppdateringar endast träder i kraft om ETag motsvarar den förväntade versionen. Läsning med If-None-Match eller If-Modified-Since förhindrar överflödiga nyttolaster och håller klienterna synkroniserade. Konsekvent beteende är viktigt: Samma slutpunkt bör svara identiskt för identiska förutsättningar. För SEO och robotar är jag uppmärksam på hur cacher och crawlers tolkar statusmeddelanden; en bra översikt över HTTP-statuskoder och crawling hjälper till med rena beslut.
Säkerhet och dataskydd för cachelagring
Jag behandlar känsligt innehåll med ingen lagring och ger dem därmed ingen chans att hamna i webbläsarens eller proxyns cache. Jag markerar personaliserade sidor med Cache-Control: private och kontrollerar att inga personuppgifter förekommer i långtidscachade webbadresser. Jag utformar ETags neutralt, utan att tillåta att slutsatser dras om användarkonton eller interna ID:n. Jag avaktiverar konsekvent all cachelagring för inloggningsvyer och bankflöden. Om du kombinerar dataminimering, lämpliga direktiv och rena headers minskar du risken och skyddar dina uppgifter. Konfidentialitet.
Implementering: Steg för server och applikation
I början separerar jag statisk av dynamiska resurser och bestämma var långa deadlines är meningsfulla och var validering har prioritet. I Nginx, Apache eller en appserver konfigurerar jag cache control och aktiverar last-modified och ETags, varvid jag placerar ETag-generering i applikationen för dynamiska endpoints. När jag bearbetar inkommande förfrågningar utvärderar jag If-None-Match och If-Modified-Since och svarar med 304 om villkoret stämmer. För skrivoperationer använder jag If-Match och returnerar 412 i händelse av avvikelser för att förhindra överskrivning. Detta skapar ett konsekvent beteende som använder cacheminnet effektivt och samtidigt Korrekthet säkerställer.
Använd mätvärden, tester och övervakning på ett förnuftigt sätt
Jag kontrollerar Nätverk-fliken i DevTools för att kontrollera om resurser kommer från cacheminnet, valideras eller är nyladdade. Jag övervakar status, åldersvärden, ETags och storleken på det överförda svaret. Under belastning mäter jag latens, överföringsvolym och server-CPU för att se den faktiska effekten av 304 svar. Loggar från den omvända proxyn visar om delade cacheminnen gör sitt jobb och hur många valideringar som lyckas. Jag använder dessa data för att justera max-age, cachekontrolldirektiv och ETag-strategier tills svarstiderna och Träfffrekvens rösta.
Hostingprestanda: Varför villkorade förfrågningar sparar pengar
Varje 304Det delade cachesvaret sparar bandbredd, minskar TLS-overhead och förkortar svarstiden, vilket är särskilt viktigt för många liknande förfrågningar. I hostingupplägg med reverse proxies, lastbalanserare och CDN:er uppnår jag störst effekt när jag tydligt tillåter eller specifikt utesluter delade cacher. Mindre överföring innebär ofta också lägre trafikkostnader i euro och mer reserver för verkliga belastningstoppar. Användarupplevelsen förbättras också eftersom upprepade sidvisningar och API-undersökningar svarar snabbare. På så sätt realiserar jag prestandapotential som rena hårdvaruuppgraderingar inte kan leverera och använder befintliga Infrastruktur bättre.
Vanliga misstag och pragmatiska lösningar
Motsägelsefull Huvud som no-cache parat med expires långt in i framtiden förvirrar cacher; jag sätter tydliga regler utan duplicering. Saknade ETags för dynamiska ändpunkter leder till onödiga fullständiga nedladdningar; Jag lägger till en pålitlig identifierare och utvärderar om ingen matchning. För korta max-age-värden slösar bort potential med filer som sällan ändras; jag tänjer på deadlines och säkrar dem ändå med validering. Aggressiv cachelagring av HTML fördröjer synliga ändringar; jag kombinerar no-cache med ETag och håller innehållet uppdaterat. Med tydliga beslut om färskhet, validering och giltighet löser jag dessa stötestenar och stärker Planerbarhet.
Använd Vary på ett rent sätt och kontrollera representationer
För att säkerställa att villkorliga begäranden fungerar säkert i delade cacheminnen ser jag till att använda rätt Varierande. Huvudet definierar vilka begärande huvuden som påverkar representationen. Typiska exempel är Accept-Encoding (gzip, br), Acceptera språk och Acceptera. Om jag levererar innehåll per språk ställer jag in Vary: Accept-Language så att en proxy inte delar den tyska versionen som svar på en fransk begäran. För personanpassat innehåll avstår jag medvetet från Vary: Cookie och använder i stället Cache-kontroll: privat, för att undvika en okontrollerbar explosion av cache-nycklar. För resurser som endast levereras med giltig auktorisering använder jag antingen private eller säkerställer en tydlig åtskillnad med Vary: Authorisation eller Vary på relevanta rubriker. Konsekvens är viktigt: den valda uppsättningen Vary-dimensioner måste vara stabil, annars kommer träfffrekvensen i cachen och valideringsfördelarna att kollapsa eftersom nya varianter ständigt skapas.
Starka kontra svaga ETags, komprimering och byte-likhet
Starka ETags karakterisera identiska representationer byte för byte och möjliggöra exakt validering, även i kombination med begäran om intervall. Svaga ETags (W/...) signalerar bara innehållsmässig likhet, inte nödvändigtvis identiska byte. I praktiken använder jag starka ETags om jag kan generera en unik identifierare för varje representation (inklusive komprimering). Så snart en omvänd proxy använder gzip eller brotli i farten anpassar jag ETag-generering eller byter till svaga ETags så att servern och klienten inte felaktigt känner igen olika byte som identiska. En robust variant är att skapa ETag från de sista bytena i det levererade svaret och samtidigt använda Vary: Acceptera-kodning ska ställas in. Detta säkerställer att „gzip“ och „br“ får var sin giltig ETag. Där jag inte kan säkerställa byte-likhet (t.ex. olika tidsstämplar i HTML) väljer jag svaga ETags som fortfarande tillåter tillförlitliga 304-svar så länge sidans innebörd inte har ändrats.
Cache-kontroll i finjustering: s-maxage, must-revalidate, stale-while-revalidate
Förutom max-ålder Jag använder specifikt finare direktiv. s-maxage adresserar uteslutande Delade cacheminnen (CDN, proxyservrar) och gör det möjligt för mig att cachelagra mer aggressivt där än i webbläsaren. måste-omvalidera tvingar kunderna att inte använda utgått innehåll heuristiskt, utan att alltid validera det - till hjälp för kritisk data. proxy-revalidate tar upp denna skyldighet specifikt för delade cacheminnen. Med stale-under-validering Jag tillåter att en något föråldrad kopia levereras tillfälligt medan valideringen körs i bakgrunden; användarna ser något omedelbart, och nästa begäran drar nytta av nya metadata. stale-om-fel som ett skyddsnät: Om Origin misslyckas eller returnerar fel får cacheminnet leverera den senast kända kopian under en definierad tid. För tillgångar med bygghash kombinerar jag lång max-age med oföränderlig, eftersom filnamnet ändras med innehållet och mellanliggande valideringar är onödiga. För HTML och API:er är no-cache plus validator fortfarande guldstandarden för att säkerställa aktualitet och samtidigt spara bandbredd.
Ytterligare villkor och metoder: HEAD, räckvidd och skrivkonflikter
Villkorade förfrågningar är inte begränsade till GET. A HEAD-request innehåller bara rubriker och är perfekt för snabba valideringar utan text. För stora filer använder jag Räckvidd-förfrågningar; med If-intervall Jag ser till att partiella områden endast skickas om resursen fortfarande matchar den förväntade versionen - annars svarar jag med 200 och en fullständig body. För skrivoperationer säkerställer jag konsekvens med If-Match ab: PUT, PATCH eller DELETE fungerar bara om klientens ETag matchar den aktuella versionen; annars svarar jag med 412 Precondition Failed. Där jag vill genomdriva förhandsvillkor, till exempel med konfliktbenägna resurser, använder jag 428 Precondition Required för att få klienter att använda If-Match. Jag väljer medvetet mellan 409 Conflict och 412: 412 signalerar brutna förhandsvillkor, 409 betonar innehållskonflikter (t.ex. affärslogiska regler). Denna tydlighet underlättar klienternas implementering och undviker blinda åsidosättanden.
Personalisering, cookies och dataskydd i praktiken
För personliga sidor markerar jag svar med privat eller . ingen lagring. Jag undviker att koda användartillstånd i e-taggar eftersom sådana „per-användare“-e-taggar ofrivilligt kan bli spårningsmarkörer. Istället gör jag en strikt åtskillnad mellan offentliga och privata representationer. Jag ställer bara in cookies i cache-nyckeln (Vary: Cookie) om det är absolut nödvändigt, eftersom de ökar antalet varianter och dramatiskt minskar träfffrekvensen. För auktoriserade API-svar håller jag mig till Cache-kontroll: privat och, om nödvändigt, till Vary på huvudformatet Authorisation. På så sätt säkerställer jag att delade cacheminnen inte oavsiktligt delar konfidentiella svar. I applikationer med blandat innehåll (offentligt grundläggande ramverk, personliga underområden) förlitar jag mig på fragmenterad cachelagring eller edge ESI/SSI, medan kritiska delar förblir privata. Resultatet är dataskydd utan att prestandan försämras.
Drift: CDN, surrogat och ogiltigförklaringar
I CDN-konfigurationer kombinerar jag s-maxage med tydliga validerare och - om tillgängligt - använda surrogatspecifika direktiv för att styra kantcacher separat från webbläsaren. Revalidering minskar belastningen på Origin, men ibland är det nödvändigt med en hård validering (t.ex. säkerhetsfix). Jag planerar då två sätt: Cache-borttagning via filnamnshashar för statiska tillgångar och Utrensning/Invalidering för HTML och API:er. Detta förhindrar „purge storms“ och upprätthåller fortfarande en kort tid till uppdatering. Det är också viktigt att ha en konsekvent cache-nyckel i CDN (inklusive värd, sökväg, frågeparametrar och relevanta Vary-rubriker). För frågeparametrar skiljer jag medvetet mellan semantiska (t.ex. ?lang=) och rent spårningsrelaterade parametrar; jag ignorerar de senare i cache-nyckeln för att undvika fragmentering. Detta gör att kedjan med webbläsarens cache, mellanliggande proxy och CDN är transparent och förutsägbar.
304 i detalj: Uppdatera rubrik och metadata korrekt
Även en 304-Svaret innehåller viktiga metadata. Jag levererar Date, Cache-Control, ETag/Last-Modified och - om det är relevant - Expires och Vary igen så att klienten kan uppdatera sina cacheposter. Content-Type och Content-Encoding behöver inte nödvändigtvis upprepas, men kan bidra till tydlighet. Det är viktigt att 304 inte innehåller en body payload och att jag skickar konsekventa validatorer: Att ändra ETag i 304 utan att ändra representationen leder till förvirring. Om riktlinjerna justeras (t.ex. längre max-age) kan klienten anta metadata utan att behöva ladda om kroppen - en liten hävstång med stor inverkan på den upplevda prestandan.
Test- och felsökningsstrategier för ren validering
Jag kontrollerar särskilt följande punkter i DevTools: från diskcache mot. från minnescache mot. omvaliderad; Status 200/304; Åldershuvud i svar från delade cacheminnen; ETag/Last-Modified-konsistens och effekten av Vary. För reproducerbara tester avaktiverar jag webbläsarens cache tillfälligt eller använder ett privat läge. På serversidan utvärderar jag loggar med avseende på förhållandet 200/304, den genomsnittliga svarsstorleken och CPU-användningen. Varningssignaler är t.ex. många 200-svar till resurser med korta ändringsintervall (validerare saknas), revalideringsloopar (avvikande tider/klockdrift) eller ett ovanligt stort antal varianter per URL (överdriven Vary). Jag använder belastningstester för att kontrollera hur s-maxage, stale-while-revalidate och if-none-match beter sig under press - och justerar direktiven tills genomströmning och latens matchar.
Kantfall och robusta standardvärden
Inte alla resurser har tydliga ändringsregler. Jag ställer in försiktiga standardvärden för genererade webbplatskartor, flöden eller instrumentpaneler: ingen cacheminne plus ETag/Last-Modified. Med instabila klockor mellan uppströmssystem undviker jag rigida sekundjämförelser och föredrar ETags som är oberoende av tidsstämplar. Om komprimeringen är variabel (olika gzip-nivåer) inkluderar jag resultatet av komprimeringen i ETag-generationen eller byter till svaga ETags. Och om kunder begär utan validerare skickar jag tydliga signaler: Antingen tydlig färskhet (max-age/immutable) eller tydlig validering (no-cache + ETag). Dessa robusta standardvärden säkerställa att inte ens ofullständiga eller felaktiga klienter orsakar oönskade belastningstoppar.
Kort sammanfattning
Ansluta villkorliga förfrågningar Hastighet och aktualitet genom att klienter endast hämtar fullständiga resurser när innehållet har ändrats. Jag använder cache-kontroll för färskhet, kombinerar senast modifierad och ETag för tillförlitliga kontroller och svarar konsekvent med 304 om villkoren är uppfyllda. Jag isolerar personligt och konfidentiellt innehåll med private eller no-store så att inga data hamnar i delade cacheminnen. Mätningar i DevTools, loggar och mätvärden visar mig var jag kan tänja på deadlines eller skärpa valideringslogiken. Om du tänker på dessa byggstenar tillsammans kommer du att uppnå snabbare sidor, minskad serverbelastning och en rundare Användarupplevelse utan slöseri med data.
