Hacker News new | ask | show | jobs
by crescentfresh 4915 days ago
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>
4 comments

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.

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

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.
This is what we had, but it wasn't responding quickly enough, so the site was hanging despite the fallback.
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.

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.
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
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.

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.
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.

> 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.

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.
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>')
Yes, also document.write('\x3Cscript>\x3C/script>'). But these are beside the point.
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.