![]() This means, only a portion of a sites users are effected. If a CDN is down, its likely that the outages are localised to specific regions, otherwise it wouldn't be a very good CDN. If something is self hosted and parts of your services service become inaccessible, then either your entire site is down or the experience is degraded. This is a problem whether using CDNs or not. It's not really an argument against the use of CDNs but rather a suggestion that there are best practices for development and user experience. This is an obvious design consideration choice when selecting current version vs explicit version. It doesn't really matter the ratio, as long as it is greater than 1. >1:1 for CDN/version combo vs 1:1 for self hosted. There's more of a chance of having already downloading a CDN/version combo than there is if every site hosted the content themselves. I just wanted to give some counterpoints to some of your arguments: Nowadays, in an era of rampant privacy and security violations, I think using 3rd party sources for Javascript should be treated as an anti-pattern. And I'm certainly guilty of misusing CDNs like this.īack when there were only a few CDNs, and their libraries didn't change rapidly, there was an advantage to using them. Of course, that means that you could end up with a broken experience on your site. If even a single byte of that JS file is changed, the hash won't match and the browser should refuse to run the code. You gain extra security by using SubResource Integrity. A malicious user changed the code on site which wasn't in BA's control - then BA served it up to its customers. What is your CDN doing with all that data? Securityīritish Airways' payments page was hacked by compromised 3rd party Javascript. What's your CDN's privacy policy? Do you need to tell your user that their browsing data are being sent to a shadowy corporation in a different legal jurisdiction? If you serve your JS from the same source as your main site, there is less chance of a user getting a broken experience. That isn't necessarily a bad thing - you do progressive enhancement, right? But it isn't ideal. Is your CDN reliable? You hope so! But if a user's network blocks a CDN or interrupts the download, you're now serving your site without Javascript. And, of course, if you're using v1.2 and another site is using v1.2.1 the browser can't take advantage of cacheing. So most people only include a specific version of the JS they want. But then you have to deal with breaking changes with little warning. There are some CDN's which let you include the latest version of a library. But if you are truly worried about speed, surely your whole site should be behind a CDN - not just a few JS libraries? Versioning Have some respect for your users' download limits. You probably shouldn't be using multi-megabyte libraries. ![]() How much of an advantage does that really give you? Speed ![]() What are the chances that your user has visited a site which uses the exact same CDN as your site? But there are dozens of popular Javascript CDNs available. I think these advantages are overstated and lead to some significant disadvantages.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |