I don’t think so? It just seems like all the kids are using CDNs these days, and some of my developer friends who have a tendency to over-architect things seem to swear by them.
I agree with the CDN comment. Please use a CDN to serve your assets no mater what you host on. It's so easy, and the performance gains to the end user are good, it should be an obvious choice.
Could someone explain me as someone relatively clueless in web matters. I've heard an opinion recently that CDNs are not useful any more. Why would that be the case?
I don't buy that, at least not in the general case. A CDN adds an additional indirection between the site you serve and the content that you reference on the CDN.
Third-party CDN usage like this isn’t a best parctice generally if it can be avoided because it involves users need to trust more parties and leaks user data to those sources. With the advent of assets being isolated a couple of years ago, there's no performance/chaching benefit to it anymore either.
True, was also considering this. Just thought having a CDN would be useful at some points (e.g. to compress/resize images, generate source sets of images automatically)
1) You don't pay for the bandwidth (in some cases)
2) If enough resources on the web request it, the client may have it cached locally already, causing faster load times.
3) If you request a lot of resources, you get more threading because the amount of simultaneous request to the same host is limited for most platforms (applicable when the source is not cached), but using HTTP/2 negates this issue as well.
4) Based on your location, the CDN can serve the content from a datacenter closest to the end-user (not all CDN's have this feature), resulting in faster transfers as well.
The question remains if this is worth it. For some stuff, it is (think Google Fonts for example), for most, you get version fragmentation, which makes the odds of someone having it cached a lot lower. Add all the other things that can go wrong, and using a CDN stops making sense in a lot of cases.
Good. Another reason not to use these CDNs is they're additional risk and introduce the potential for downtime and breakage. It's an additional point of failure that just doesn't come with many benefits.
I'll happily use these services for quick POCs and throwaway demos, but once anything starts to become semi-permanent I'll make sure I control my uptime and host these assets myself.
I'm not really sure what you mean, but absolutely using a CDN product is the way to go when you want to sell your content on a global scale. Otherwise, you are going to deal with having to build / maintain your own and the cost of doing that is far higher than just letting other experts deal with the issues that surround it.
Every site that needs a CDN probably already has one, because it's a quick win. For every site that doesn't need one (small user base, small asset size, etc) it's likely not worth the added complexity.
From the performance point of view is better to use that public CDN. But they have control over the javascript, and they may change it at anytime. Maybe too paranoid, so just thinking about it.
So like a P2P CDN. Big deal. A CDN like Amazon's is cheap and efficient. For web applications, e.g. dynamic content, a CDN isn't helpful, and neither will this system be. I don't see this as revolutionary.
reply