4 ms·

So this is something I wrote last week relating how I've come to believe that it's really not appropriate to rely on vendor code on public CDN's for anything mo

So this is something I wrote last week relating how I've come to believe that it's really not appropriate to rely on vendor code on public CDN's for anything more complex than a JSFiddle. http://daemon.co.za/2014/03/from-trenches-js-cdn-point-of-failure http://daemon.co.za/2014/03/from-trenches-js-cdn-point-of-fa... Basically, if you need to include something like jquery, you have to have code that makes use of it. Since by definition, you can't serve that code from a public cdn, you are going to need to serve those static assets somehow. I now believe that you should serve the vendor code from the same 'place' as you serve your application's static assets, because by relying on external resources, you are adding more moving parts that all have to be in perfect working order for your app to actually be able to run. This doesn't really have anything to do with how reliable the CDN itself is, but rather with how reliable the client's connection is. I did read the jsdelivr post, and it actually looks like a really well thought out system. I just don't think I will use something like this for anything where I have the choice not to. IMO, the possible benefits of using a public CDN, don't outweigh the fragility that gets added. It just feels like it is trying to optimize best case performance while worst case is far more important. I'm not against CDN's as a concept though, I just think you should serve all the code that is needed for normal operation from the same one.

untog 13y ago
It's very easy to add a fallback, though. If the CDN goes down, load the local version. > This doesn't really have anything to do with how reliable the CDN itself is, but rather with how reliable the client's connection is. If they have the CDNed version of jQuery cached then it doesn't need their connection to do anything.
- AdrianRossouw 13y ago
  you could just have loaded the local file the first time and have it work every time, without all those ifs and maybes involved. it can take several seconds for the request to fail, during which your application won't have been loaded or working. the fallback adds complexity to your code, which ultimately didn't need to be there. I just think that it's better to reduce the ways that your application can break, before trying to make it a little bit faster for the cases in which all the conditions are met. On principle, even in the theoretical best case scenario, I think it's not the right approach to be taking. I also don't think that the best case scenario can be reliably enough predicted to be something you should try to optimize for. There are many CDN's, many different versions of the many different libraries. Especially on mobile devices, cache size is limited. IMO, at least.
  - oinksoft 13y ago
    You're overthinking this. There are benefits to using a CDN beyond caching; you exaggerate the risk of the CDN going down, and the effort it takes to create a fallback for that. For most applications, a widely-used (cached) free CDN is a no-brainer and is nice to your end users.
    - AdrianRossouw 13y ago
      not the CDN going down. the client being unable to reach the CDN. the http request the cdn to get the file is not a 'free' operation. network timeouts take time.
      - oinksoft 13y ago
        I mean the CDN going down from the end user's point of view. Why the host is unreachable is a moot point.
        lerouxb 13y ago
        I see this daily, but then I don't have a sub-20ms ping time and a cable modem where I live. The CDN doesn't have to go down. The user's connection doesn't even have to go down. Things just have to get momentarily flaky _somewhere_. I'm working on a project that uses google fonts and the page loads with fonts timing out multiple times per day. I get to sites where just the html loads and none of the css (or worse: just some of the css) all the time. Especially on 3G, but regularly on ADSL too. Or what if you're sharing a saturated line? (And waiting for a timeout to kick in before you trigger a callback is just not an option. By then the user probably closed the page anyway. Rather just make it work in the first place.)
      - xtreme 13y ago
        You should optimize the common path, not the edge cases. Most of the time the user would be benefited (cached content = faster load) from using CDN. On the other hand, CDN being unreachable is not a very common scenario, so it is acceptable to be a little slower.
moystard 13y ago
I think your statement is a bit extreme. While relying exclusively on a cdn to serve your static assets is risky, doing it using require.js with a local fallback works very well. You still benefit from cdn caching, while preventing your assets to become unavailable (even in China).
- AdrianRossouw 13y ago
  that's just added complexity, where it could all just work. or fail consistently at the same time if your server isn't accessible. In that case it doesn't matter that the public cdn is still accessible. i just don't think the possible benefit of public cdn hosted code can justify how many moving parts it adds.
  - moystard 13y ago
    It does not add complexity if your project already makes use of require.js, it is literally specifying an array of paths for a library instead of a simple string. If my server is not available, my web application will ultimately fail anyway.
    - AdrianRossouw 13y ago
      if you are worried enough about performance to start using external resources in this way, you are probably going to benefit much more by using r.js and a build step to build a single (or a few partitioned) javascript files. https://developers.google.com/speed/docs/best-practices/rtt#CombineExternalJS https://developers.google.com/speed/docs/best-practices/rtt#...
      - moystard 13y ago
        We do use r.js and create modules (a main one that gets download systematically, and smaller ones for less used features). However as we update often, we don't want our users to download the large third party libraries we use at each occurence, so having them as separate downloads is actually much better. For the large libraries we use that are hosted on a cdn, with a local fallback, we use the :empty value for the optimiser and they are exclude from our modules.
deleted 13y ago
[deleted]
elwell 13y ago
If you spread your resources over multiple domain names, the client can download more files in parallel.
- AdrianRossouw 13y ago
  you can shard your own domains too.
- AdrianRossouw 13y ago
  https://developers.google.com/speed/docs/best-practices/rtt#ParallelizeDownloads https://developers.google.com/speed/docs/best-practices/rtt#...

untog 13y ago

It's very easy to add a fallback, though. If the CDN goes down, load the local version. > This doesn't really have anything to do with how reliable the CDN itself is, but rather with how reliable the client's connection is. If they have the CDNed version of jQuery cached then it doesn't need their connection to do anything.

AdrianRossouw 13y ago
you could just have loaded the local file the first time and have it work every time, without all those ifs and maybes involved. it can take several seconds for the request to fail, during which your application won't have been loaded or working. the fallback adds complexity to your code, which ultimately didn't need to be there. I just think that it's better to reduce the ways that your application can break, before trying to make it a little bit faster for the cases in which all the conditions are met. On principle, even in the theoretical best case scenario, I think it's not the right approach to be taking. I also don't think that the best case scenario can be reliably enough predicted to be something you should try to optimize for. There are many CDN's, many different versions of the many different libraries. Especially on mobile devices, cache size is limited. IMO, at least.
- oinksoft 13y ago
  You're overthinking this. There are benefits to using a CDN beyond caching; you exaggerate the risk of the CDN going down, and the effort it takes to create a fallback for that. For most applications, a widely-used (cached) free CDN is a no-brainer and is nice to your end users.
  - AdrianRossouw 13y ago
    not the CDN going down. the client being unable to reach the CDN. the http request the cdn to get the file is not a 'free' operation. network timeouts take time.
    - oinksoft 13y ago
      I mean the CDN going down from the end user's point of view. Why the host is unreachable is a moot point.
      - lerouxb 13y ago
        I see this daily, but then I don't have a sub-20ms ping time and a cable modem where I live. The CDN doesn't have to go down. The user's connection doesn't even have to go down. Things just have to get momentarily flaky _somewhere_. I'm working on a project that uses google fonts and the page loads with fonts timing out multiple times per day. I get to sites where just the html loads and none of the css (or worse: just some of the css) all the time. Especially on 3G, but regularly on ADSL too. Or what if you're sharing a saturated line? (And waiting for a timeout to kick in before you trigger a callback is just not an option. By then the user probably closed the page anyway. Rather just make it work in the first place.)
    - xtreme 13y ago
      You should optimize the common path, not the edge cases. Most of the time the user would be benefited (cached content = faster load) from using CDN. On the other hand, CDN being unreachable is not a very common scenario, so it is acceptable to be a little slower.

moystard 13y ago

I think your statement is a bit extreme. While relying exclusively on a cdn to serve your static assets is risky, doing it using require.js with a local fallback works very well. You still benefit from cdn caching, while preventing your assets to become unavailable (even in China).

AdrianRossouw 13y ago
that's just added complexity, where it could all just work. or fail consistently at the same time if your server isn't accessible. In that case it doesn't matter that the public cdn is still accessible. i just don't think the possible benefit of public cdn hosted code can justify how many moving parts it adds.
- moystard 13y ago
  It does not add complexity if your project already makes use of require.js, it is literally specifying an array of paths for a library instead of a simple string. If my server is not available, my web application will ultimately fail anyway.
  - AdrianRossouw 13y ago
    if you are worried enough about performance to start using external resources in this way, you are probably going to benefit much more by using r.js and a build step to build a single (or a few partitioned) javascript files. https://developers.google.com/speed/docs/best-practices/rtt#CombineExternalJS https://developers.google.com/speed/docs/best-practices/rtt#...
    - moystard 13y ago
      We do use r.js and create modules (a main one that gets download systematically, and smaller ones for less used features). However as we update often, we don't want our users to download the large third party libraries we use at each occurence, so having them as separate downloads is actually much better. For the large libraries we use that are hosted on a cdn, with a local fallback, we use the :empty value for the optimiser and they are exclude from our modules.

deleted 13y ago

[deleted]

elwell 13y ago

If you spread your resources over multiple domain names, the client can download more files in parallel.

AdrianRossouw 13y ago
you can shard your own domains too.
AdrianRossouw 13y ago
https://developers.google.com/speed/docs/best-practices/rtt#ParallelizeDownloads https://developers.google.com/speed/docs/best-practices/rtt#...