3 ms·

CDN, with local fallback: <script src="//ajax.aspnetcdn.com/ajax/jQuery/jquery-1.x.x.min.js" type="text/javascript"></script> <script type="text/javasc

CDN, with local fallback: <script src="//ajax.aspnetcdn.com/ajax/jQuery/jquery-1.x.x.min.js" type="text/javascript"></script> <script type="text/javascript"> window.jQuery || document.write(unescape('%3Cscript src="/scripts/jquery-1.x.x.min.js"%3E%3C/script%3E')) </script>

dos1 14y ago
Yeah, I know - but why bother? Just host the libs yourself and be done with it. Plus that way you can bundle them with your other scripts and save a request. Edit: To clarify - the reason I don't like the above solution is because if the CDN is slow to respond for some reason, you've just wasted a bunch of your user's time before loading your self hosted version.
- crescentfresh 14y ago
  > bundle them with your other scripts and save a request There's huge merit in that IMO for single-page type applications that have many lib dependencies. For content-based pages (dunno what to call them, whatever the opposite of single page apps are) the benefits stated by Google/others are more apparent with the CDN with local fallback approach.
  - dos1 14y ago
    I figure most content sites that are including jQuery are likely including some other third party libs. In the case of more than one external lib I think bundling makes sense and has a positive impact.
macca321 14y ago
This is what we had, but it wasn't responding quickly enough, so the site was hanging despite the fallback.
- crescentfresh 14y ago
  Yes I've found that too. Our single-page-style apps would do better to bundle all our dependencies together into a single request to our own servers. However say for content-based sites, the theoretical ideal is that the content should be delivered and usable without the inclusion of fooLib.js (which folks say should even be included as late as just before </body>), so a delay from a CDN would not necessarily cause any apparent "hang". Again this is the ideal and admittedly I've never got it right.
- k3n 14y ago
  You could probably wire something up in JS to handle it with reduced timeouts, e.g. an AJAX call that automatically fails after 50-100ms and proceeds to load the local version.
  - jQueryIsAwesome 14y ago
    A simpler solution would be to reload the page passing a parameter that you want to use other CDN; something like this: https://gist.github.com/4444636 https://gist.github.com/4444636
    - weego 14y ago
      You've now got people wondering why their page just reloaded after half a second and a slug of unnecessary javascript in your page all for the sake of simplicity. A simple solution would be to just link to a self-hosted version of the lib.
      - jQueryIsAwesome 14y ago
        False; because (if the script is inside the head of the page) the loading of Javascript is synchronous so the user will not notice any refresh at all.
jQueryIsAwesome 14y ago
Don't use unescape, is ugly and is not required if you break the close tag of "script". this.jQuery||document.write('<script src="js/jquery-1.8.3.min.js"></sc'+'ript>')
- crescentfresh 14y ago
  Yes, also document.write('\x3Cscript>\x3C/script>'). But these are beside the point.
  - jQueryIsAwesome 14y ago
    Well; I also think this is going offtopic but I have to mention "unescape" is not a JS standard but it is available in most JS engines; in the other hand literal Unicode codes in strings are part of the ES specification.
kyrra 14y ago
If you do overall page loading times, I wonder what sort of averages you will see comparing this to hosting it locally for all requests. When hosted locally it would result in 1 less DNS lookup, as well it could reuse an open HTTP connection to fetch the resource.
- crescentfresh 14y ago
  Correct on both counts. One con of hosting multiple dependencies locally could be that parallelization of downloads is reduced. There's always a flipside and each situation warrants analysis! So many of these discussion points are discussed at https://developers.google.com/speed/docs/best-practices/rtt https://developers.google.com/speed/docs/best-practices/rtt
- deelowe 14y ago
  I think for popular CDNs hosting popular libraries(google's jquery for example), the browser would use the local cache. So, I imagine there's a benefit to using a big CDN for those cases.

dos1 14y ago

Yeah, I know - but why bother? Just host the libs yourself and be done with it. Plus that way you can bundle them with your other scripts and save a request. Edit: To clarify - the reason I don't like the above solution is because if the CDN is slow to respond for some reason, you've just wasted a bunch of your user's time before loading your self hosted version.

crescentfresh 14y ago
> bundle them with your other scripts and save a request There's huge merit in that IMO for single-page type applications that have many lib dependencies. For content-based pages (dunno what to call them, whatever the opposite of single page apps are) the benefits stated by Google/others are more apparent with the CDN with local fallback approach.
- dos1 14y ago
  I figure most content sites that are including jQuery are likely including some other third party libs. In the case of more than one external lib I think bundling makes sense and has a positive impact.

macca321 14y ago

This is what we had, but it wasn't responding quickly enough, so the site was hanging despite the fallback.

crescentfresh 14y ago
Yes I've found that too. Our single-page-style apps would do better to bundle all our dependencies together into a single request to our own servers. However say for content-based sites, the theoretical ideal is that the content should be delivered and usable without the inclusion of fooLib.js (which folks say should even be included as late as just before </body>), so a delay from a CDN would not necessarily cause any apparent "hang". Again this is the ideal and admittedly I've never got it right.
k3n 14y ago
You could probably wire something up in JS to handle it with reduced timeouts, e.g. an AJAX call that automatically fails after 50-100ms and proceeds to load the local version.
- jQueryIsAwesome 14y ago
  A simpler solution would be to reload the page passing a parameter that you want to use other CDN; something like this: https://gist.github.com/4444636 https://gist.github.com/4444636
  - weego 14y ago
    You've now got people wondering why their page just reloaded after half a second and a slug of unnecessary javascript in your page all for the sake of simplicity. A simple solution would be to just link to a self-hosted version of the lib.
    - jQueryIsAwesome 14y ago
      False; because (if the script is inside the head of the page) the loading of Javascript is synchronous so the user will not notice any refresh at all.

jQueryIsAwesome 14y ago

Don't use unescape, is ugly and is not required if you break the close tag of "script". this.jQuery||document.write('<script src="js/jquery-1.8.3.min.js"></sc'+'ript>')

crescentfresh 14y ago
Yes, also document.write('\x3Cscript>\x3C/script>'). But these are beside the point.
- jQueryIsAwesome 14y ago
  Well; I also think this is going offtopic but I have to mention "unescape" is not a JS standard but it is available in most JS engines; in the other hand literal Unicode codes in strings are part of the ES specification.

kyrra 14y ago

If you do overall page loading times, I wonder what sort of averages you will see comparing this to hosting it locally for all requests. When hosted locally it would result in 1 less DNS lookup, as well it could reuse an open HTTP connection to fetch the resource.

crescentfresh 14y ago
Correct on both counts. One con of hosting multiple dependencies locally could be that parallelization of downloads is reduced. There's always a flipside and each situation warrants analysis! So many of these discussion points are discussed at https://developers.google.com/speed/docs/best-practices/rtt https://developers.google.com/speed/docs/best-practices/rtt
deelowe 14y ago
I think for popular CDNs hosting popular libraries(google's jquery for example), the browser would use the local cache. So, I imagine there's a benefit to using a big CDN for those cases.