3 ms·
That sounds like an interesting approach. We push out breaking changes to our server and client libraries several times a week. Since we invalidate our CDN on e
by vikrum 14y ago
That sounds like an interesting approach. We push out breaking changes to our server and client libraries several times a week. Since we invalidate our CDN on each deploy and set headers indicate as such, we can quickly and seamlessly migrate our end users without having them modify their <script> include.
At present, our library is unlike other mature javascript libraries that can make use of a very high cache timeout. How would the 1yr cache timeout work for the library that is changing several times a week?
- bryanh 14y agoI think he might be referring to a 1yr cache timeout on things like the logo.
- moonboots 14y agoSteve Souders blogged about how to serve scripts with far future expires without updating the client's script tag [1]. This technique initially loads the (potentially stale) js from the client's cache and checks for updates in the background, updating the client's cache if a new version is detected. [1] http://www.stevesouders.com/blog/2012/05/22/self-updating-scripts/ http://www.stevesouders.com/blog/2012/05/22/self-updating-sc...
- jconley 14y agoYes, this is a great approach for javascript code. Usually, like in this case, there is something that will be faster than a round trip to check for if-modified-since or the ETag, which I would assume is used to do the invalidation in this case. Of course, YMMV, and if fastly is close enough to the edge and there aren't very many requests, this kind of optimization won't be required. There might also be an opportunity to modify what is served from the customer's sites, depending on how all that is architected.