Plugin Author
shift8
(@shift8)
Hello!
We are setting an expires tag as well as cache-control headers for a 1 year expiration. Where a pull will happen is if the query string changes for the requeted file (i.e. style.css?ver=1.0 versus style.css?ver=1.1).
Thats interesting about the 1 day re-pull. Just to clarify you were hitting the same endpoint each time you tested? Its possible you hit another endpoint , but if you were testing from the asia endpoint each time then I can attempt to look into this further.
There may be other factors that caused the cache to refresh but I would want to run some tests to see – is this for every static asset (images, css, js) , or is this for just some? If you could send an email to [email protected] withe the site url , I can look further also.
Hi there,
Thanks for getting back so quickly, didn’t noticed you replied as I got no notification despite opting for it.
Just to clarify you were hitting the same endpoint each time you tested?
Anyway, yes I tested from the same origin endpoint in asia SG everytime. It’s being pulled by the CDN in OVH SG. I checked from both Chrome dev with cache disabled and curl head.
is this for every static asset (images, css, js) , or is this for just some?
From what I noticed, it’s happening for every static assets. Below is one of such:
https://iplw1glkkmpj.wpcdn.shift8cdn.com/wp-content/uploads/2016/01/WDMyCloud4TB-qBittorrent-150×58.png
There may be other factors that caused the cache to refresh
I’m aware about the query string changes but would love to know more about the other factors. Also would it cache both with and without query string? Thank you.
Plugin Author
shift8
(@shift8)
Hello,
Thank you for your added information and assistance with understanding your issue.
There are certain behaviours and practices that will be happening behind the scenes to optimize the process of the CDN. Some of these are best practices , for example :
If an asset is cached in the CDN, there is a time window it will stay held in the cache. If nobody accesses it at all within the window of time, it will naturally expire. This is intended to optimize the network so that we aren’t holding assets that nobody is accessing.
What this really means is the busier your site is, the longer (or permanently) the assets will stay held in the cache. If during after hours, someone doesn’t access an asset for more than an hour (the way the CDN is configured now), it will naturally expire and go stale.
I have facilitated the increase of this behaviour time window to be a bit more generous. Please understand, especially for a free CDN, we have to take these types of precautions to ensure that we dont overload the network. Also understand that this behaviour for a caching system is actually by design and a best practice (so its not just us).
That said , I would consider improving this even further for paid users. Again the default time window has increased from 60 minutes (if nobody accesses an asset at all, it expires), to 180 minutes, for free plan users.
Does this make sense? I think this may be what you were seeing. I dont think the expires was happening in a day but was likely just the content going stale. I would be willing to investigate further if you have other suggestions, of course.
Hello thanks again for replying.
Ok I understood but doesn’t this impact the CDN network bandwidth by doing double job again and again in a short period? That is pulling again from origin then serve to the endpoint repeatedly every few hours. Retaining them longer on the edge may save the bandwidth at the slight cost of storage. IIRC one of the other free CDN provider kept it for few days hence I was puzzled why I was getting many misses in a short period with Shift8 but you already given the explanation.
Anyway thank you for providing this great service.
Plugin Author
shift8
(@shift8)
I’ll continue looking into this – I appreciate your understanding. You are correct in your assessment, it would be much more efficient to keep the asset longer.
Plugin Author
shift8
(@shift8)
I’m closing this issue as its more of a feature change at this point. I will continue to investigate this and roll it out any necessary improvements in a future update.