Caching of query parameters
When receiving a request for a URL, the page cache considers the entirety of the URL, including GET
parameters. As a result, the page cache will identify example.com/?a=1&b=1
as different from example.com?b=1&a=1
and cache each variant separately. This caching behavior provides a more scalable method for serving variations of a page to specific user groups.
Because each variant of a URL’s GET
parameters are cached separately, an increase in the number of variants for a URL can have performance implications for a site, particularly during a high traffic event. The first request for each variant will bypass cache and will result in SQL queries on the origin server. A large volume of direct SQL queries can overload the primary database and lead to an increase in responses with a 503
HTTP status code.
- Avoid using very explicit times (e.g., specifying minutes or seconds) in query parameters. Instead, round the dates and times up to the closest day, hour, or minute.
- Avoid creating email campaigns that generate a wide variety of query parameter variants. Reduce the number of variants wherever possible.
Purging a URL from the page cache
When purging a URL from the page cache, all variants of the URL’s GET
parameters will also be purged.
Filtered query parameters
Some query parameters included in URLs provide no benefit to users in personalizing responses based on their values, and only serve a purpose for analytics.
A specific set of those query parameters are filtered at the Varnish page cache, including: hpt, eref, iref, fbid, fb_xd_bust, fb_xd_fragment, npt, iid, icid, ncid, snapid, _, fb_ref, fb_source, omcamp, affiliate, migAgencyId, migSource, migTrackDataExt, migRandom, gclid, migTrackFmtExt, linkId, _ga, hootPostID, pretty, gref, __lsa, ia_share_url, fbclid, mod, wsrlui
If any of the filtered query parameters listed above are included in a request for a URL, those query parameters—and their values—will be ignored. The page cache will check all other query parameters and values in the URL before potentially passing the request to the origin server.
For example:
www.example.com/?fbclid=100
is rewritten by Varnish as a request towww.example.com/
when searching for existing cached entries.www.example.com/?hpt=foo&bar=baz
is rewritten aswww.example.com/?bar=baz
.- Query strings with a value and no name, such as
www.example.com/?=foo
are also filtered to reflectwww.example.com/
.
Last updated: April 03, 2023