Title: Cache length
Last modified: April 27, 2020

---

# Cache length

 *  Resolved [Nazar78](https://wordpress.org/support/users/nazar78/)
 * (@nazar78)
 * [6 years, 1 month ago](https://wordpress.org/support/topic/cache-length/)
 * Hello,
 * Can I know how long is the cache on the CDN? Does it honor the origin cache headers?
   Take example the header below, first request I got a miss which is normal, 2nd
   request minutes apart I got a hit which is also normal. But the next day I got
   a miss again requesting from the same location in Asia. I noticed in my server
   logs the CDN is doing origin pull again for all static contents the next day.
   This daily origin pull seems to slow down the process instead of speeding up 
   the site. I’ve also tried removing the etag, same occurrence. Could you help 
   to advise? Thank you!
 *     ```
       HTTP/1.1 200 OK
       Date: Mon, 27 Apr 2020 12:35:47 GMT
       Content-Type: image/png
       Content-Length: 12558
       Connection: keep-alive
       Last-Modified: Tue, 16 Feb 2016 20:25:36 GMT
       ETag: "56c385c0-310e"
       Content-Encoding: gzip
       Expires: Tue, 27 Apr 2021 12:35:47 GMT
       Cache-Control: max-age=31536000
       Server: Shift8_CDN
       Access-Control-Allow-Origin: http://xxxxxxxxx
       X-Shift8CDN-Cache: MISS
       Pragma: public
       Cache-Control: public
       ```
   

Viewing 6 replies - 1 through 6 (of 6 total)

 *  Plugin Author [shift8](https://wordpress.org/support/users/shift8/)
 * (@shift8)
 * [6 years, 1 month ago](https://wordpress.org/support/topic/cache-length/#post-12738657)
 * 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 [cdnhelp@shift8web.com](https://wordpress.org/support/topic/cache-length/cdnhelp@shift8web.com?output_format=md)
   withe the site url , I can look further also.
 *  Thread Starter [Nazar78](https://wordpress.org/support/users/nazar78/)
 * (@nazar78)
 * [6 years, 1 month ago](https://wordpress.org/support/topic/cache-length/#post-12750744)
 * 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](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](https://wordpress.org/support/users/shift8/)
 * (@shift8)
 * [6 years, 1 month ago](https://wordpress.org/support/topic/cache-length/#post-12760570)
 * 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.
 *  Thread Starter [Nazar78](https://wordpress.org/support/users/nazar78/)
 * (@nazar78)
 * [6 years, 1 month ago](https://wordpress.org/support/topic/cache-length/#post-12791102)
 * 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](https://wordpress.org/support/users/shift8/)
 * (@shift8)
 * [6 years, 1 month ago](https://wordpress.org/support/topic/cache-length/#post-12791117)
 * 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](https://wordpress.org/support/users/shift8/)
 * (@shift8)
 * [6 years ago](https://wordpress.org/support/topic/cache-length/#post-12811103)
 * 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.

Viewing 6 replies - 1 through 6 (of 6 total)

The topic ‘Cache length’ is closed to new replies.

 * ![](https://ps.w.org/shift8-cdn/assets/icon-256x256.png?rev=3343767)
 * [Shift8 CDN](https://wordpress.org/plugins/shift8-cdn/)
 * [Frequently Asked Questions](https://wordpress.org/plugins/shift8-cdn/#faq)
 * [Support Threads](https://wordpress.org/support/plugin/shift8-cdn/)
 * [Active Topics](https://wordpress.org/support/plugin/shift8-cdn/active/)
 * [Unresolved Topics](https://wordpress.org/support/plugin/shift8-cdn/unresolved/)
 * [Reviews](https://wordpress.org/support/plugin/shift8-cdn/reviews/)

 * 6 replies
 * 2 participants
 * Last reply from: [shift8](https://wordpress.org/support/users/shift8/)
 * Last activity: [6 years ago](https://wordpress.org/support/topic/cache-length/#post-12811103)
 * Status: resolved