Cache and geolocated content

  • Hello,

    I am evaluating whether it will be possible to use this plugin for my geotargeted sites.

    Currently, the way I have this setup is that I have a worker which adds geolocation headers to server requests, based on the values of CloudFlare’s request.cf object. Then, on the server, I show/hide content based on these headers. I am able to serve most of these pages from the LiteSpeed public cache, as I have a directive in place that varies the cache, based on the country and region.

    Basically, I am wondering if it is possible to achieve the same setup, except replace the LiteSpeed public cache with CloudFlare’s own cache. I assume it should be possible to modify this plugin’s worker to add the new request headers, but any ideas on what would be required to split up the CF cache based on the country/region? Then how can one go about invalidating that cache using the plugin? And what about preloading it from the various key locations?

Viewing 5 replies - 1 through 5 (of 5 total)
  • Plugin Contributor iSaumya

    (@isaumya)

    Hi,
    what you are looking for is technically possible but it’s advanced stuff so if you are not habituated with the plugin then it will be hard for you.

    That being said, let me tell you how this can be achieved. First of all, the way you are doing it now is counterintuitive and can be done in a better way. You don’t need to use to the worker to add a location response header for the server to see.

    Instead for a moment forget about all the caching and imagine all request is managed by your origin server, in this case inside your site’s code you can use some API or MaxMind data to check where the user is coming from, and then based on that show the data.

    Now comes the caching part. Here you definitely need to sue the worker. Basically, you need to overwrite our worker code with custom logic for your purpose. Inside the plugin settings FAQ section it is clearly mentioned how to do this: https://i.imgur.com/8fCFA6z.jpeg

    If you look at this gist: https://gist.github.com/isaumya/b4776a7f7b7c56a50aa8e75f1dd60aa8 which I created about 2 months back and since then didn’t get time to update it. But if you look at the code you will see how we are creating different cacheKey by attending a query string to the URL inside the worker which the user can’t see but to CF it will be treated as a different cacheKey. You can apply the same logic to incorporate location details to make the cacheKey unique.

    Also use the worker code from this upcoming build soi that you don’t have to modify the worker code again once we update the default worker code.

    This will give you everything you are looking for. But it’s just occasionally you have to check the default worker code in case we have updated it in any means and then diff it with your custom code to see if you need to update your custom worker code as well or not?

    Hope this helps.

    Thread Starter ivantrendafilov

    (@ivantrendafilov)

    Hello,

    First off, thank you for your response — it is very helpful.

    > But if you look at the code you will see how we are creating different cacheKey by attending a query string to the URL inside the worker which the user can’t see but to CF it will be treated as a different cacheKey

    That is a clever idea, I can just edit the worker to attach the request.cf headers I need as query strings, which will create unique cache keys for each location of interest. But this brings up another question — how does cache invalidation work? I.e., imagine some page is currently cached, but someone goes in and makes an update. Will the plugin be able to purge each individual cache key, varied on all the geolocations, for that page? Or does it simply wait X amount of time for the cache to automatically expire? Or does it do a purge all?

    Re: the somewhat counterintuitive idea of using CF geolocation headers instead of some API: better performance on a cache miss than any API and also allows us to serve the bulk of the requests from a geo-split html cache on LiteSpeed, instead of doing server-side PHP execution.

    Plugin Contributor iSaumya

    (@isaumya)

    how does cache invalidation work?

    – Great question. When using the custom worker like this you cannot just purge the HTML pages of your site. So, basically inside the plugin settings, under the cache tab:
    1. Under Automatically purge the Cloudflare's cache when something changes on the website section you need to unselect the related pages option and need to select purge whole cache: https://i.imgur.com/xiq3C1P.jpeg

    2. Also make sure that you have disabled the option to only purge HTML pages: https://i.imgur.com/CrfqMm3.jpeg

    the somewhat counterintuitive idea of using CF geolocation headers instead of some API: better performance on a cache miss than any API and also allows us to serve the bulk of the requests from a geo-split html cache on LiteSpeed, instead of doing server-side PHP execution.

    – Not a good idea cause when a page is not cached in CF CDN, it will reach to the origin server to be generated. But when a page is cached, that request will not even land on the origin server and fully handelled by CF. So, you won’t even get a chance to check anything.

    So, if you can code according to that then it’s fine. The idea is when someone from a specific location lands on a page, the worker will add user location in the cacheKey with a query string that users can’t see and as this request is served by the origin server, it will generate the respective content. Then next time anyone else comes from the same location CF will see that it’s already cached in it’s system and pass the content from it’s CDN.

    Thread Starter ivantrendafilov

    (@ivantrendafilov)

    Is it possible to add a hook into the “related pages” purge code, so that I can execute my own logic on what is considered a related page?

    Generally, for my use case, I’ll have 10k pages, cached 50 x 10k times (each page’s content varies depending on the US state of the visitor), so just to preload all of these into the CF cache is going to be difficult, if I have to purge everything on each update, then it’s not going be sustainable at all. On the other hand, if I can hook into that code and purge the cache keys that are basically URL + query param for each US state, then it becomes very reasonable and effective.

    I would imagine it would be useful for other people as well, if they end up modifying your default worker to include new params (e.g., like in that device detection gist example).

    Plugin Contributor iSaumya

    (@isaumya)

    Hi,
    There is already a filter named swcfpc_post_related_url_init where you can add a list of URLs that you would like to be part of the related pages so when you post new content or update existing content they gets updated. This is already mentioned in the FAQ tab inside the plugin settings: https://i.imgur.com/tYx6SVn.jpeg

    But considering the number of pages you have, purging the whole cache would be the best option and if you have high traffic site it will get cached again very soon. Otherwise, if you go onto purging all the permutations and combinations of all URLs even CF API will not allow you that many requests.
    Link: https://support.cloudflare.com/hc/en-us/articles/200171456-How-many-API-calls-can-I-make-

Viewing 5 replies - 1 through 5 (of 5 total)
  • The topic ‘Cache and geolocated content’ is closed to new replies.