3 ms·

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 fo

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.
    - Jach 13y ago
      CDNs are already an edge-case optimization, provided that unique visitors is less than number of visits.
untog 13y ago
it can take several seconds for the request to fail But if the client already has it cached it doesn't even make a request. CDNs have long expiries because the content of the JS lib will never change. There are many CDN's, many different versions of the many different libraries. But you're only using one. Especially on mobile devices, cache size is limited. All the more reason to use a CDN.
- lerouxb 13y ago
  The common case is that the user doesn't have the file yet and then has to do another dns lookup (for the cdn) and establish another http connection (to the cdn). There are so many public cdns now and so many versions of libraries scattered about that the chances that the user already has the resource cached is rather slim. Your build tool might as well have combined it all and sent the same "cache this forever" header. And in the common case that would have come from the same host as some other files, so one dns lookup, one http connection. I think public CDNs optimise an edge case for little benefit. But maybe it is clearer to me because I always have high latency where I live and my connection speed can be described as "medium" at best. I see sites only load some of their resources due to splitting files across CDNs on a daily basis. I can understand that if you have a sub-20ms ping time to your local CDN and a cable modem this might be difficult to understand. Making everything work or everything fail together is a lesson I've learned many times.

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.
  - Jach 13y ago
    CDNs are already an edge-case optimization, provided that unique visitors is less than number of visits.

untog 13y ago

it can take several seconds for the request to fail But if the client already has it cached it doesn't even make a request. CDNs have long expiries because the content of the JS lib will never change. There are many CDN's, many different versions of the many different libraries. But you're only using one. Especially on mobile devices, cache size is limited. All the more reason to use a CDN.

lerouxb 13y ago
The common case is that the user doesn't have the file yet and then has to do another dns lookup (for the cdn) and establish another http connection (to the cdn). There are so many public cdns now and so many versions of libraries scattered about that the chances that the user already has the resource cached is rather slim. Your build tool might as well have combined it all and sent the same "cache this forever" header. And in the common case that would have come from the same host as some other files, so one dns lookup, one http connection. I think public CDNs optimise an edge case for little benefit. But maybe it is clearer to me because I always have high latency where I live and my connection speed can be described as "medium" at best. I see sites only load some of their resources due to splitting files across CDNs on a daily basis. I can understand that if you have a sub-20ms ping time to your local CDN and a cable modem this might be difficult to understand. Making everything work or everything fail together is a lesson I've learned many times.