Hacker News Reader

Comment by jimaek | Hacker News Reader

I invite everyone affected to consider switching to a production focused CDN https://www.jsdelivr.com/

There is also a tool to simplify migration https://www.jsdelivr.com/unpkg

I invite everyone (even those not affected in this instance) to consider switching away from relying on random third parties for your hosting. Like wtf how is did this ever become the norm even when there was a slight performance advantage from a shared cache, which doesn't even exist anymore these days.

I do both. If you are loading a JS lib then check for its existence on the client. If it's not found load the resource from your server. You could also achieve this on the server side.

Or you could simplify the whole thing and just host it yourself. It isn’t worth that level of complication.

In this situation server bandwidth was an issue. Using an available CDN with the fall back was what we decided to do. It's not that complicated, from the client check if the object you expect to exist in the library exists, if not load it from your server.

I’m curious, in what scenario was bandwidth for static resources an issue? It’s one of the most trivial things to serve cheaply.

When the server is behind a pipe of limited size. When most of your new visits happen all at once over a short period of time. When you can't rely on a mobile phones cache like a desktop because 90% of your visitors are using one. A CDN is a easy win to off load resources, even if they are small.

> A CDN is an easy win to off load resources, even if they are small.

Yes and setting up your own CDN config (Cloudfront, whatever) is minutes of work and brings all of the benefits you’ve outlined. And costs pennies.

1. You realise caches, even for third party assets are partitioned by host domain in most modern browsers now? So you're not getting a benefit that users loaded the script from someone else's site.

2. For saving bandwidth on the server are you using proper cache setup with etags and If-Modified-Since support? It shouldn't have to download a first party asset again if it's in the cache. It's worth pointing out that non-ancient versions of all major web servers do this by default.

3. Haven't you now added latency by first making users download the loader script, have that execute, and then start loading the dependencies?

1) Yes, the other benefit at the time was a browser would only do X number of requests per domain, using the CDN allowed more requests. Also it was a bandwidth issue from the server.

2) Yes. I should also mention at the time mobile browser cache was not consistent/reliable.

3) The "loader script" is a basic if(!lib.func) { do the magic }. Its one extra thing I suppose. For the overall page load there are lower hanging fruit.

> The "loader script" is a basic if(!lib.func) { do the magic }. Its one extra thing I suppose. For the overall page load there are lower hanging fruit.

That's still a 100-200ms if the user is not on the same continent as your server.

What does that actually mean? How do you check if a JS library exists on the client?

A very specific problem with third party hosts : if you use noscript and only allow main domain script as a default, you have to either whitelist those CDN or authorize them on every site using it. Not the best experience. Especially with some sites having dozens of third party scripts so instead of trying to find the right one(s) to authorize you just close the tab and forget about it.

Why? If you care about being even remotely reliable (hinted at with "production-focused"), why would you do this? Just use the same host as where you serve everything else from.

Browsers have partitioned caches per origin for over 10 years, so there's no performance gains from getting cache hits from other websites.

Reply on news.ycombinator.com