undefined | Better HN

0 pointswil4218y ago0 comments

One reason is that by linking to external libraries your browser most likely has them cached. At least it was the case a few years ago when I was doing web dev.

0 comments

10 comments · 2 top-level

eric_b8y ago· 8 in thread

I see this argument a lot but I don't think it's necessarily a good one. If a third party CDN goes down, your site is down.

A few extra ms in initial download isn't so bad compared to having your site be completely inaccessible for reasons outside your control.

matthberg8y ago

When a CDN goes down, that is the time to use local backups. The best policy I've seen is using 3rd party CDNs for scripts like jQuery, ie. common, unchanging resources, yet with subresource integrity checks [0] to make sure it's actually what you are asking for (in case the site somehow gets compromised or returns an error). On top of that to cover for failure, you have a fallback locally hosted copy which is loaded only if the CDN version fails.

[0] https://developer.mozilla.org/en-US/docs/Web/Security/Subres...

wil421OP8y ago

Would those resource checks been done at the client or sever? For example the sever pings the CDN at a set interval and if it's down the sites code is modified to included links to local copies.

Or would you do something in the browser to fetch the local one in case of failure?

omni8y ago

Why doesn't having the resources cached provide a buffer against short-term outages of the CDN?

hobofan8y ago

Because normal Cache-Control is only aimed at reducing the amount of data transferred. With newer immutable Cache-Control[0], a CDN going down wouldn't have an effect if you have the resources cached.

[0]: https://hacks.mozilla.org/2017/01/using-immutable-caching-to...

nleach8y ago

The browser still has to make a request to the CDN to get back an HTTP 304. The goal is to avoid downloading a potentially large payload, not be resilient against connectivity issues.

wil421OP8y ago

Self hosting will probably cause more downtime than if you are using a decent CDN. CDN is just one of many points of failure, I would expect there's a fine balancing act where you could achieve benefits of both.

dom08y ago

By definition, if your site is down, you don't need your assets.

1 more reply

jlgaddis8y ago

Then why are these sites down?

Asmod4n8y ago

This is most likely never the case, because there are way too many versions of each library.

j / k navigate · click thread line to collapse

0 comments

10 comments · 2 top-level

eric_b8y ago· 8 in thread

I see this argument a lot but I don't think it's necessarily a good one. If a third party CDN goes down, your site is down.

A few extra ms in initial download isn't so bad compared to having your site be completely inaccessible for reasons outside your control.

matthberg8y ago

[0] https://developer.mozilla.org/en-US/docs/Web/Security/Subres...

wil421OP8y ago

Would those resource checks been done at the client or sever? For example the sever pings the CDN at a set interval and if it's down the sites code is modified to included links to local copies.

Or would you do something in the browser to fetch the local one in case of failure?

omni8y ago

Why doesn't having the resources cached provide a buffer against short-term outages of the CDN?

hobofan8y ago

[0]: https://hacks.mozilla.org/2017/01/using-immutable-caching-to...

nleach8y ago

The browser still has to make a request to the CDN to get back an HTTP 304. The goal is to avoid downloading a potentially large payload, not be resilient against connectivity issues.

wil421OP8y ago

dom08y ago

By definition, if your site is down, you don't need your assets.

1 more reply

jlgaddis8y ago

Then why are these sites down?

Asmod4n8y ago

This is most likely never the case, because there are way too many versions of each library.

j / k navigate · click thread line to collapse