Hoppa till innehåll 
HTTP-caching sparar tid och data genom att resurser endast laddas om när de faktiskt har ändrats. Om ETag och Senast modifierad kontrollerar jag med hjälp av en villkorad förfrågan om servern svarar med 304 Not Modified, vilket avsevärt minskar dataöverföringen och belastningen på servern.
Centrala punkter
Följande huvudpunkter visar vad jag lägger vikt vid när det gäller villkorlig cachelagring med ETag och Senast modifierad uppmärksamhet.
- Mindre trafik: Oförändrade filer returnerar 304, inte hela innehållet – vilket märkbart minskar datamängden och latensen.
- Bättre prestanda: Kortare väntetider förbättrar användarupplevelsen och Core Web Vitals, vilket SEO hjälper.
- Två mekanismer: Last-Modified/If-Modified-Since och ETag/If-None-Match validerar cachen på ett säkert sätt.
- Cache-kontroll: Direktiv styr uppdateringsfrekvens, uppdatering och beteende i mellanliggande cacher.
- Kombination: Tillsammans ger dessa båda metoderna hög precision och enkla reservlösningar.
Jag undersöker först vilka resurser som verkligen ändras ofta och vilka som ändras sällan. För filer som sällan ändras sätter jag en Senast modifierad-tidpunkt och lägger till en ETag. För dynamiska svar föredrar jag att använda ETag, eftersom varje innehållsändring märks omedelbart. På så sätt avlastar jag servrarna, minskar fördröjningarna och levererar mycket snabba sidor till återkommande besökare. Denna strategi stärker Core Web Vitals och därmed indirekt synligheten.
HTTP-caching med villkor: Så här kontrollerar jag giltigheten
Vid en ny begäran skickar klienten, utöver GET, ytterligare rubriker som jag analyserar på serversidan. Om resursen har samma ETag Om innehållet är detsamma som i cachen (If-None-Match) returnerar jag 304 Not Modified utan huvudtext. Om tidsstämpeln inte har ändrats (If-Modified-Since) svarar servern också med 304. Om dag eller datum inte stämmer längre skickar jag 200 OK med nytt innehåll plus uppdaterad Senast modifierad och ETag. På så sätt sparar jag bandbredd, håller cachen uppdaterad och säkerställer märkbart snabbare laddningstider.
Last-Modified och If-Modified-Since i vardagen
Rubriken Senast modifierad Jag utgår från filens faktiska ändringstidpunkt, till exempel från filsystemet. Om en begäran med If-Modified-Since kommer senare och resursen inte har ändrats sedan dess, svarar jag med 304. Denna metod är okomplicerad, lätt att förstå och idealisk för statiska tillgångar som CSS, JS eller bilder. Begränsningar uppstår på grund av sekundrasteret i HTTP-tidsstämplar och situationer där innehåll logiskt ändras utan att det finns en tydlig filtidpunkt. Där Last-Modified stöter på sina gränser kompletterar en ETag kontrollen.
ETag och If-None-Match i dynamiska system
En ETag genererar jag som en hash, ett versions-ID eller från en databaskolumn som markerar statusförändringar. Vid återkommande åtkomst skickar webbläsaren If-None-Match, jag jämför taggen med mitt aktuella värde och svarar därefter med 304 eller 200. Denna jämförelse upptäcker alla meningsfulla innehållsändringar utan att förlita sig på filens tidsstämpel. Särskilt vid API:er, sammansatta sidor eller personaliserade fragment ger detta mycket exakta resultat. Det är viktigt att jag håller ETags konsekventa i klustermiljöer, så att ingen server av misstag använder en annan Dag produceras.
Att kombinera Cache-Control på rätt sätt
Med Cache-kontroll Här definierar jag hur länge innehåll ska betraktas som aktuellt utan att behöva hämtas på nytt, och när webbläsaren ska göra en ny validering. Jag anger lämpliga max-age-värden beroende på hur ofta innehållet ändras och använder must-revalidate om föråldrade data skulle vara kritiska. För versionerade filer är en lång giltighetstid lämplig, medan svar som ändras ofta har kortare livslängd och sedan kan kontrolleras korrekt via ETag eller datum. På så sätt kombinerar jag korta svarstider med korrekt aktualitet. Den som vill fördjupa sig i ämnet hittar många exempel under Strategier för cachekontroll, som jag använder i praktiken.
Steg-för-steg-beskrivning av ett villkorligt GET-förfrågan
Vid den första begäran skickar servern 200 OK med Cache-Control, Senast modifierad och ETag, webbläsaren sparar allt. Vid nästa besök avgör cachen hur gammal informationen är om en omvalidering behövs. Om så är fallet skickar webbläsaren en förfrågan med If-None-Match och/eller If-Modified-Since. Om värdena stämmer överens med det aktuella läget skickar jag 304 Not Modified, och klienten fortsätter att använda sin cache. Om de inte längre stämmer följer 200 OK med ny body och uppdaterad Valideringsdata.
Jämförelse: ETag vs. Last-Modified
Båda metoderna ger mig kontroll, men skiljer sig åt när det gäller arbetsinsats, noggrannhet och lämplighet. Senast modifierad utmärker sig genom enkel implementering och tydlig semantik, så länge jag har korrekta tidsstämplar. ETag återger innehållet mycket exakt, men kräver lite logik för att genereras. I många konfigurationer kombinerar jag båda och drar därmed nytta av enkelhet och exakt identifiering. Följande tabell sammanfattar typiska egenskaper och hjälper till vid beslutet.
| Aspekt | Senast modifierad | ETag | Ledtråd |
|---|---|---|---|
| Identitet | Tidstämpel för senaste ändringen | Innehållshash eller versions-ID | Tid vs. innehållsbaserad identifierare |
| Ändringsdetektering | Sekundupplösning, indirekt | Direkt inriktat på innehållet | ETag upptäcker de minsta Skillnader |
| implementering | Mycket lätt, filsystemet räcker | Kräver generering och konsekvens | Kluster behöver samma ETags |
| Användning | Statiska tillgångar | Dynamiska svar | Kombinationen täcker många Fall från |
| Svar på frågor | 304 med oförändrad tidsstämpel | 304 vid identisk tagg | 200 vid ändringar med nytt Värde |
I praktiken: Effektiv leverans av statiska tillgångar
Statiska filer som CSS, JS och bilder ändras sällan och lämpar sig väl för långa max-ålder-tider. För versionerade filer anger jag långa tidsintervall på upp till ett år och markerar dem som oföränderliga, så att webbläsaren laddar dem utan att fråga om bekräftelse. För icke-versionerade tillgångar väljer jag kortare tidsgränser och förlitar mig på omvalidering via ETag och Last-Modified. På så sätt undviker jag föråldrat innehåll och håller trafiken låg. Om jag ser till att inte Sabotage av cachehuvud genom att låta den göra det uppnår jag en hög träfffrekvens i cachen.
I praktiken: API:er och dynamiska sidor
När det gäller API:er brukar jag oftast satsa på ETags, som jag skapar utifrån det serialiserade resultatet eller en versionskolumn. Om dataposten ändras genererar jag en ny tagg, vilket klienterna upptäcker omedelbart. För innehåll med osäker tidsstämpel avstår jag ofta från Last-Modified, så att inget felaktigt intryck av aktualitet uppstår. Som komplement styr jag livslängden via Cache-Control och tvingar fram en omvalidering efter utgången. På så sätt håller jag data tillförlitligt aktuella utan att göra svaren onödigt stora.
Testning och övervakning av cache-träfffrekvens
Jag kontrollerar rubriker som ETag, Last-Modified, If-None-Match och If-Modified-Since i utvecklarverktygen. Då håller jag koll på svarskoderna, särskilt 304 jämfört med 200, för att se hur effektiv min omvalidering är. Om 304 sällan förekommer justerar jag Cache-Control, giltighetstider och ETag-generering. Loggar och mätvärden visar mig vilka sökvägar som ger onödigt stora svar. För samlade förbättringar använder jag gärna ett Paketet Conditional-Requests, som kombinerar konfiguration och tester.
Webbhotellarkitektur och ETag-fällor
I installationer med flera servrar måste en ETag vara oberoende av instansen, annars fungerar inte igenkänningen. Jag ser till att alla noder använder samma logik och samma nyckel för genereringen. Omvända proxyservrar eller CDN-tjänster får inte ändra ETag-värden och bör vidarebefordra villkorsrubriker korrekt. Vid distributioner med tillgångsfingeravtryck undviker jag serverbaserad omberäkning av ETag om filen redan har en versionerad URL. Enhetliga regler förhindrar inkonsekventa svar och håller cache-träfffrekvensen hög.
Färskhet kontra validering: Använd direktiv på ett precist sätt
Jag gör en tydlig åtskillnad mellan Färskhet (hur länge får en cache använda en kopia utan att fråga?) och Validering (hur kontrollerar jag om den fortfarande är giltig?). Om Cache-kontroll jag styr båda på ett mycket detaljerat sätt: max-ålder anger livslängden för klienten, s-maxage för delade cacher som proxyservrar. allmänheten tillåter cachelagring i delade cacheminnen, privat begränsar det till slutwebbläsaren. måste-omvalidera kräver uppföljning efter utgången, medan oföränderlig förhindrar onödiga omvalideringar av versionerade tillgångar. ingen cacheminne förbjuder inte caching, utan kräver alltid en omvalidering; ingen lagring förbjuder däremot lagring helt och hållet. Äldre Upphör att gälla-Header använder jag bara som reservlösning, jag flyttar konsekvent logiken till Cache-Control. Och om jag vill mildra avbrott hjälper stale-under-validering och stale-om-fel, för att kunna visa innehåll som nyligen har upphört att gälla, medan jag uppdaterar i bakgrunden eller hanterar eventuella fel.
Starka och svaga ETags, komprimering och varianter
Jag gör ett medvetet val mellan starka och svaga validerare. Starka ETags identifiera exakt samma representation på byte-nivå – perfekt om jag också Förfrågningar om intervall vill betjäna på ett effektivt sätt. Svaga ETags (Prefix W/) räcker om semantisk överensstämmelse är tillräcklig, till exempel vid små, irrelevanta formatändringar. Det viktiga är hanteringen av Kompression: Om jag levererar både gzip- och brotli-komprimerat innehåll får inte en och samma ETag gälla för alla varianter. Antingen skapar jag taggen utifrån den okomprimerade versionen och lägger dessutom till en passande Vary: Acceptera-kodning, eller så genererar jag konsekventa men olika ETags för varje variant. På så sätt undviker jag felaktiga träffar och 200-svar som egentligen borde vara 304. Vid If-intervall Jag kombinerar räckviddskontroller med en validerare: Om ETag eller datum stämmer svarar jag med 206 Partial Content; i annat fall skickar jag 200 med fullständig kropp, så att klienten får en konsekvent grund.
Att behärska Vary-Header och innehållsförhandling på ett korrekt sätt
När servern levererar olika representationer beroende på behov, sätter jag Varierande korrekt. Typiska exempel är Accept-Encoding (kompression), Acceptera språk (lokalisering) eller specifika funktionsflaggor. Jag undviker att använda flyktiga huvudfiler som Användaragent eller till och med Kaka att variera, eftersom det kraftigt försämrar cache-träfffrekvensen. När personalisering krävs markerar jag svaren som privat eller . ingen lagring och skilj dem tydligt från resurser som kan cachelagras offentligt. Viktigt: Variationerna påverkar även ETags – varje variant behöver sin egen, korrekta validator. På så sätt säkerställer jag att webbläsare, proxyservrar och CDN:er tillämpar samma logik och att ingen variant av misstag blandas ihop med en annan.
Villkorade förfrågningar utöver GET
Villkorliga förfrågningar fungerar inte bara vid läsning. För skrivande metoder använder jag If-Match eller . If-Unmodified-Sincetill saknade uppdateringar för att förhindra detta. Om klienten vid en PUT- eller DELETE-begäran skickar den senast sedda ETag via If-Match om, genomför jag ändringen endast om serverns status fortfarande är densamma – annars svarar jag med 412 Förutsättning uppfylld. För att hålla ordning på klienterna kan servern dessutom 428 Förutsättning krävs etablera. För snabba tester utan Body använder jag HEAD, som ger mig samma rubriker som ett GET-förfrågan; perfekt när jag vill testa metadata. Och vid 304-I svaren skickar jag med alla rubriker som är relevanta för cachen (Cache-Control, ETag, Expires, Last-Modified) på nytt, så att klienten uppdaterar sina metadata utan att överföra själva innehållet.
Säkerhet, dataskydd och efterlevnad
Jag sparar inte personuppgifter eller känsligt innehåll i den offentliga cachen. Här använder jag Cache-kontroll: privat eller . ingen lagring, så att webbläsaren eller någon annan instans inte lagrar innehållet. Var försiktig med användarkonton och instrumentpaneler: Svara med Ställ in cookie eller . Auktorisering får inte av misstag vara offentligt cachbara. ETags i sig kan missbrukas som spårningsverktyg om de förblir oförändrade under lång tid. Jag hanterar detta genom att endast aktivt använda validerare där caching är önskvärt, och inaktivera dem för användarspecifika rutter eller hålla livslängden kort. På så sätt förenar jag prestanda med dataskyddskrav.
Implementeringsdetaljer och prestandakostnader
Kostnaden för att skapa en ETag får inte överstiga nyttan. För stora filer eller kostsamma renderingar sparar jag taggen tillsammans med metadata (filkontrollsumma, build-hash, databas-radversion) och återger den inte vid varje förfrågan. Vid sammansatta sidor är det bra med en Strategi för versionsskapande: Jag bygger upp ETag-värdet av stabila del-ETag-värden (t.ex. mall, datafragment, konfiguration), så att små ändringar ger ett specifikt men reproducerbart nytt värde. I kluster synkroniserar jag genereringslogiken i ett gemensamt bibliotek och kontrollerar den i CI så att ingen instans avviker. För extremt stora blobbar använder jag snabba kontrollsummor (CRC64) eller lagrar bygghashar istället för att hasha kroppen direkt. Där absolut byte-likhet inte är nödvändig räcker det med svaga ETags som en pragmatisk kompromiss.
Vanliga misstag och hur du undviker dem
- Slumpmässiga ETags: Om taggar genereras på nytt vid varje förfrågan blir varje omvalidering meningslös. Jag ser till att värdena är deterministiska och endast ändras vid faktiska förändringar.
- Felaktig kombination av direktiv: ingen lagring Att använda ETag är meningslöst – webbläsaren lagrar ändå inte informationen. Jag väljer konsekventa kombinationer för att uppnå önskat beteende.
- Överdriven variation: Variationer i Cookie eller User-Agent splittrar cachen. Jag begränsar Vary till faktiska ändringar av representationen.
- Kompressionsfällor: En gemensam ETag för gzip och br leder till felaktiga träffar. Jag kopplar ETags korrekt till den specifika varianten och anger Vary på rätt sätt.
- Tidsavvikelse: Felaktiga serverklockor förvränger Last-Modified. Jag ser till att tidskällorna är synkroniserade så att If-Modified-Since fungerar korrekt.
- Förväxling av no-cache: Många läser det som „inte cacha“. Det som menas är „alltid revidera“. För ett verkligt förbud använder jag ingen lagring.
Felsökning, mätvärden och arbetsflöden
För felsökning börjar jag på fliken Nätverk: Stämmer Cache-kontroll? Används vid rehabilitering 304 istället för 200? Passar ETag och Senast modifierad mellan förfrågan och svar? Jag kollar upp det Varierande, för att se om varianterna har identifierats korrekt. I loggarna visar jag Träff/Miss-Visa andelar, 304-frekvenser och genomsnittliga svarsstorlekar per sökväg. Om 304-frekvensen ökar minskar vanligtvis datavolymen och TTFB märkbart. I belastningstester simulerar jag upprepade anrop för att mäta revalideringskostnader istället för överföringskostnader. Vid avvikelser tar jag stegvis bort störande faktorer: Set-Cookie, alltför strikta Vary-regler, motstridiga rubriker som Pragma. På så sätt hittar jag snabbt den flaskhals som trycker ner träfffrekvensen.
Service Worker som ett kompletterande cache-lager
Om jag använder en service worker, använder jag den som ett komplement, inte som något som står i vägen. Jag låter den hantera samma Cache-kontroll-Ta hänsyn till signalerna och kombinera strategier som stale-under-validering med HTTP-validering via ETag och Last-Modified. Vid offline-användning kan arbetaren tillfälligt leverera föråldrade resurser och omvalidera dem i bakgrunden. Det är viktigt att han vidarebefordrar villkorsheaders korrekt, annars går fördelarna med 304 förlorade på nätverkssträckan. På så sätt drar även PWA-scenarier nytta av korrekt HTTP-caching, istället för att kringgå dess mekanismer.
SEO-effekt och Core Web Vitals
Förbättra snabba svar UX och användarsignaler, vilket gynnar rankningen. Särskilt återkommande besökare gynnas, eftersom deras webbläsare hämtar många filer direkt från cachen eller via 304-svar. Denna lägre latens påverkar FCP, LCP och TTFB positivt, vilka jag minskar genom riktad omvalidering. Dessutom sparar servern beräkningstid, som jag kan använda för belastningstoppar eller resurskrävande förfrågningar. På så sätt bibehåller jag prestandan samtidigt som innehållet levereras korrekt och snabbt.
Sammanfattning: Min handlingsplan
Jag förlitar mig på en tydlig Kombination utifrån Cache-Control, Last-Modified och ETag. För statiska resurser väljer jag långa livslängder och säkerställer med omvalidering om filerna inte är versionerade. För dynamiska svar genererar jag tillförlitliga ETags och håller klusterna konsistenta. Därefter kontrollerar jag med verktyg, mätvärden och loggar om 304 förekommer tillräckligt ofta och justerar inställningarna. På så sätt säkerställer jag snabb leverans, lägre belastning och en bättre användarupplevelse genom effektiv HTTP-caching.
