undefined | Better HN

0 pointsalzoid1y ago0 comments

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.

0 comments

afavour1y ago

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

alzoidOP1y ago

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.

afavour1y ago

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

1 more reply

Macha1y ago

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?

alzoidOP1y ago

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.

Macha1y ago

> 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.

madeofpalk1y ago

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

j / k navigate · click thread line to collapse

0 comments

afavour1y ago

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

alzoidOP1y ago

afavour1y ago

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

1 more reply

Macha1y ago

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.

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

alzoidOP1y ago

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.

Macha1y ago

> 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.

madeofpalk1y ago

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

j / k navigate · click thread line to collapse