28. Cache scripts¶
Suppose that there are two URLs that render the same page on the site:
https://www.supershoes.example/search/?shoe:color=red&gclid=9fjsdu0u
https://www.supershoes.example/search/?gclid=0bjDdAt&shoe:color=red
and that page is different than the one at:
https://www.supershoes.example/search/?gclid=0bjDdAt&q=shoe-color:green
So, from the point of view of ShimmerCat, the first two URLs should receive the same rules, while the third should receive its own set of rules. How to be flexible enough to consider these type of cases? Here is where cache scripts help.
Cache script files have one simple function: to produce a key that can be used to index accelerator rules for pages which are essentially the same regarding static assets.
28.1. Where .cache-script files go?¶
Cache scripts are associated with views. Whenever there is a view, there can be a matching cache script, and the naming convention is as follows:
index.html -> index.html.cache-script
__index.html -> __index.html.cache-script
As you may guess, whenever a particular view is used, ShimmerCat also looks for an associated cache script. If it finds it, it evaluates its contents on the context of this particular request, trying to derive a key which is then used to fetch push rules and priorities.
In the accelerator, .cache-script
files can be set in one of two ways:
They can be created by hand in the views dir, and “pushed” (with sc_pack push ) to the accelerator. This is the best way to go if you know best which query strings end up making the page render differently. Or
The cloud service will eventually add default
.cache-scripts
to the views under/+target/
, provided that the coordinated image loading pipeline runs for pages ushered by those views.
28.2. What’s in .cache-script files?¶
Lua modules, which are evaluated in our base Lua environment.
Here is an example cache-script:
local cache = {}
function string_starts(String,Start)
return string.sub(String,1,string.len(Start))==Start
end
-- Special function, will be looked-up by name
function cache.extend_key(request)
-- trace("extend-called")
return request.uri_path.path .. ' ' ..
string.match(request.uri_path.query, "%w+:%w+=%w+")
end
return cache
The script must return a module with one function: extend_key
This extend_key
function should take into account relevant parts of the query string, cookies
and so on, and return a page key.
The page key is used to locate .push-hint blocks in Redis, with dynamically generated suggestions of
assets to push.
The parameter request
received by extend_key
is a Lua table with the following members:
view_path
: the viewuri_path
: the uri path, expressed as a table with memberspath
,query
andfragment
.cookies
: a dictionary of cookiescache-control
: the cache-control directive