Not all content can be cached,that's where optimal routing to origin provides the most benefit...for instance if you're serving pages with PII after the user logs in, you can't cache that on a CDN (you can do browser based private caching though).
I think for popular CDNs hosting popular libraries(google's jquery for example), the browser would use the local cache. So, I imagine there's a benefit to using a big CDN for those cases.
Uhh, what caching advantage are you talking about? Everything that can be served cached over HTTP can also be served cached over HTTPS. Unless you are talking about a caching proxy outside of the website control. In that case, they aren't needed, CDNs solved that problem in a much better way.
Doesn't that kill the possibility that a visitor will already have common content cached when visiting your site for the first time? I know that's not the only reason to use a CDN, but it's a pretty big one.
I think that depends on user. Some use CDNs to improve performance via already cached files, others to offload traffic and use the actual CDN performance from Geo balancing.
Personally I don't think a user will have anything cached other than jQuery from Google. Which in this case I removed to follow the rule of eating own dogfood.
You're overthinking this. There are benefits to using a CDN beyond caching; you exaggerate the risk of the CDN going down, and the effort it takes to create a fallback for that. For most applications, a widely-used (cached) free CDN is a no-brainer and is nice to your end users.
I don't get the point the first point about caching. Only the very first user of a specific website in a specific region sees a slow download from the origin server, every other user of that website in the same region gets the cached files from the CDN node. No matter how and when a file got onto a CDN node first, the vast majority of users will benefit from caching (it doesn't matter whether it's a "popular" JS library, or any other file that's only used by your website).
1) What does a CDN have to do with the simple real-world fact that content gets duplicated around sites all the time, particularly stupid crap like funny picture memes? A good global hash of this would certainly help optimize web-caching.
2) A well designed app will hopefully not have every page rendered dynamically at the server anymore, but just have an api to send data back to the page for rendering client side. This benefits from content caching (provided the content is big enough to benefit from caching rather than retransmission).
3. Using something like varnish in front of your site will allow you to dynamically invalidate the hash when needed, and in the interim, a generated result to a url is no different than a static one.
But you can cache other things that are not the entire page itself:
- database queries
- user sessions
- api calls
- page fragment
- function memoization
What's more, cache backends have the ability to expire things, which can be helpful for all sort of stuff.
reply