- Decreased latency: Chances are high that a CDN server is closer to a user than your own server. Thus: faster delivery.
- Increased parallelism: Some browsers impose per-host limits on the number of connections. If your JavaScript libraries come from a different server, more of your own content can be loaded in parallel.
- Better caching: If several sites use the same CDN, a copy of your library might already be cached in a user’s browser.
- Naturally, a reason against it is that it does not always work when you work offline, with file URLs. If that matters, you can dynamically load your libraries and switch to locally stored versions if the URL protocol is file.
- The post suggests to use protocol-relative URLs if you want your site to work both with HTTP and HTTPS. This breaks down if you are using file URLs to test your site (as the CDNs cannot be reached via that protocol).
- The CDN approach is also useful if you just want to quickly try out a small example, without downloading a library.
- Privacy is an issue. If you use Google’s libraries, they will be able to track who comes to your website and from where. [Source: comment from Wesley P]
Be careful about what code you link to! Only do it if the owner of a site expressly allows it; this can cost them a lot of money.
2 comments:
Hi Axel Rauschmayer , thanks for the shoutout (I'm one of the founders for cdnjs).
In regards to the Microsoft CDN name change, it seems like the main reason it was changed was to avoid the overhead of unnecessary cookies: http://www.asp.net/ajaxlibrary/cdn.ashx#ajaxmicrosoftcom_renamed_to_ajaxaspnetcdncom_8
Ah, interesting. Thanks for the pointer!
Post a Comment