PerformanceCaching

No-Vary-Search: der erste HTTP-Header, der explizit Datenverschwendung reduziert

Von ·

Wenn jemand über einen Google-Ads-Link auf datensm.art landet, hängt Google automatisch einen gclid-Parameter an die URL:

https://datensm.art/?gclid=EAIaIQobChMI...

Wenn jemand über einen Newsletter-Link kommt, sieht die URL so aus:

https://datensm.art/?mtm_source=newsletter&mtm_medium=email

Für den Browser sind das zwei völlig verschiedene Seiten. Er speichert beide separat im Cache – obwohl das HTML byte-für-byte identisch ist. Derselbe Inhalt, mehrfach gecacht, mehrfach übertragen, wenn der Cache gefüllt ist.

Genau das löst No-Vary-Search.

Was der Header macht

No-Vary-Search ist ein HTTP-Response-Header, der dem Browser mitteilt: Diese Query-Parameter verändern den Seiteninhalt nicht – ignoriere sie beim Cache-Key. URLs, die inhaltlich identisch sind, scheitern oft daran, denselben gecachten Response wiederzuverwenden, weil sich ihre Query-Strings unterscheiden. No-Vary-Search lässt den Server via Header mitteilen: „Diese Parameter fragmentieren den Cache nicht sinnvoll."

Das Ergebnis: Alle Varianten einer URL mit reinen Tracking-Parametern landen auf demselben Cache-Eintrag. Der Browser lädt die Seite einmal, der Rest wird aus dem Cache bedient.

Das spart RAM, Disk-Cache, Netzwerkanfragen, CPU – und bei Mobilfunkzugriffen auch Datenvolumen.

Konkrete Umsetzung für Hugo mit Matomo

Das folgende Beispiel gilt für eine Hugo-Website mit Matomo als Analyse-Tool. Matomo und Google Analytics werden nicht gleichzeitig eingesetzt – wer GA nutzt, findet weiter unten einen Hinweis.

Matomo-Kampagnen-Parameter (mtm_*) – Matomo setzt ausschließlich diese Parameter in eigenen Links:

In der .htaccess im Webroot – Matomo-Version:

<IfModule mod_headers.c>
  Header set No-Vary-Search "params=(\"mtm_campaign\" \"mtm_kwd\" \"mtm_source\" \"mtm_medium\" \"mtm_content\" \"mtm_cid\" \"mtm_group\" \"mtm_placement\" \"utm_source\" \"utm_medium\" \"utm_campaign\" \"utm_content\" \"utm_term\")"
</IfModule>
Info
Obwohl Matomo selbst keine utm_*-Parameter setzt, sollten sie dennoch in der Liste stehen: Externe Quellen wie LinkedIn, ChatGPT oder Google Ads hängen automatisch UTM-Parameter an Links – etwa utm_source=linkedin oder utm_source=chatgpt. Matomo erkennt und wertet diese Parameter automatisch aus. Ohne utm_* in der Liste würden diese Seiten-Varianten als separate Cache-Einträge behandelt, obwohl der Inhalt identisch ist.

Für Google-Analytics-Nutzer entfallen die mtm_*-Parameter:

<IfModule mod_headers.c>
  Header set No-Vary-Search "params=(\"utm_source\" \"utm_medium\" \"utm_campaign\" \"utm_content\" \"utm_term\")"
</IfModule>

Wer bezahlte Werbung schaltet, ergänzt gclid (Google Ads) bzw. fbclid (Meta) im jeweiligen Block.

Ein Hinweis zur Syntax: Wildcards wie utm_* unterstützt No-Vary-Search nicht – Parameter müssen einzeln aufgelistet werden. Die einzige Alternative wäre params ohne Liste, was jedoch alle Query-Parameter ignoriert und für die meisten Websites zu pauschal ist.

Tipp
Die obige Implementierung ist ein Beispiel für eine typische Hugo-Website mit Matomo. Welche Parameter für deine Website sinnvoll sind, hängt davon ab, welche Analyse- und Kampagnen-Tools du einsetzt. Wenn du unsicher bist, welche Parameter bei dir anfallen – ich helfe gerne dabei, das für deine konkrete Situation einzurichten.

Testen mit curl:

curl -I "https://deine-domain.de/?mtm_source=test"
curl -I "https://deine-domain.de/podcast/?utm_source=linkedin"

In der Ausgabe sollte erscheinen:

No-Vary-Search: params=("mtm_campaign" "mtm_source" ...)

Wichtige Einschränkung: Matomo _pk_*-Parameter

Matomos eigene Session-Parameter _pk_id und _pk_ses sollten nicht in die No-Vary-Search-Liste. Sie transportieren Besucherzustände und sind keine reinen Kampagnenparameter. Die mtm_*-Parameter sind dagegen unkritisch – sie dienen ausschließlich der Kampagnenzuordnung und verändern den Seiteninhalt nicht.

Achtung
No-Vary-Search nur für Parameter einsetzen, bei denen sicher ist, dass sie den Seiteninhalt nicht verändern. Parameter, die Produktvarianten, Sprachauswahl oder Benutzerzustände steuern, dürfen nicht in die Liste – sonst liefert der Cache falsche Inhalte aus.

Browser-Support: heute Chrome, morgen Standard

No-Vary-Search ist aktuell primär in Chrome und Chromium-basierten Browsern implementiert. Firefox und Safari sind zurückhaltend. Das klingt nach einem Grund, es zu ignorieren – ist es aber nicht.

Der Header schadet bei nicht unterstützten Browsern nicht. Er wird ignoriert. Das macht ihn zu einer risikolosen Progressive Enhancement: Chrome-Nutzer profitieren sofort, alle anderen verhalten sich wie bisher.

URLs wie /sale?utm_source=google, /sale?utm_source=chatgpt und /sale?utm_source=newsletter werden ohne No-Vary-Search als drei separate Ressourcen gecacht – obwohl alle drei byte-für-byte identisches HTML liefern. Im besten Fall bedeutet das verschwendeten Cache-Speicher, im schlechtesten Fall unnötige Netzwerkanfragen.

Das ist einer der wenigen HTTP-Standards, der explizit auf Reduktion von Datenhaltung und redundanten Transfers ausgelegt ist. Für eine Hugo-Site mit Matomo: fünf Minuten Aufwand, dauerhafter Effekt.

Danke Johan von Hülsen für den Impuls im aktuellen Wingman-Newsletter #309.

Mehr zur Implementierung bei CSS Wizardry: csswizardry.com

Die technische Spezifikation: httpwg.org