Stel dat een bibliotheek de openingstijden op haar website heeft aangepast, maar sommige bezoekers nog de oude tijden zien. Eerst moet u onderscheiden of de bron op de server niet is bijgewerkt, de browser een opgeslagen antwoord hergebruikt of een tussenliggende server een eerdere versie levert. Dat u de pagina verschillende keren hebt vernieuwd, vertelt op zichzelf niet welke stap de oorzaak is.
Een HTTP-cache bewaart ontvangen antwoorden en gebruikt ze opnieuw wanneer de voorwaarden dat toelaten. Dit artikel verbindt de opslag- en hervalidatie-instructies van Cache-Control met ETag en 304 aan de hand van fictieve openbare openingstijden. De uitwisselingen hieronder zijn verkorte uitlegvoorbeelden, geen metingen aan een echte bibliotheek of specifieke server. Het doel is uit te leggen welk antwoord wanneer opnieuw bruikbaar moet zijn, in plaats van alles te behandelen door caches geheel uit te schakelen.
1. Opslaan, controleren vóór hergebruik en delen zijn verschillende vragen
Schrijf bij een cachebeleid drie vragen afzonderlijk op: mag het antwoord worden opgeslagen, mag een volgende aanvraag meteen de opgeslagen versie gebruiken en mag die met meerdere gebruikers worden gedeeld? Opslagtoestemming betekent niet onbeperkt hergebruik; een controle op actualiteit geeft evenmin toestemming om met anderen te delen. De HTTP-cachestandaard RFC 9111 definieert hiervoor afzonderlijke instructies. Hieronder bespreken we antwoordinstructies zonder een argument met veldnamen.
| Te beoordelen vraag | Relevante antwoordinstructie | Betekenis om te onderscheiden |
|---|---|---|
| Mag dit antwoord niet worden opgeslagen? | no-store | Verbiedt opslag voor later hergebruik |
| Moet vóór hergebruik worden gecontroleerd? | no-cache | Opslag kan, maar hergebruik vereist geslaagde validatie |
| Mag het tussen gebruikers worden gedeeld? | private | Sluit opslag in een gedeelde cache uit, maar verbiedt opslag in een privécache niet |
Als openbare openingstijden vaak op hetzelfde adres veranderen, kunt u bijvoorbeeld overwegen te eisen dat ook een opgeslagen versie vóór gebruik wordt gecontroleerd. Persoonlijke pagina’s verschillen al in hun voorwaarden voor delen van openbare openingstijden. private is een instructie voor gedeelde caches en vervangt aanmelden of een toegangscontrole niet. Als instellingen met verschillende doelen op één hoop worden gegooid, kan een snelheidsverbetering het publiek voor bepaalde informatie verkeerd afbakenen.
Leg in het beleidsoverzicht behalve de instructie ook de reden vast. Noteer bijvoorbeeld of de openingstijden openbare informatie zijn waarvan wijzigingen moeten worden gecontroleerd, of een logo een bestand met vaste inhoud is en of op hetzelfde adres persoonlijke informatie staat. Dit overzicht is geen kant-en-klare configuratie voor iedere website, maar een vertrekpunt om echte antwoorden in te delen. Onderscheid ook op welke opslag, zoals een browser of CDN, het beleid betrekking heeft.
2. Kies no-cache en no-store niet op hun naam alleen
no-cache klinkt als een opslagverbod, maar in een antwoord betekent het dat de opgeslagen versie vóór hergebruik moet worden gevalideerd. Bevestigt de server dat er niets is veranderd, dan kan de opgeslagen inhoud opnieuw bruikbaar zijn. no-store instrueert daarentegen om dit antwoord niet op te slaan. Omdat opslag en de controle bij de volgende aanvraag verschillende zaken zijn, moet u niet hetzelfde gedrag van beide instellingen verwachten.
Bij caches betekent fresh dat het beleid hergebruik zonder aanvullende validatie toestaat. Het garandeert niet dat een beheerder de inhoud ondertussen niet heeft gewijzigd. Als max-age een periode voor hergebruik vastlegt, kan het opgeslagen antwoord binnen die periode gekozen blijven worden, ook nadat de bron is aangepast. Bepaal eerst welke vertraging bij actualisering aanvaardbaar is en verbind die eis aan de instructies. Kopieer geen willekeurig lange bewaartermijn als universeel recept voor betere prestaties.
De uitleg over HTTP-caching van MDN vermeldt dat no-store op een nieuw antwoord eerdere antwoorden voor dezelfde URL niet verwijdert. Als een oude opgeslagen versie nog bruikbaar is en geen nieuw antwoord wordt opgehaald, komt ook de nieuwe header mogelijk niet aan. Beschouw no-store dus niet als het wissen van iedere cache of als voldoende privacybescherming. Controleer ook de levensduur van bestaande antwoorden en de actualiseringsprocedure van caches die u beheert.
3. Volg één herbezoek met ETag en 304
Neem de fictieve URL /hours.json, die aanvankelijk een sluitingstijd van 18.00 uur meldt. Hieronder staat een vereenvoudigd HTTP/1.1-voorbeeld met alleen de relevante onderdelen. Andere headers die een werkelijk antwoord nodig kan hebben, zijn weggelaten. hours-v1 is hier een door de server gekozen identificatie van de representatie, geen formule om tijd te berekenen of een echte bestandshash.
HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-cache
ETag: "hours-v1"
{"closes":"18:00"}Als de browser dit antwoord heeft opgeslagen, kan hij de ETag bij een volgende voorwaardelijke aanvraag in If-None-Match meesturen. Komt de voorwaarde overeen met de huidige gekozen representatie en concludeert de server dat deze niet veranderd is, dan antwoordt hij met 304 Not Modified. Het volgende blok toont verkort de aanvraag en het bijbehorende antwoord achter elkaar. Het is geen voorbeeld waarin na 304 opnieuw JSON met de openingstijden wordt verzonden.
GET /hours.json HTTP/1.1
Host: library.example
If-None-Match: "hours-v1"
HTTP/1.1 304 Not Modified
Cache-Control: no-cache
ETag: "hours-v1"Zoals de ETag-uitleg van MDN beschrijft, gebruikt de client dan de opgeslagen inhoud. Een 304 bevat geen nieuwe antwoordinhoud, maar de aanvraag en validatie brengen wel communicatie met zich mee. Als de beheerder de sluitingstijd naar 19.00 uur heeft veranderd en ook de serverrepresentatie is gewijzigd, kunt u op de oude voorwaarde een 200-antwoord met nieuwe inhoud en een nieuwe identificatie verwachten. no-cache betekent niet dat ieder antwoord 304 is of dat een database nooit meer wordt geraadpleegd.
Controleer vooral de relatie tussen inhoud en identificatie, niet alleen de statuscode. Als de inhoud wijzigt maar de server de oude ETag blijft gebruiken, kan de validatie onjuist uitvallen. Als de inhoud gelijk blijft maar de identificatie steeds verandert, moet de inhoud mogelijk vaker opnieuw worden verzonden. Onderzoek op de server hoe de identificatie wordt gemaakt en bij de gekozen representatie past. Alleen de aanwezigheid van een ETag bewijst niet dat de implementatie correct is.
4. Onderscheid veranderlijke documenten van bestanden met een nieuwe naam
Een document dat op dezelfde URL verandert, zoals de openingstijden, kan een andere actualiseringsstrategie vragen dan een logo of script dat bij een inhoudswijziging een nieuwe bestandsnaam krijgt. Verandert een logo bijvoorbeeld van logo.a1.png in logo.b2.png, dan moet het nieuwe document naar het nieuwe adres verwijzen. Een inhoudsidentificatie in de naam zetten en toch de inhoud onder de oude naam overschrijven, doorbreekt de afspraak om inhoud en adres samen te beheren.
Een nieuw bestand uploaden zorgt op zichzelf niet dat bezoekers het nieuwe adres aanvragen. Als hun HTML nog naar het oude logo verwijst, kunnen ze het oude bestand blijven hergebruiken. Bekijk daarom niet alleen het cachebeleid van het bestand, maar ook hoe het verwijzende document wordt bijgewerkt. In plaats van beide dezelfde bewaartermijn te geven, moet u per onderdeel kunnen uitleggen hoeveel vertraging bij wijziging aanvaardbaar is.
Tijdens een uitrol kunnen oude en nieuwe documenten tijdelijk naast elkaar in gebruik zijn. Een nieuw document publiceren voordat de bijbehorende bestanden klaarstaan, of oude bestanden te vroeg verwijderen, kan afzonderlijke fouten veroorzaken. In dit fictieve geval kunt u controleren of bestanden waarnaar het nieuwe document verwijst bestaan en of bestanden uit bestaande documenten bereikbaar blijven. Bestandsnamen veranderen is een hulpmiddel voor cacheontwerp; het lost niet automatisch iedere uitrolvolgorde of terugdraaioperatie op.
5. Onderzoek één hypothese tegelijk in het Network-paneel
Leg eerst een uitgangsmeting vast terwijl caching is toegestaan. Bekijk samen de exacte URL met query, de versie van de getoonde openingstijden, de antwoordstatus, If-None-Match van de aanvraag en Cache-Control en ETag van het antwoord. Ook gelijknamige aanvraag- en antwoordheaders beschrijven voorwaarden van verschillende partijen: noteer welke kant u leest. De Chrome DevTools Network-documentatie laat zien hoe u deze onderdelen in Headers uit elkaar houdt.
| Fictieve testsituatie | Samen te bekijken gegevens | Voorbarige conclusie om te vermijden |
|---|---|---|
| Dezelfde openingstijden opnieuw aanvragen | Voorwaardelijke aanvraag, status en getoonde tijd | Bij 304 was er helemaal geen communicatie |
| Aanvragen na wijziging van de bron | Nieuwe inhoud, ETag en werkelijk aangevraagde URL | Een opslagbevestiging betekent dat iedereen de wijziging ziet |
| Aanvragen met browsercache uitgeschakeld | Verschil tussen eerste download en gewoon herbezoek | Dit resultaat is gelijk aan de normale herbezoeksnelheid |
| Terugkeren met de terugknop | Of er een nieuwe aanvraag plaatsvond en welke pagina is hersteld | Een zichtbare pagina betekent dat er nieuwe HTTP-validatie was |
Test het uitschakelen van de browsercache vervolgens als een afzonderlijke conditie. In Chrome DevTools geldt Disable cache terwijl DevTools geopend blijft; noteer dus ook of het paneel openstond. Dit is nuttig voor het onderzoeken van een eerste download, maar verschilt van een test van hergebruik bij gewone herbezoeken. Zonder die instelling vast te leggen kunt u uit telkens nieuwe downloads ten onrechte afleiden dat caching niet werkt. Bewaar de testcondities zodat u opnieuw met toegestane caching kunt vergelijken.
Verander tijdens het observeren niet alles tegelijk en voer niet allerlei aanvragen door elkaar uit. Begin met een herbezoek zonder inhoudswijziging en pas daarna één tijd aan om het andere antwoord te bekijken. Als document-URL, serverinstellingen en bestandsnamen tegelijk veranderen, is moeilijk vast te stellen welke verandering het resultaat veroorzaakte. Verschijnt de verwachte 200 of 304 niet, lees dan eerst de echte aanvraag en het antwoord opnieuw voordat u meer instellingen toevoegt.
6. Controleer andere opslagroutes en duidelijke voltooiingscriteria
Ga er niet van uit dat het uitschakelen van de HTTP-cache van de browser ook een CDN vóór de server of andere opslagroutes van de toepassing opheft. Onderzoek afzonderlijk of een serviceworker de aanvraag afhandelt, welk antwoord een tussenserver kiest en of de toepassing eerder ontvangen gegevens op het scherm vasthoudt. Dezelfde zichtbare URL betekent niet dat iedere laag dezelfde kopie gebruikt.
Bekijk terugnavigeren eveneens los van een nieuwe HTTP-aanvraag. Wanneer de browser een pagina uit een eerdere sessie herstelt, kan ook met no-cache de verwachte hervalidatie ontbreken. Dat is niet meteen bewijs dat de server de header negeert. Noteer afzonderlijk of er bij nieuwe navigatie, vernieuwen en teruggaan werkelijk een aanvraag ontstond; zo behandelt u verschillende verschijnselen niet als één probleem.
Het voltooiingscriterium voor de openingstijden is meer dan alleen een cachetrefferpercentage. Controleer of de opgeslagen versie correct wordt gebruikt als niets verandert, of nieuwe informatie binnen de toegestane tijd zichtbaar wordt na een wijziging en of het antwoord met het juiste publiek wordt gedeeld. Met wijzigings- en observatietijd, condities en daadwerkelijke inhoud kan iemand anders de situatie beter reproduceren. Betere snelheid met langdurig onjuiste openingstijden voldoet niet aan de oorspronkelijke eis.
Bekijk voor productie per antwoordsoort het beleid, de actualisering en de procedure om wijzigingen terug te draaien. Kopieer cache-instructies voor openbare documenten niet zomaar naar persoonlijke antwoorden en beschouw geslaagde validatie niet als een afgeronde toegangscontrole. Headers geven regels voor opslag en hergebruik door. U kunt verouderde pagina’s beter onderzoeken als u kunt uitleggen wat is opgeslagen en via welke controles het huidige scherm tot stand kwam.