HTTP Voorwaardelijk Verzoeken verminderen de overdrachtskosten door ervoor te zorgen dat de client een bron alleen volledig laadt als deze daadwerkelijk is gewijzigd sinds het laatste verzoek. Ik zal laten zien hoe Cache-validatie met ETag, Last-Modified, If-None-Match, If-Modified-Since en 304 Not Modified werkt betrouwbaar en de laadtijden zijn merkbaar korter.
Centrale punten
- Validatie in plaats van een volledige download: 304 bespaart bandbreedte en tijd.
- ETag en Last-Modified werken samen voor een schone controle.
- Cachebeheer definieert versheid, verloopt alleen supplementen.
- Randvoorwaarden zoals If-Match beveiligde schrijfprocessen.
- Beveiliging vereist private/no-store voor gevoelige inhoud.
Wat voorwaardelijke verzoeken doen in het dagelijks leven
Ik stel Voorwaardelijk verzoeken om de server een duidelijke vraag te stellen: Moet ik echt nieuwe gegevens overbrengen of is mijn cache voldoende? De browser of een proxy stuurt voorwaarden, de server controleert of een bestand is gewijzigd en antwoordt met 304 Not Modified zonder body. Dit patroon houdt HTML, CSS, JavaScript, afbeeldingen en API-reacties up-to-date en vermindert de belasting van de infrastructuur aanzienlijk. Voor langere geldige assets gebruik ik lange max-age waarden en zorg ik ervoor dat ze up-to-date zijn door middel van validatie. Als u de juiste Cachebeheerstrategieën haalt het maximale uit caches zonder risico op verouderde inhoud.
Headers die cachevalidatie mogelijk maken
Voor betrouwbare Cache-De client heeft duidelijke signalen nodig van het antwoord om beslissingen te kunnen nemen. Ik gebruik Cache-Control voor versheid en regels, Expires af en toe als aanvulling, en Last-Modified en ETag voor de eigenlijke validatie. Last-Modified geeft een modificatietijd die snel kan worden gecontroleerd, terwijl ETag een versie-aanduiding geeft die ook wordt gebruikt voor dynamische inhoud. Het blijft belangrijk: no-cache betekent valideren voor gebruik, niet verwijderen. Als je deze semantiek correct toepast, zul je merkbaar minder gegevensverkeer krijgen terwijl de inhoud up-to-date blijft. Inhoud.
Volgorde van een voorwaardelijk verzoek zonder omwegen
Bij de eerste oproep slaat de client het bestand en de validatiewaarden op, zoals ETag of Last-Modified in de cache. Later verloopt de bron of is een nieuwe controle nodig voor gebruik en stuurt de client If-None-Match of If-Modified-Since. De server vergelijkt de informatie met de huidige status en stuurt ofwel 200 OK met een nieuwe body of 304 Not Modified zonder payload terug. De client blijft dan de bestaande kopie gebruiken en bespaart transmissie, TLS-werklast en tijd. Dit pingpongen lijkt onopvallend, maar de Effect op het gevoel van belasting en serverbelasting is duidelijk.
ETag vs. Last-Modified in directe vergelijking
Ik gebruik Laatst gewijzigd Ik gebruik graag timestamps als een snelle, eenvoudige referentie, maar gebruik ETags voor een fijnmazige controle. Tijdstempels kunnen hun grenzen bereiken met zeer korte wijzigingsintervallen of dynamische uitvoer vervalsen. Ik maak ETags aan van bestandshashes, databaseversies of rendervarianten, waarbij elke verandering in de inhoud een nieuwe identifier genereert. Beide mechanismen kunnen worden gecombineerd: De client kan If-None-Match en If-Modified-Since parallel verzenden en de server selecteert de juiste controle. Hoe zorg je voor een betrouwbare Validatie, die evenzeer van toepassing is op statische als op dynamische bronnen.
| Criterium | Laatst gewijzigd | ETag |
|---|---|---|
| Nauwkeurigheid | Tweede resolutie, geschikt voor bestanden | Versie-aanduiding voor elke inhoudswijziging |
| Dynamiek | Zwak met frequente, niet op bestanden gebaseerde wijzigingen | Sterk voor API's en gerenderde inhoud |
| Uitgaven | Laag, beschikbaar via het bestandssysteem | Laag tot matig, generatie in app/proxy |
| Conflicten | Klokafwijkingen mogelijk | Mogelijk onjuist geconfigureerde zwakke/sterke tags |
Juiste instellingen voor browser caching en API's
Voor statische activa gebruik ik lange maximumleeftijd en opslaan via ETag of bestandsnaam hash zodat updates onmiddellijk worden herkend. Ik markeer HTML- en API-responses vaak met no-cache zodat de client ze voor gebruik kan valideren zonder alles elke keer opnieuw te hoeven laden. Ik markeer gepersonaliseerde pagina's met private zodat gedeelde caches niets uitvoeren dat is bewaard voor anderen. Fouten worden vaak veroorzaakt door tegenstrijdige richtlijnen of ontbrekende validatieheaders, die ik voorkom met duidelijke regels. Als je de typische struikelblokken kent, kun je ze gemakkelijk vermijden; goede voorbeelden hiervan vind je in het artikel over Header-traps in caching, waar ik me graag op oriënteer.
Statuscodes en voorwaarden effectief gebruiken
Ik organiseer Statuscodes duidelijk: 200 OK levert inhoud, 304 Not Modified bevestigt cachegebruik en 412 Precondition Failed annuleert als niet aan een voorwaarde wordt voldaan. Voor beveiligde schrijfoperaties gebruik ik If-Match zodat updates alleen worden uitgevoerd als de ETag overeenkomt met de verwachte versie. Lezen met If-None-Match of If-Modified-Since voorkomt overbodige payloads en houdt clients gesynchroniseerd. Consistent gedrag is belangrijk: Hetzelfde endpoint moet identiek reageren voor identieke precondities. Voor SEO en bots let ik op hoe caches en crawlers statusberichten interpreteren; een goed overzicht van HTTP-statuscodes en crawling helpt bij het nemen van schone beslissingen.
Beveiliging en gegevensbescherming voor caching
Ik behandel gevoelige inhoud met geen opslag en ze dus geen kans geven om in de browser of proxy cache terecht te komen. Ik markeer gepersonaliseerde pagina's met Cache-Control: private en controleer of er geen persoonlijke gegevens in langlopende URL's in de cache staan. Ik ontwerp ETags neutraal, zonder conclusies te trekken over gebruikersaccounts of interne ID's. Ik schakel consequent alle caching uit voor inlogweergaven en bankflows. Als je gegevensminimalisatie, geschikte richtlijnen en schone headers combineert, verlaag je het risico en bescherm je je gegevens. Vertrouwelijkheid.
Implementatie: Stappen voor server en applicatie
In het begin scheid ik statisch van dynamische bronnen en beslis waar lange deadlines zinvol zijn en waar validatie prioriteit heeft. In Nginx, Apache of een app-server configureer ik cache control en activeer ik last-modified en ETags, waarbij ik het genereren van ETags in de applicatie plaats voor dynamische eindpunten. Bij het verwerken van inkomende verzoeken evalueer ik If-None-Match en If-Modified-Since en reageer ik met 304 als de voorwaarde overeenkomt. Voor schrijfoperaties gebruik ik If-Match en retourneer 412 bij afwijkingen om overschrijven te voorkomen. Dit creëert een consistent gedrag dat efficiënt gebruik maakt van caches en tegelijkertijd Correctheid verzekert.
Gebruik meetgegevens, tests en monitoring op een verstandige manier
Ik controleer de Netwerk-tab van de DevTools om te controleren of bronnen uit de cache komen, gevalideerd worden of vers geladen zijn. Ik controleer status, leeftijdswaarden, ETags en de grootte van het overgedragen antwoord. Onder belasting meet ik latency, overdrachtsvolume en CPU van de server om het werkelijke effect van 304 reacties te zien. Logboeken van de reverse proxy laten zien of gedeelde caches hun werk doen en hoeveel validaties succesvol zijn. Ik gebruik deze gegevens om de max-age, cache control directives en ETag-strategieën aan te passen totdat de responstijden en Raakpercentage stemming.
Hostingprestaties: waarom voorwaardelijke verzoeken geld besparen
Elke 304-De gedeelde cache-respons bespaart bandbreedte, vermindert de TLS-overhead en verkort de responstijd, wat vooral belangrijk is voor veel gelijksoortige verzoeken. In hostingopstellingen met reverse proxies, loadbalancers en CDN's bereik ik het grootste effect als ik gedeelde caches duidelijk toesta of specifiek uitsluit. Minder overdracht betekent vaak ook lagere verkeerskosten in euro's en meer reserves voor echte belastingspieken. De gebruikerservaring wordt ook verbeterd doordat herhaalde paginaweergaven en API-polls sneller reageren. Op deze manier realiseer ik prestatiepotentieel dat pure hardware-upgrades alleen niet kunnen leveren en maak ik gebruik van bestaande Infrastructuur beter.
Veelgemaakte fouten en pragmatische oplossingen
Tegenstrijdige Kop zoals no-cache gekoppeld aan expires ver in de toekomst verwarren caches; ik stel duidelijke regels op zonder duplicatie. Ontbrekende ETags voor dynamische eindpunten leiden tot onnodige volledige downloads; ik voeg een betrouwbare identifier toe en evalueer if-none-match. Te korte max-age waarden verspillen potentieel met zelden veranderde bestanden; ik rek deadlines op en beveilig ze toch met validatie. Agressieve caching van HTML vertraagt zichtbare veranderingen; ik combineer no-cache met ETag en houd inhoud actueel. Met duidelijke beslissingen over versheid, validatie en geldigheid, los ik deze struikelblokken op en versterk ik de Planbaarheid.
Gebruik Vary netjes en controleer representaties
Om ervoor te zorgen dat voorwaardelijke verzoeken veilig werken in gedeelde caches, zorg ik ervoor dat ik de juiste Variëren. De header definieert welke request headers de weergave beïnvloeden. Typische voorbeelden zijn Accept-Encoding (gzip, br), Accept-Language en Accepteer. Als ik inhoud per taal lever, stel ik Vary: Accept-Language in zodat een proxy niet de Duitse versie deelt in antwoord op een Frans verzoek. Voor gepersonaliseerde inhoud doe ik het bewust zonder Vary: Cookie en gebruik ik in plaats daarvan Cachebeheer: privé, om een oncontroleerbare explosie van cachesleutels te voorkomen. Voor bronnen die alleen worden geleverd met geldige autorisatie, gebruik ik private of zorg ik voor een duidelijke scheiding met Vary: Authorisation of Vary op relevante headers. Consistentie is belangrijk: de geselecteerde set Vary-dimensies moet stabiel blijven, anders zullen de cache-hitrate en validatievoordelen instorten omdat er voortdurend nieuwe varianten worden gemaakt.
Sterke vs. zwakke ETags, compressie en bytegelijkheid
Sterke ETags karakteriseren per byte identieke weergaven en maken nauwkeurige validatie mogelijk, ook in combinatie met bereikaanvragen. Zwakke ETags (W/...) geven alleen inhoudelijke gelijkheid aan, niet noodzakelijk identieke bytes. In de praktijk gebruik ik sterke ETags als ik een unieke identifier kan genereren voor elke weergave (inclusief compressie). Zodra een reverse proxy on-the-fly gzip of brotli gebruikt, pas ik de ETag generatie aan of schakel over op zwakke ETags zodat de server en client niet ten onrechte verschillende bytes als identiek herkennen. Een robuuste variant is om de ETag te maken van de laatste bytes van het geleverde antwoord en tegelijkertijd gebruik te maken van Vary: Accept-Encoding worden ingesteld. Dit zorgt ervoor dat „gzip“ en „br“ elk hun eigen geldige ETags krijgen. Waar ik geen byte gelijkheid kan garanderen (bijv. verschillende timestamps in HTML), kies ik zwakke ETags die nog steeds betrouwbare 304 reacties toestaan zolang de betekenis van de pagina niet veranderd is.
Cachebeheer in fijnafstemming: s-maxage, must-revalidate, stale-while-revalidate
Naast maximumleeftijd Ik gebruik specifiek fijnere richtlijnen. s-maximum richt zich uitsluitend tot Gedeelde caches (CDN's, proxies) en stelt me in staat om daar agressiever te cachen dan in de browser. moet opnieuw worden gevalideerd dwingt klanten om verlopen inhoud niet heuristisch te gebruiken, maar altijd te valideren - handig voor kritieke gegevens. proxy-hervalideren adresseert deze verplichting specifiek voor gedeelde caches. Met stale-while-revalidate Ik sta toe dat een iets verouderde kopie kort wordt afgeleverd terwijl validatie op de achtergrond draait; gebruikers zien direct iets en de volgende aanvraag profiteert van verse metadata. stale-if-error als vangnet: Als de Origin faalt of fouten retourneert, mag de cache de laatst bekende kopie leveren voor een bepaalde tijd. Voor build-hashed assets combineer ik lange max-age met onveranderlijk, omdat de bestandsnaam samen met de inhoud verandert en tussentijdse validaties onnodig zijn. Voor HTML en API's blijft no-cache plus validator de gouden standaard om up-to-date te blijven en toch bandbreedte te besparen.
Verdere voorwaarden en methoden: HEAD, bereik en schrijfconflicten
Voorwaardelijke verzoeken zijn niet beperkt tot GET. A HEAD-request geeft alleen headers en is ideaal voor snelle validaties zonder body. Voor grote bestanden gebruik ik Bereik-verzoeken; met Als-bereik Ik zorg ervoor dat deelgebieden alleen worden verzonden als de bron nog steeds overeenkomt met de verwachte versie - anders antwoord ik met 200 en een volledige body. Voor schrijfbewerkingen zorg ik voor consistentie met Als-match ab: PUT, PATCH of DELETE werken alleen als de ETag van de client overeenkomt met de huidige versie; anders reageer ik met 412 Precondition Failed. Waar ik precondities wil afdwingen, bijvoorbeeld bij conflictgevoelige bronnen, gebruik ik 428 Precondition Required om clients If-Match te laten gebruiken. Ik kies bewust tussen 409 Conflict en 412: 412 signaleert geschonden randvoorwaarden, 409 benadrukt inhoudelijke conflicten (bijv. regels voor bedrijfslogica). Deze duidelijkheid vergemakkelijkt implementaties door clients en voorkomt blinde opheffingen.
Personalisatie, cookies en gegevensbescherming in de praktijk
Voor gepersonaliseerde pagina's markeer ik antwoorden met privé of geen opslag. Ik vermijd het coderen van gebruikerstoestanden in e-tags omdat zulke „per-gebruiker“ e-tags ongewild tracking markers kunnen worden. In plaats daarvan maak ik een strikt onderscheid tussen openbare en privéweergaven. Ik zet alleen cookies in de cache key (Vary: Cookie) als dat absoluut noodzakelijk is, omdat ze het aantal varianten verhogen en de hit rate drastisch verlagen. Voor geautoriseerde API-reacties houd ik me aan Cachebeheer: privé en, indien nodig, op Vary op de Authorisation header format. Zo zorg ik ervoor dat gedeelde caches niet per ongeluk vertrouwelijke antwoorden delen. In toepassingen met gemengde inhoud (openbaar basisraamwerk, gepersonaliseerde deelgebieden) vertrouw ik op gefragmenteerde caching of ESI/SSI aan de rand, terwijl kritieke delen privé blijven. Het resultaat is gegevensbescherming zonder prestatieverlies.
Werking: CDN's, surrogaten en invalidaties
In CDN-opstellingen combineer ik s-maximum met duidelijke validators en - indien beschikbaar - gebruik surrogaat-specifieke richtlijnen om edge caches apart van de browser te beheren. Revalidatie vermindert de belasting op Origin, maar af en toe is een harde invalidatie nodig (bijv. voor een beveiligingsfix). Ik plan dan twee manieren: Cache breken via bestandsnaam-hashes voor statische activa en Zuiveren/Invalidatie voor HTML en API's. Dit voorkomt „purge storms“ en zorgt toch voor een korte time-to-freshness. Het is ook belangrijk om een consistente cache key te hebben in het CDN (inclusief host, pad, query parameters en relevante Vary headers). Voor query parameters maak ik bewust onderscheid tussen semantische (bijv. ?lang=) en puur tracking-gerelateerde parameters; deze laatste negeer ik in de cache key om fragmentatie te voorkomen. Dit houdt de keten van browser cache, tussenliggende proxy en CDN transparant en voorspelbaar.
304 in detail: Update header en metadata correct
Ook een 304-Het antwoord bevat belangrijke metadata. Ik lever Datum, Cache-Control, ETag/Last-Modified en - indien relevant - Expires en Vary opnieuw zodat de client zijn cache-items kan bijwerken. Content-Type en Content-Encoding hoeven niet per se herhaald te worden, maar kunnen bijdragen aan de duidelijkheid. Het is belangrijk dat 304 geen body payload bevat en dat ik consistente validators stuur: Het veranderen van de ETag in de 304 zonder de representatie te veranderen leidt tot verwarring. Als de richtlijnen worden aangepast (bijv. langere max-age), kan de client de metadata overnemen zonder de body opnieuw te hoeven laden - een kleine hefboom met een grote impact op de waargenomen prestaties.
Test- en debug-strategieën voor schone validatie
Ik controleer specifiek de volgende punten in DevTools: van schijfcache vs. van geheugencache vs. gerevalideerd; Status 200/304; Age header in antwoorden van gedeelde caches; ETag/Last-Modified consistentie en het effect van Vary. Voor reproduceerbare tests deactiveer ik tijdelijk de browsercache of gebruik ik een privémodus. Aan de serverkant evalueer ik logs op de 200/304 ratio, de gemiddelde responsgrootte en CPU-gebruik. Waarschuwingssignalen zijn bijvoorbeeld veel 200 reacties op bronnen met korte wijzigingsintervallen (ontbrekende validators), revalidatielussen (afwijkende tijden/klokdrift) of een ongebruikelijk groot aantal varianten per URL (overmatige Vary). Ik gebruik belastingstests om te controleren hoe s-maxage, stale-while-revalidate en if-none-match zich onder druk gedragen - en pas richtlijnen aan totdat doorvoer en latency overeenkomen.
Randgevallen en robuuste standaardinstellingen
Niet elke bron heeft duidelijke wijzigingsregels. Ik stel voorzichtige standaardwaarden in voor gegenereerde sitemaps, feeds of dashboards: no-cache plus ETag/Last-Modified. Met onstabiele klokken tussen upstream systemen vermijd ik rigide secondevergelijkingen en geef ik de voorkeur aan ETags die onafhankelijk zijn van tijdstempels. Als de compressie variabel is (verschillende gzip niveaus), neem ik het resultaat van de compressie mee in de ETag generatie of schakel ik over op zwakke ETags. En als clients aanvragen zonder validators, stuur ik duidelijke signalen: Ofwel duidelijke versheid (max-age/immutable) of duidelijke validatie (no-cache + ETag). Deze robuuste standaardinstellingen ervoor zorgen dat zelfs onvolledige of defecte clients geen ongewenste belastingspieken veroorzaken.
Korte samenvatting
Voorwaardelijke verzoeken verbinden Snelheid en tijdigheid door clients alleen volledige bronnen op te laten halen als de inhoud is gewijzigd. Ik gebruik cachecontrole voor versheid, combineer last-modified en ETag voor betrouwbare controles en reageer consequent met 304 als aan de voorwaarden wordt voldaan. Ik isoleer gepersonaliseerde en vertrouwelijke inhoud met private of no-store zodat er geen gegevens in gedeelde caches terechtkomen. Metingen in DevTools, logs en metrics laten me zien waar ik deadlines kan oprekken of validatielogica kan aanscherpen. Als je over deze bouwstenen nadenkt, zul je snellere pagina's, minder serverbelasting en een ronder Gebruikerservaring zonder gegevens te verspillen.
