5 ms·

I invite everyone affected to consider switching to a production focused CDN https://www.jsdelivr.com/ https://www.jsdelivr.com/ There is also a tool to simpli

by jimaek 2y ago

I invite everyone affected to consider switching to a production focused CDN https://www.jsdelivr.com/ https://www.jsdelivr.com/ There is also a tool to simplify migration https://www.jsdelivr.com/unpkg https://www.jsdelivr.com/unpkg

account42 2y ago
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.
- arkh 2y ago
  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.
- alzoid 2y ago
  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 2y ago
    Or you could simplify the whole thing and just host it yourself. It isn’t worth that level of complication.
    - alzoid 2y 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.
      - afavour 2y 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.
        alzoid 2y ago
        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.
        afavour 2y ago
        > 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.
  - Macha 2y 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?
    - alzoid 2y 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.
      - Macha 2y 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.
  - madeofpalk 2y ago
    What does that actually mean? How do you check if a JS library exists on the client?
madeofpalk 2y ago
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.

by jimaek 2y ago

account42 2y ago

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.

arkh 2y ago
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.
alzoid 2y ago
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 2y ago
  Or you could simplify the whole thing and just host it yourself. It isn’t worth that level of complication.
  - alzoid 2y 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.
    - afavour 2y 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.
      - alzoid 2y ago
        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.
        afavour 2y ago
        > 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.
- Macha 2y 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?
  - alzoid 2y 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.
    - Macha 2y 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.
- madeofpalk 2y ago
  What does that actually mean? How do you check if a JS library exists on the client?

madeofpalk 2y ago

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.