[alzoid]

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.

[afavour]

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

[alzoid]

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.

[Macha]

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?

[alzoid]

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.

[madeofpalk]

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