gclid-Cache: Abfrageparameter von Anzeigenklicks, Seiten-Cache-Schlüssel und gemessene Zeit bis zum ersten Byte
Bei der gclid-Cache-Behandlung wird der gclid-Parameter am Ende einer Anzeigenklick-URL ignoriert und mit der Cache-Datei der Adresse ohne Query-String geantwortet. Messungen der Zeit bis zum ersten Byte nach Query-Parametern und Cache-Zustand auf einem WordPress-Server mit Nginx + Apache ergaben: gclid kostete 0,014–0,015 Sekunden, Verzögerungen von mehreren Sekunden traten nur auf, wenn der Cache nicht genutzt werden konnte.
Innerhalb desselben Servers gemessen lag die Zeit bis zum ersten Byte ohne Query-String bei 0,014–0,015 Sekunden und mit angehängten Anzeigenklick-Parametern bei 0,029–0,030 Sekunden. Als WordPress dieselbe Seite ohne Cache neu erzeugte, dauerte es 3,639 und 3,260 Sekunden.
1️⃣ gclid-Cache: Anzeigenklick-URLs und Cache-Schlüssel
Mit der automatischen Tag-Kennzeichnung von Google Ads wird an die URL von Besuchern, die auf eine Anzeige klicken, [?gclid=Wert] angehängt. Dieser Wert ist ein Parameter, der den Anzeigenklick kennzeichnet, und unterscheidet sich daher von Besucher zu Besucher; klickt dieselbe Person erneut auf dieselbe Anzeige, kann allerdings derselbe Wert verwendet werden.
Echte Anzeigenklick-URLs tragen selten nur gclid. Oft hängen gad_source, gad_campaignid und gbraid mit dran, manchmal auch wbraid.
https://example.com/sample-page/?gad_source=1&gad_campaignid=1234567890&gbraid=EXAMPLE&gclid=EXAMPLE
https://example.com/sample-page/?gclid=EXAMPLE&gbraid=EXAMPLE&wbraid=EXAMPLEAuch mit einem Query-String am Ende öffnet der Browser dieselbe Seite, für einen Cache ist es aber eine andere Adresse. Der HTTP-Caching-Standard (RFC 9111) legt fest, dass der Cache-Schlüssel – das Kriterium, nach dem ein Cache eine gespeicherte Antwort auswählt – mindestens aus Anfragemethode und Ziel-URI besteht, und die Ziel-URI enthält auch den Query-String.
Landet der Query-String unverändert im Cache-Schlüssel, wird jeder Klick mit einem anderen gclid-Wert zu einer neuen Adresse. CDN, nginx und WP Rocket, die die Antwort durchläuft, behandeln diesen Parameter jeweils nach eigenen Regeln.
Hat das CDN keine Kopie oder unterscheidet sein Cache-Schlüssel die Query-Parameter, geht die Anfrage an den Ursprungsserver. Wie schnell es danach geht, hängt davon ab, ob nginx und WP Rocket eine Cache-Datei finden.
2️⃣ Statische Auslieferung durch nginx: mit Query-String weiter an Apache
Auch wenn die Cache-Datei auf der Platte liegt, liefert nginx in einem Nginx-+-Apache-Setup sie bei einer Anfrage mit Query-String nicht direkt aus. Denn die Konfiguration unten, mit der nginx die Cache-Dateien von WP Rocket direkt liest, baut den Dateipfad nur bei leerem Query-String.
# nginx.conf — http-Block: Bedingungen, um die Cache-Datei zu überspringen
map $http_cookie $rocket_cookie {
default 0;
'~*wordpress_logged_in' 1;
'~*wp-postpass' 1;
'~*comment_author' 1;
'~*woocommerce_items' 1;
}
map $request_method $rocket_method {
default 1;
GET 0;
HEAD 0;
}
map $query_string $rocket_query {
default 1;
'' 0; # 0 nur bei leerem Query-String
}
# server-Block
set $rocket_bypass '';
if ($rocket_cookie = 1) { set $rocket_bypass '1'; }
if ($rocket_method = 1) { set $rocket_bypass '1'; }
if ($rocket_query = 1) { set $rocket_bypass '1'; }
set $rocket_file '/wp-content/cache/wp-rocket/example.com${request_uri}index-https.html';
if ($rocket_bypass = '1') { set $rocket_file ''; }
location / {
try_files $rocket_file @apache; # an Apache, wenn der Pfad leer ist oder die Datei fehlt
add_header X-Rocket-Nginx-Serving-File 'HIT' always; # Kennzeichen: nginx hat die Cache-Datei direkt ausgeliefert
}[$rocket_query] prüft nur, ob der gesamte Query-String leer ist; gclid, das WP Rocket ignoriert, wird daher wie jeder andere Parameter behandelt. Werden mobile Kopien getrennt gehalten, kommt noch eine Prüfung hinzu, die [-mobile] an den Dateinamen hängt.
Auch die [.htaccess]-Regeln, die WP Rocket für Apache schreibt, verlangen einen leeren Query-String. Ob nginx oder Apache: Der Schritt, der die Cache-Datei ohne PHP direkt ausliefert, gilt nur für Anfragen ohne Query-String.
Anfragen ohne Query-String enthielten den Header [X-Rocket-Nginx-Serving-File: HIT], die sechs Anfragen mit gclid und anzeigenartigen Parametern nicht. Dass die Zeit bis zum ersten Byte bei Anfragen mit Query-String um 0,014–0,015 Sekunden stieg, liegt daran, dass Apache und PHP die Cache-Datei lesen und ausliefern mussten.
curl -so /dev/null -H 'Accept-Encoding: gzip' -w '%{time_starttransfer}\n' \
'https://example.com/sample-page/'0.015127curl -so /dev/null -H 'Accept-Encoding: gzip' -w '%{time_starttransfer}\n' \
'https://example.com/sample-page/?gclid=test123'0.029525curl -sI 'https://example.com/sample-page/' | grep -i x-rocket-nginx-serving-filex-rocket-nginx-serving-file: HIT[time_starttransfer] ist die Zeit von der Anfrage bis zum Eintreffen des ersten Bytes. Um ohne CDN im Server zu messen, hängst du [--resolve example.com:443:127.0.0.1] mit an.
3️⃣ Ignorier-Liste von WP Rocket: Antwort aus derselben Cache-Datei
Adressen mit Query-String nicht zu cachen ist das Standardverhalten von WP Rocket, Anzeigenklick-Parameter sind aber die Ausnahme. WP Rocket entfernt vor der Entscheidung die Parameter auf seiner Ignorier-Liste und antwortet, wenn keine übrig bleiben, mit der Cache-Datei der Adresse ohne Query-String.
// wp-rocket/inc/classes/Buffer/class-tests.php (3.23.5.1)
public function get_query_params() {
// …
$params = array_diff_key( // zuerst die ignorierten Parameter entfernen
self::$get,
$this->config->get_config( 'cache_ignored_parameters' )
);
// …
}
public function can_process_query_string() {
// …
$params = $this->get_query_params();
if ( ! $params ) { // keine Parameter übrig: aus dem Cache bedienen
return self::memoize( __FUNCTION__, [], true );
}
// nur lang · s · permalink_name · lp-variation-id und in [Cache Query String(s)] eingetragene Parameter kommen durch
// …
}Ist das, was [get_query_params] nach dem Entfernen der ignorierten Parameter liefert, leer, wird auch der Pfad der Cache-Datei auf die Adresse ohne Query-String gesetzt. Die Anfrage mit gclid lief über Apache und PHP, doch der Cache-Kommentar am Ende des HTML glich dem der Anfrage ohne Query-String, und die Antwort war mit 350.668 Bytes so groß wie die Cache-Datei (gzip).
Die Ignorier-Liste ist eine Standardliste, die WP Rocket einmal pro Woche von den eigenen Servern lädt und in [wp-content/wp-rocket-config/dynamic-lists.json] speichert. Stand 17. Oktober 2026 enthält sie gclid, gbraid, wbraid, gad_source und gad_campaignid.
Ist auch nur ein Parameter dabei, der nicht auf der Liste steht, nutzt WP Rocket den Cache nicht: Dieselbe Seite mit einem beliebigen Parameter außerhalb der Liste erzeugte WordPress neu, ohne Cache-Kommentar. Hängen an deinen Anzeigen-URLs selbst gebaute Tracking-Parameter, laufen diese Klicks jedes Mal über diesen Weg.
Um die Liste zu ändern, nutzt du das von WP Rocket empfohlene Helper-Plugin. Das Plugin fügt über den Filter [rocket_cache_ignored_parameters] Parameter hinzu oder entfernt sie und erzeugt beim Aktivieren und Deaktivieren die Konfigurationsdatei von WP Rocket neu.
// aus WP Rocket | Ignore Query Strings 1.1.1 (Helper-Plugin des WP-Rocket-Supportteams)
function define_ignored_parameters( array $params ) {
$params['new_query_string'] = 1; // zu den ignorierten Parametern hinzufügen
//unset ( $params['utm_source'] ); // aus den ignorierten Parametern entfernen
return $params;
}
add_filter( 'rocket_cache_ignored_parameters', __NAMESPACE__ . '\define_ignored_parameters', 999 );
register_activation_hook( __FILE__, __NAMESPACE__ . '\flush_wp_rocket' ); // beim Aktivieren rocket_generate_config_file() ausführenWP Rocket schreibt diese Liste in die nach der Domain benannte Konfigurationsdatei in [wp-content/wp-rocket-config/] und liest diese Datei bei jeder Anfrage; fügst du nur den Filter hinzu, ohne die Konfigurationsdatei neu zu erzeugen, greift die neue Liste nicht. Parameter auf der Liste nutzen unabhängig vom Wert die eine Cache-Datei der Basisadresse – nimm also keine Parameter auf, deren Wert den Seiteninhalt ändert.
Nachdem [uk_test], das nicht auf der Liste stand, im Helper-Plugin ergänzt und das Plugin aktiviert war, wurde die Konfigurationsdatei neu erzeugt und der Parameter ans Listenende angehängt. Danach wurden nacheinander die Adresse ohne Query-String und zwei Adressen mit unterschiedlichen [uk_test]-Werten angefragt.
curl -s -o /dev/null -w '%{size_download} %{time_starttransfer}\n' -H 'Accept-Encoding: gzip' 'https://example.com/sample-page/'
curl -s -o /dev/null -w '%{size_download} %{time_starttransfer}\n' -H 'Accept-Encoding: gzip' 'https://example.com/sample-page/?uk_test=abc'
curl -s -o /dev/null -w '%{size_download} %{time_starttransfer}\n' -H 'Accept-Encoding: gzip' 'https://example.com/sample-page/?uk_test=xyz'21390 0.025720
21390 0.025507
21390 0.027929Alle drei Anfragen lieferten dieselben 21.390 Bytes in unter 0,03 Sekunden; am Ende des HTML der Anfrage mit [uk_test] wurde die Cache-Zeit geprüft.
curl -s --compressed 'https://example.com/sample-page/?uk_test=abc' | tail -c 200ck=lazyLoadYoutubeIframe;}});</script></body>
</html>
<!-- This website is like a Rocket, isn't it? Performance optimized by WP Rocket. Learn more: https://wp-rocket.me - Debug: cached@1792248839 -->Die Cache-Zeit im Schlusskommentar entsprach der Cache-Datei der Adresse ohne Query-String. Vor dem Aktivieren des Helper-Plugins wurde dieselbe Anfrage in 0,36–0,38 Sekunden neu erzeugt, ohne Cache-Kommentar.
Auch nach dem Aktivieren wurde eine Anfrage, die zusätzlich [foo] trug – nicht auf der Liste –, ohne Cache-Datei neu erzeugt.
In der ersten Minute nach dem Neuerzeugen der Konfigurationsdatei wurden auch [uk_test]-Anfragen neu erzeugt. Da PHP OPcache geänderte Dateien in diesem Setup alle 60 Sekunden neu prüft (revalidate_freq), kam die Antwort erst nach einer Minute aus der Cache-Datei.
Auch nach dem Deaktivieren und Löschen des Helper-Plugins blieb die Zeile [uk_test] in der Konfigurationsdatei. Der Code beim Deaktivieren versucht, den mit Priorität 999 eingehängten Filter mit der Standardpriorität zu entfernen; die Konfigurationsdatei wird also mit noch aktivem Filter neu erzeugt. Erst wenn du sie nach dem Löschen des Plugins noch einmal neu erzeugst, verschwindet der Eintrag aus der Liste.
4️⃣ CDN-Cache-Schlüssel: Anzeigen-Parameter ausschließen und Anfragen an den Ursprung
Übernimmt das CDN den Query-String unverändert in den Cache-Schlüssel, findet jeder Klick mit anderem gclid-Wert keine Kopie, und die Anfrage geht bis zum Ursprungsserver. Alle Parameter zu entfernen löst das, passt aber nicht zu Websites mit Adressen, deren Inhalt sich je nach Parameter ändert – etwa Suchergebnisse. Besser ist es daher, nur die Anzeigen-Parameter aus dem Cache-Schlüssel zu entfernen.
Sind die Anzeigen-Parameter so entfernt, antwortet das CDN auch bei anderem gclid-Wert mit derselben Kopie wie für die Adresse ohne Query-String und fragt nur dann samt Query-String beim Ursprungsserver an, wenn es keine Kopie hat.
# CDN-Cache-Status zweier Anfragen mit unterschiedlichem gclid (Header-Namen je nach CDN)
curl -sI 'https://example.com/sample-page/?gclid=test1' | grep -i -E 'cache|age'curl -sI 'https://example.com/sample-page/?gclid=test2' | grep -i -E 'cache|age'Sind beide Anfragen mit unterschiedlichem Wert HITs und wurden ihre Kopien zur selben Zeit gespeichert wie die der Adresse ohne Query-String, lässt dieses CDN gclid aus dem Cache-Schlüssel heraus. Der erste Besuch an einem Standort ohne Kopie läuft trotzdem durch nginx und WP Rocket auf dem Ursprungsserver, auch wenn das CDN Anzeigen-Parameter aus dem Schlüssel entfernt.
5️⃣ Ursache langsamer Anzeigenklicks: ein leerer Seiten-Cache
Lädt die erste Seite nach einem Anzeigenklick langsam, liegt der Verdacht nahe, gclid umgehe den Cache – doch ist eine Cache-Datei da, wird auch mit Query-String dieselbe Cache-Datei ausgeliefert. Sekunden zusätzlich bis zum ersten Byte kostet nur eine leere Cache-Datei, bei der WordPress die Seite neu erzeugt.
Cache-Dateien werden gelöscht, sobald die Cache-Lebensdauer abgelaufen ist; der Standardwert von WP Rocket liegt bei 10 Stunden. Beim Speichern eines Beitrags oder der Einstellungen wird auch der zugehörige Cache gelöscht, und wenn die Liste, die WP Rocket einmal pro Woche lädt, durch eine neue Version ersetzt wird, wird der gesamte Cache der Website geleert.
Mit aktiviertem Preload ruft WP Rocket geleerte Adressen erneut auf und füllt den Cache wieder; wer vorher kommt, wartet, bis die Seite erzeugt ist. Auch eine Anfrage nur mit Anzeigen-Parametern legt die Cache-Datei unter der Adresse ohne Query-String an – der Anzeigenklick, der als Erster auf einen leeren Cache trifft, füllt ihn also für den nächsten Besucher.
Direkt nach dem Leeren des Caches fand die erste Anfrage mit anzeigenartigen Parametern keine Cache-Datei und wurde in 0,341–0,369 Sekunden neu erzeugt; in derselben Sekunde entstand die Cache-Datei der Adresse ohne Query-String.
curl -s -o /dev/null -w '%{size_download} %{time_starttransfer}\n' -H 'Accept-Encoding: gzip' 'https://example.com/sample-page/?gclid=EXAMPLE1'
ls -l --time-style='+%F %T' wp-content/cache/wp-rocket/example.com/sample-page/
curl -s -o /dev/null -w '%{size_download} %{time_starttransfer}\n' -H 'Accept-Encoding: gzip' 'https://example.com/sample-page/'21361 0.366881
insgesamt 116
-rw-r--r-- 1 example nobody 90908 2026-10-17 23:56:38 index-https.html
-rw-r--r-- 1 example nobody 21385 2026-10-17 23:56:38 index-https.html_gzip
21385 0.025379Alle drei Durchläufe liefen in derselben Reihenfolge ab, und die anschließende Anfrage ohne Query-String wurde in 0,023–0,025 Sekunden aus der neuen Cache-Datei beantwortet. Da die Anfrage nicht von einem Mobilgerät kam, entstanden nur die zwei Desktop-Dateien.
Bei den Adressen, auf die deine Anzeigen verlinken, prüfst du selbst, ob es eine Cache-Datei gibt und wann sie entstand; werden mobile Kopien getrennt angelegt, prüfst du Desktop- und Mobil-Dateien zusammen.
ls -l --time-style='+%F %T' wp-content/cache/wp-rocket/example.com/sample-page/insgesamt 3520
-rw-r--r-- 1 example nobody 1445922 2026-10-17 14:07:44 index-https.html
-rw-r--r-- 1 example nobody 350668 2026-10-17 14:07:44 index-https.html_gzip
-rw-r--r-- 1 example nobody 1446862 2026-10-17 14:07:47 index-mobile-https.html
-rw-r--r-- 1 example nobody 351042 2026-10-17 14:07:47 index-mobile-https.html_gzipcurl -s --compressed 'https://example.com/sample-page/?gclid=test123' | tail -c 200n/1/wp-content/uploads/example-plugin/style.css' media='all' /></noscript></body>
</html>
<!-- Cached for great performance - Debug: cached@1792213663 -->Bei einer Antwort aus einer Cache-Datei steht im Kommentar am Ende des HTML hinter [Debug: cached@] die Erstellungszeit der Datei als Unix-Zeit. Fehlt diese Markierung, hat WordPress die Antwort neu erzeugt.
🔢 FAQ & empfohlene Inhalte
ℹ️ Affiliate-Hinweis
Die Inhalte dieser Website enthalten Affiliate-Links. Kauft ein Besucher über einen dieser Links ein Produkt oder eine Dienstleistung, erhält die Website vom Verkäufer eine Provision. Der Betrag, den der Käufer zahlt(bei Aktionsrabatten sinkt er ↓), steigt dadurch nicht. Angegebene Preise, Rabatte und Lagerbestände entsprechen dem Stand bei Erstellung und können abweichen; prüfe sie daher vor dem Kauf beim Verkäufer. Produkte werden nach eigenen Kriterien ausgewählt und bewertet, und Provisionen beeinflussen weder die Reihenfolge noch den Inhalt der Bewertungen.