HTTPcache bewaart verouderde contactinformatie

Wanneer een pagina wordt opgevraagd, kan het antwoord op meerdere plaatsen worden bewaard: in de browser van de bezoeker, in een tussenliggend netwerk zoals een CDN, en op de server zelf. Elk van die lagen mag een kopie hergebruiken zolang de regels uit de response dat toestaan. Het HTML-document is daarbij het eerste dat je site laadt, en hoe het gecachet wordt bepaalt mee hoe snel de rest verschijnt. De cursus Performance van web.dev behandelt HTML-caching expliciet als onderdeel van het laden van een pagina (cursus Performance van web.dev).

Voor contactinformatie is dit extra lastig. Je wilt dat een gewijzigd nummer snel overal klopt, terwijl cachen juist bedoeld is om kopieën te hergebruiken. Het gevolg is dat dezelfde pagina voor jou en voor een klant anders kan zijn, afhankelijk van welke laag welke kopie bewaart. Je eerste taak is dus niet 'de cache wissen' maar uitzoeken welke laag de oude versie nog uitdeelt.

Voor je iets verandert, wil je weten waar de oude versie vandaan komt. Werk dit in een vaste volgorde af en noteer bij elke stap wat je ziet.

1. Open de pagina in een privévenster of een andere browser zonder opgeslagen gegevens. Toont die nog het oude nummer, dan zit het niet alleen in jouw browser.
2. Open dezelfde pagina op een ander netwerk, bijvoorbeeld via mobiele data. Een verschil wijst op een laag die per locatie of netwerk anders reageert.
3. Bekijk de pagina met een URL die een extra, willekeurige parameter bevat. Toont die de nieuwe versie, dan is dat een aanwijzing dat de oorspronkelijke URL gecachet wordt, geen bewijs. Let op: sommige systemen negeren parameters, dus een gelijk resultaat bewijst niets.
4. Vraag een collega of klant op een ander toestel dezelfde pagina te openen en noteer wat die ziet.

Een gewone browsercontrole toont wat jouw browser krijgt, niet wat elk zoeksysteem of elke bezoeker krijgt. Gebruik het resultaat dus als aanwijzing en niet als eindconclusie.

De responseheaders vertellen welke cacheregels gelden. Open de netwerktab in de ontwikkelhulpmiddelen van je browser (de exacte schermnamen verschillen per browser en versie), selecteer het HTML-document en lees de headers. Vergelijk bij voorkeur twee metingen: één van een opvraging die de oude versie toont en één van een opvraging die de nieuwe toont.

Noteer minstens:

• Cache-Control: bepaalt of en hoe lang kopieën mogen worden hergebruikt.
• Age: toont, als aanwezig, hoe lang een tussenliggende cache de kopie al bewaart.
• ETag en Last-Modified: laten een cache controleren of de bron veranderd is.
• Vary: geeft aan op welke aanvraagkenmerken het antwoord kan verschillen.
• Extra headers van een CDN of host: sommige providers voegen een eigen header toe die toont of het antwoord uit de cache kwam. De naam verschilt per provider; zoek die op in de documentatie van je host of CDN.

MDN beschrijft in zijn overzicht over webprestaties hoe laden, latentie en opslag samenhangen (MDN over webprestaties). Gebruik dat als achtergrond, maar vertrouw voor de exacte betekenis van elke header op de documentatie van de tool of provider die je gebruikt.

Combineer wat je in stap 1 en 2 zag met onderstaande tabel. De acties zijn voorstellen voor je eigen controle. Welke knoppen je hebt, hangt af van je hostingpakket, CMS en CDN; controleer dat bij je webbouwer of provider.

Kies voor inhoud die na wijziging snel correct moet zijn een kortere cachelevensduur of een revalidatiepad, zodat caches bij elk gebruik controleren of er iets veranderd is. Pas dit selectief toe op pagina's met contactgegevens in plaats van op de hele site, want veel caching op afbeeldingen en stijlbladen blijft nuttig voor snelheid.

Dit scenario bevat enkel invoer en verwachte technische controles, geen verzonnen resultaten of termijnen.

Invoer: je hebt op de contactpagina het telefoonnummer gewijzigd en opgeslagen. Op jouw computer staat het nieuwe nummer. Een collega via mobiele data ziet het oude nummer. De ontwikkelhulpmiddelen tonen bij de HTML-response een Cache-Control met een lange levensduur en een Age-header met een hoge waarde.

Verwachte controles in volgorde:

1. Het verschil tussen netwerken en de hoge Age wijzen mogelijk op een tussenliggende cache in plaats van jouw browser. Bevestig dit door de headers van beide metingen te vergelijken en door de documentatie van je host of CDN te raadplegen.
2. Zoek in het CDN- of hostbeheer naar een optie om die pagina te vernieuwen of de cache te wissen, en voer dat uit.
3. Herhaal de meting op het toestel dat de oude versie toonde. Controleer of de headers nu een lage Age of een verse respons tonen en of het nieuwe nummer verschijnt.
4. Pas daarna de cacheregel voor deze pagina aan, zodat een volgende wijziging niet opnieuw lang blijft hangen, en test dat met een volgende kleine wijziging.

Weet je niet welke laag er in jouw opzet zit, stel dan de vraag aan je webbouwer of host: welke caches staan er tussen de server en de bezoeker, en hoe vernieuw ik er één voor één?

Een oplossing is pas afgerond als je haar hebt gecontroleerd op meerdere plaatsen. Doorloop deze controle:

• Open de pagina op minstens twee toestellen en twee netwerken en bevestig dat overal het nieuwe nummer staat.
• Vergelijk de responseheaders opnieuw en noteer de nieuwe cacheregels.
• Test het vernieuwingspad met een kleine, onschuldige wijziging en kijk hoe snel die zichtbaar wordt. Noteer wat je ziet; er is geen vaste termijn die voor elke opzet geldt.
• Controleer ook plekken buiten je site waar het oude nummer kan staan, zoals je bedrijfsvermelding in zoekmachines of op kaarten. Die worden door andere systemen bijgehouden, buiten je eigen cache.

Het verlagen van cachetijden kan de laadsnelheid beïnvloeden, dus weeg dit af per pagina. Vraag bij twijfel hulp aan de beheerder van je site; exacte instellingen en functies kunnen per provider en pakket wijzigen. Wil je bekijken welke publieke signalen je website zichtbaar geeft, dan kan dat via Marketing Scan. Die scan meet zichtbare signalen en bewijst geen volledige technische implementatie van je cachingopzet.