No-Vary-Search: slimmer cachen met query parameters
Query parameters zoals utm_source of ?page=3 saboteren stiekem je cache. Elke variant wordt als aparte URL opgeslagen, met lagere hit rates en meer origin-verkeer als gevolg. De nieuwe No-Vary-Search header belooft hier eindelijk grip op te geven. Maar werkt het al écht en waar liggen de valkuilen?
Het probleem dat je waarschijnlijk niet zag
Moderne websites zitten vol query parameters: tracking, filters, paginering, sortering. Handig, maar caches behandelen elke variant als een compleet andere URL. Dus /products en /products?utm_source=twitter zijn technisch identiek, maar krijgen twee aparte cache-entries. Het resultaat: lagere cache hit rates, meer verkeer naar je origin server en dus hogere infrastructuurkosten.
Wat No-Vary-Search doet
Deze nieuwe HTTP-header laat je expliciet vertellen welke parameters wél of niet meetellen voor caching. Je kunt tracking-parameters negeren, parametervolgorde irrelevant maken, of juist álles negeren behalve een handvol belangrijke parameters. Eindelijk een gestandaardiseerd alternatief voor de rommelige, vendor-specifieke workarounds die veel teams nu bij de CDN handmatig in elkaar knutselen.
De pragmatische kanttekening
Mooi verhaal, maar let op: de feature is nog experimenteel. Er bestaan zelfs twee syntaxvarianten (params en params=()) omdat de spec nog beweegt. En het grootste gevaar zit in verkeerd gebruik: negeer je per ongeluk een parameter die de content wél verandert — denk aan sessies, personalisatie of localisatie — dan serveer je zomaar de verkeerde pagina aan de verkeerde gebruiker. Cachebugs zijn notoir lastig te debuggen.
DebugBear legt de werking, de geavanceerde edge cases en de valkuilen helder uit met concrete voorbeelden. Wil je je cache-strategie eindelijk opschonen zonder brokken te maken? Lees het volledige artikel.
Bron: https://www.debugbear.com/blog/no-vary-search?mc_cid=1898941f8d