gclid-cache: querystring van advertentieklikken, cachesleutel van de pagina en gemeten eerste byte
gclid-cache-afhandeling betekent dat de gclid-query aan het eind van een advertentieklik-URL wordt genegeerd en dat er wordt geantwoord met het cachebestand van de URL zonder query. Metingen van de eerste byte per query en per cachestatus op een WordPress-server met Nginx + Apache lieten zien dat gclid 0,014–0,015 seconde toevoegde en dat vertragingen van enkele seconden alleen optraden als de cache niet gebruikt kon worden.
Binnen dezelfde server gemeten was de eerste byte 0,014–0,015 seconde zonder query en 0,029–0,030 seconde met advertentieklik-query's erbij. Toen WordPress dezelfde pagina zonder cache opnieuw opbouwde, duurde dat 3,639 en 3,260 seconden.
1️⃣ gclid-cache: advertentieklik-URL's en de cachesleutel
Als automatisch taggen in Google Ads aanstaat, wordt [?gclid=waarde] aan het eind van de URL toegevoegd voor bezoekers die op een advertentie klikken. Deze waarde is een parameter die de advertentieklik identificeert en verschilt dus per bezoeker, al kan dezelfde persoon die opnieuw op dezelfde advertentie klikt dezelfde waarde krijgen.
Echte advertentieklik-URL's hebben zelden alleen gclid. Vaak komen gad_source, gad_campaignid en gbraid mee, en soms ook 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=EXAMPLEMet een query aan het eind van de URL opent de browser nog steeds dezelfde pagina, maar voor een cache is het een ander adres. De HTTP-cachingstandaard (RFC 9111) definieert de cachesleutel, waarmee een cache een opgeslagen antwoord kiest, als minstens de verzoekmethode en de doel-URI, en de doel-URI bevat ook de querystring.
Gaat de querystring ongewijzigd de cachesleutel in, dan wordt elke klik met een andere gclid-waarde een nieuw adres. Het CDN, nginx en WP Rocket, waar het antwoord doorheen gaat, behandelen deze query elk volgens een andere regel.
Heeft het CDN geen kopie of onderscheidt de cachesleutel query's, dan gaat het verzoek door naar de originserver. Vanaf daar hangt de snelheid ervan af of nginx en WP Rocket een cachebestand vinden.
2️⃣ Statisch serveren door nginx: verzoeken met een query gaan naar Apache
Ook als het cachebestand op schijf staat, serveert nginx in een Nginx + Apache-opstelling het niet direct bij een verzoek met een query. Dat komt doordat de configuratie hieronder, waarmee nginx de cachebestanden van WP Rocket direct leest, alleen een bestandspad opbouwt als de querystring leeg is.
# nginx.conf — http-blok: voorwaarden om het cachebestand over te slaan
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; # alleen 0 als de querystring leeg is
}
# server-blok
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; # naar Apache als het pad leeg is of het bestand ontbreekt
add_header X-Rocket-Nginx-Serving-File 'HIT' always; # markeert antwoorden die nginx direct uit het cachebestand gaf
}[$rocket_query] controleert alleen of de hele querystring leeg is, dus gclid, dat WP Rocket negeert, wordt net zo behandeld als elke andere query. Worden mobiele kopieën apart bewaard, dan komt er nog een controle bij die [-mobile] aan de bestandsnaam toevoegt.
Ook de [.htaccess]-regels die WP Rocket voor Apache schrijft, vereisen een lege querystring. Of het nu nginx of Apache is: de stap die het cachebestand direct zonder PHP serveert, geldt alleen voor verzoeken zonder query.
Verzoeken zonder query kregen de header [X-Rocket-Nginx-Serving-File: HIT], de zes verzoeken met gclid en advertentie-achtige query's niet. De eerste byte werd bij verzoeken met een query 0,014–0,015 seconde later, omdat Apache en PHP, die het cachebestand lezen en teruggeven, aan de route werden toegevoegd.
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] is de tijd van het verzoek tot de eerste byte binnenkomt. Om binnen de server te meten zonder via het CDN te gaan, voeg je [--resolve example.com:443:127.0.0.1] toe.
3️⃣ Lijst met genegeerde query's van WP Rocket: hetzelfde cachebestand
URL's met een query niet cachen is de standaard van WP Rocket, maar advertentieklik-query's vormen een uitzondering. WP Rocket haalt de parameters op zijn lijst met genegeerde query's weg voordat het beslist, en als er geen query's overblijven, antwoordt het met het cachebestand van de URL zonder query.
// wp-rocket/inc/classes/Buffer/class-tests.php (3.23.5.1)
public function get_query_params() {
// …
$params = array_diff_key( // eerst de genegeerde query's weghalen
self::$get,
$this->config->get_config( 'cache_ignored_parameters' )
);
// …
}
public function can_process_query_string() {
// …
$params = $this->get_query_params();
if ( ! $params ) { // geen query's over: met cache afhandelen
return self::memoize( __FUNCTION__, [], true );
}
// alleen lang · s · permalink_name · lp-variation-id en query's uit [Cache Query String(s)] komen erdoor
// …
}Is wat [get_query_params] teruggeeft na het weghalen van de genegeerde query's leeg, dan wordt ook het pad van het cachebestand op de URL zonder query gezet. Het verzoek met gclid ging via Apache en PHP, maar het cachecommentaar aan het eind van de HTML kwam overeen met dat van het verzoek zonder query, en de antwoordgrootte was 350.668 bytes, gelijk aan het cachebestand (gzip).
De lijst met genegeerde query's is een standaardlijst die WP Rocket eens per week van zijn eigen servers downloadt en opslaat in [wp-content/wp-rocket-config/dynamic-lists.json]. Op 17 oktober 2026 staan gclid, gbraid, wbraid, gad_source en gad_campaignid in de lijst.
Zit er ook maar één query tussen die niet op de lijst staat, dan gebruikt WP Rocket de cache niet: dezelfde pagina met een willekeurige query die niet op de lijst stond, werd door WordPress opnieuw opgebouwd, zonder cachecommentaar. Hangen er aan je advertentie-URL's trackingquery's die je zelf hebt gemaakt, dan gaan die klikken elke keer deze weg.
Om de lijst te wijzigen gebruik je de helper-plugin die WP Rocket aanraadt. De plugin voegt via de filter [rocket_cache_ignored_parameters] query's toe of haalt ze weg en maakt bij activeren en deactiveren het configuratiebestand van WP Rocket opnieuw aan.
// uit WP Rocket | Ignore Query Strings 1.1.1 (helper-plugin van het supportteam van WP Rocket)
function define_ignored_parameters( array $params ) {
$params['new_query_string'] = 1; // toevoegen aan de genegeerde query's
//unset ( $params['utm_source'] ); // uit de genegeerde query's halen
return $params;
}
add_filter( 'rocket_cache_ignored_parameters', __NAMESPACE__ . '\define_ignored_parameters', 999 );
register_activation_hook( __FILE__, __NAMESPACE__ . '\flush_wp_rocket' ); // voert bij activeren rocket_generate_config_file() uitWP Rocket schrijft deze lijst in het configuratiebestand met de domeinnaam in [wp-content/wp-rocket-config/] en leest dat bestand bij elk verzoek, dus als je alleen de filter toevoegt zonder het configuratiebestand opnieuw aan te maken, wordt de nieuwe lijst niet toegepast. Query's op de lijst delen ongeacht hun waarde het ene cachebestand van de basis-URL, dus voeg geen query's toe waarvan de waarde verandert wat de pagina toont.
Na het toevoegen van [uk_test], dat niet op de lijst stond, aan de helper-plugin en het activeren ervan werd het configuratiebestand opnieuw aangemaakt met die query aan het eind van de lijst. Daarna werden de URL zonder query en twee URL's met verschillende waarden voor [uk_test] na elkaar opgevraagd.
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 drie de verzoeken gaven binnen 0,03 seconde dezelfde 21.390 bytes terug, en het eind van de HTML van het verzoek met [uk_test] werd geopend om de cachetijd te controleren.
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 -->De cachetijd in het slotcommentaar kwam overeen met het cachebestand van de URL zonder query. Voordat de helper-plugin werd geactiveerd, werd hetzelfde verzoek in 0,36–0,38 seconde opnieuw opgebouwd, zonder cachecommentaar.
Ook na het activeren gebruikte een verzoek dat daarnaast [foo] had, dat niet op de lijst staat, het cachebestand niet en werd het opnieuw opgebouwd.
Gedurende één minuut direct na het opnieuw aanmaken van het configuratiebestand werden ook verzoeken met [uk_test] opnieuw opgebouwd. Omdat PHP OPcache was ingesteld om gewijzigde bestanden elke 60 seconden opnieuw te controleren (revalidate_freq), kwamen de antwoorden pas na een minuut uit het cachebestand.
Ook nadat de helper-plugin was gedeactiveerd en verwijderd, bleef de regel met [uk_test] in het configuratiebestand staan. De deactiveringscode probeert de filter, die met prioriteit 999 is toegevoegd, met de standaardprioriteit te verwijderen, waardoor het configuratiebestand opnieuw wordt aangemaakt terwijl de filter er nog is. Pas door het configuratiebestand na het verwijderen van de plugin nog een keer aan te maken, verdwijnt de query uit de lijst.
4️⃣ Cachesleutel van het CDN: advertentiequery's uitsluiten en verzoeken aan de originserver
Zet het CDN de querystring ongewijzigd in de cachesleutel, dan vindt elke klik met een andere gclid-waarde geen kopie en gaat het verzoek helemaal door naar de originserver. Query's in hun geheel weglaten lost dat op, maar past niet bij sites met URL's waarvan de inhoud per query verandert, zoals zoekresultaten, dus je kunt beter alleen de advertentiequery's uit de cachesleutel halen.
Met de advertentiequery's op die manier weggehaald antwoordt het CDN ook bij een andere gclid-waarde met dezelfde kopie als voor de URL zonder query, en alleen als het geen kopie heeft, stuurt het het verzoek met de query naar de originserver.
# CDN-cachestatus van twee verzoeken met verschillende gclid-waarden (headernamen verschillen per 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'Zijn beide verzoeken met verschillende waarden een HIT en werden hun kopieën op hetzelfde moment opgeslagen als die van de URL zonder query, dan laat dat CDN gclid buiten de cachesleutel. Het eerste bezoek op een locatie zonder kopie gaat nog steeds door nginx en WP Rocket op de originserver, ook als het CDN advertentiequery's uit de sleutel haalt.
5️⃣ Waarom advertentieklikken traag zijn: een lege paginacache
Laadt de eerste pagina vanuit een advertentie traag, dan ligt het voor de hand gclid de schuld te geven van het omzeilen van de cache, maar als er een cachebestand is, wordt ook met een query hetzelfde cachebestand geserveerd. Wat seconden aan de eerste byte toevoegt, is een leeg cachebestand, waardoor WordPress de pagina opnieuw moet opbouwen.
Cachebestanden worden verwijderd zodra de tijd uit de instelling Cachelevensduur verstreken is; de standaardwaarde van WP Rocket is 10 uur. Bij het opslaan van een bericht of van instellingen wordt ook de bijbehorende cache verwijderd, en wanneer de lijst die WP Rocket eens per week downloadt door een nieuwe versie wordt vervangen en opgeslagen, wordt ook de hele sitecache geleegd.
Met preload aan opent WP Rocket geleegde URL's opnieuw en vult de cache weer, en bezoekers die eerder binnenkomen wachten terwijl de pagina wordt opgebouwd. Ook een verzoek met alleen advertentiequery's maakt het cachebestand aan onder de URL zonder query, dus de advertentieklik die als eerste op een lege cache stuit, vult die voor de volgende bezoeker.
Direct na het legen van de cache vond het eerste verzoek met advertentie-achtige query's geen cachebestand en werd het in 0,341–0,369 seconde opnieuw opgebouwd; in dezelfde seconde verscheen het cachebestand voor de URL zonder query.
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
Totaal 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 drie de keren verliep het in dezelfde volgorde, en het verzoek zonder query dat volgde werd in 0,023–0,025 seconde uit het nieuwe cachebestand beantwoord. Omdat het verzoek niet van een mobiel apparaat kwam, werden alleen de twee desktopbestanden aangemaakt.
Controleer voor de URL's waar je advertenties naartoe linken zelf of er een cachebestand is en wanneer het is aangemaakt; worden mobiele kopieën apart gemaakt, controleer dan zowel het desktop- als het mobiele bestand.
ls -l --time-style='+%F %T' wp-content/cache/wp-rocket/example.com/sample-page/Totaal 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 -->Een antwoord uit een cachebestand heeft in het commentaar aan het eind van de HTML na [Debug: cached@] het moment waarop het bestand is aangemaakt, in Unix-tijd. Zonder deze markering heeft WordPress dat antwoord opnieuw opgebouwd.
🔢 FAQ & aanbevolen content
ℹ️ Affiliatemelding
De content van deze site bevat affiliatelinks. Koopt een bezoeker via een van deze links een product of dienst, dan ontvangt deze site een commissie van de verkoper. Het bedrag dat de koper betaalt (bij acties gaat het omlaag ↓) wordt daardoor niet hoger. De vermelde prijzen, kortingen en voorraad gelden op het moment van schrijven en kunnen afwijken; controleer ze daarom vóór je aankoop bij de verkoper. Producten worden gekozen en beoordeeld volgens onze eigen criteria, en commissies hebben geen invloed op de volgorde of de inhoud van de beoordelingen.