4 ms·
One aspect that I think isn't common knowledge: You shouldn't use javascript libraries from CDNs. It's less secure, has less privacy and is slower than selfhost
by hannob 5y ago
One aspect that I think isn't common knowledge: You shouldn't use javascript libraries from CDNs. It's less secure, has less privacy and is slower than selfhosting.
Why is it less secure? You're adding an additional point of attack. Someone could compromise the CDN or they could stop operating and the domain will fall to someone else. (And it doesn't really matter if your CDNs security is better or worse than your own hosting security - if you use a CDN it adds security risk and does not take away the risk from whatever other hosting you're using.)
Why privacy? Your CDN can at the very least read the IPs of your visitors (+ they could add cookies, which will usually not happen but still is a possibility) and you may need to worry about legal issues (e.g. adding it to your GDPR statement).
Finally performance: I guess many people will use a CDN "because it's faster" - except it's not.
In the past there used to be the argument that the JS may already be cached. However that's no longer the case as for security reasons browsers partition the cache based on the origin.
It's always faster to fetch a resource over the same connection compared to opening up a new connection to a different host.
So: Don't fetch your JS from CDNs, just put it in your webspace and fetch it from there.
- SahAssar 5y agoOn performance it is also good to mention that these sort of cdns where mostly conceived before http2, so then you ran into the risk of filling your connection quota to the origin server. Nowadays with http2/http3 that is no longer a problem.
- xiwenc 5y agoWell said! Times has indeed changed. Today we have access to: - http2 - broadband internet - clients have large local caches/storage Privacy and security are gaining traction.
- jhgg 5y agoStill can't beat the speed of light...
- robin_reala 5y agoSure, but if that’s a problem you should be CDNing your entire site.
- dspillett 5y agoAlso reliability: by using a 3rd party service for important parts of your page/site/app for performance reasons is essentially RAID0 for web requests. You now have two (or more) points of failure (your infrastructure and the CDN) each of which can single-handedly break your stuff. And the break doesn't have to happen at the CDN, it could for instance be a failed DNS lookup, or an odd routing error at an ISP which affects the CDN but not your main location, a plugin such as noscript, or many other possibilities. Yes, there are methods that allow you to fall-back to your own local copy if the CDN copy fails to arrive, but that is adding further complication and could effectively slow down your page/app by getting in the way of some “make the initial render as early as possible” techniques. I never liked the idea of loading code from CDNs, or anything else for that matter, even when the benefits seemed more real than they do now. > Finally performance: … there used to be the argument that the JS may already be cached For larger CDNs with the resources to have many widely distributed points of presence there is a potential benefit that is still relevant even with partitioned caching: multi-view DNS or any-cast routing can result in a user's request being served from a topologically closer host than otherwise. Though I suspect that is you care that much about this small benefit you are probably running your own multi-homed infrastructure using the same technique(s) so CDNs aren't needed for you to benefit from them. And back to reliability: such methods further abstract away from the simple “make request, get response from expected host” arrangement and make diagnosing problems further down the line more difficult.
- heurisko 5y agoI don't think it's less secure to use a Javascript library from a CDN if you use https://www.srihash.org https://www.srihash.org. If the CDN server is compromised and the library edited then the resource no longer loads.