[arkitaip]

One of the benefits of using cdn resources is that it enables prototyping with, say, bootstrap so fast because you could essentially upload a single html file instead of a bunch of css, is,l and graphics. I mean, that will still be possible but there are more benefits to CDNs that just performance.

[ocdtrekkie]

But the cost of it is making your site which normally only depends on one server depend on several. That inherently lowers the reliability of your site.

I see no problem with using remotely hosted resources for prototyping. But you should never let a link to remotely hosted fonts or scripts make it into production code.

[wolco2]

In isolation 1 is better than two. But when each of those servers is on new equipment with expert techs getting an alert if things go down the risk gets reduced. Unless your support on the single server is on par multiple managed may be safer.

[TonyTrapp]

It doesn't help your website if your own server has issues while the CDN has the best experts ensuring its 99.999% uptime. The probability of a failure is still a multiplicative factor of both uptimes, so it's strictly worse. Your user won't care if the CDN serving JS files is up while the website itself is unreachable. The only uptime that is relevant is that of your own server.

Edit: Typo

[dragonwriter]

> It doesn't help your website if your own server has issues while the CDN has the best exports ensuring its 99.999% uptime.

That's certainly true of the server on which your APIs, if any, reside, but isn't it typical for your website itself to also leverage the CDN for distribution?

[ocdtrekkie]

Distributing your website on a CDN is fine, but then, all of your fonts and JS belong on that same CDN.

Basically, you should never have a production website which calls out to cdnjs.cloudflare.com or ajax.googleapis.com or fonts.googleapis.com, you should be hosting all of your site's dependencies in the same place or set of places.

As a side perk, your site also will stop looking like trash for users who use browser extensions to block such external calls. ;)

[dathinab]

But what if you also put you static content (e.g. blog-post) onto the CDN and as such your site is still operating to >50% of it's features when your sever is down. (Just missing comments, new posts, announcements etc. but not the main content).

[wolco2]

If you put 100% of the load on the local server you increase your chance of failure. Moving the bulk of the load to a cdn can reduce the load.

You are only as good as your local server. Having a cdn means you need a better local server.

[ocdtrekkie]

I would argue if you're shoving so much additional JavaScript on top of your website that you need a better server to host it, you are serving way too many scripts.

[kevincox]

Yup. Unless your site is so unreliable that it is likely to fail between serving the homepage and the assets the CDN will only hurt your availability.

[dathinab]

You are forgetting that under high load availability of local servers is likely to degrade and serving non small parts of you content via CDN can noticeable reduce the load and as such improving local availability potentially improving total availability.

[thomasfromcdnjs]

Yeah, I've said it here before but I created cdnjs.com 10 years ago or so.

I use webpack and other more secure/performant strategies for all my JS needs when working in a serious environment.

But when I am building something personal/light, I still load up cdnjs.com and drop something in. It's just easier than thinking about how I will serve files etc