Skip to content

Loading…

Remove Google CDN reference for jQuery #1327

Closed
wants to merge 1 commit into from
@localpcguy

http://statichtml.com/2011/google-ajax-libraries-caching.html

According to that, there is a very little benefit to using the
Google CDN to serve jQuery source. A better option would be to
encourage devs to minify and concatenate all of their script files
into one JS file served with a long-lived cache time.

This was referenced by Alex Sexton (@SlexAxton) in his talk at
jQueryTO March 2nd, 2013.

@localpcguy

Saw this was brought up once before but with different reasoning, seemed better to open a new issue rather than append to the older one. There may be other reasons to choose to use the CDN, but if it is strictly because it is considered better performance this article seems to indicate that won't be the case in the vast majority of the cases.

@paulirish
H5BP member

Unless h5bp required a built step to use it, I don't think we can do this.
The best thing we can do is strongly promote build tools.

Also, looking forward: Bower + AMD + r.js will likely have a future role in solving this issue.

@necolas
H5BP member

I've brought this up before in other issues. I'm in favour of this change because even without a build step, using the CDN doesn't seem to provide significant benefit. But this change would need more work:

  • Remove the extra comment about "why we're not using the CDN".
  • Move mention of the reason to the JS docs file.
  • Include the unminified version of jQuery.
  • Include the jQuery source map file.
  • Include a line about the change in the CHANGELOG.
@roblarsen
H5BP member

That's cool. That's great analysis and what I expected to see in terms of the spread of the URLs.

I think we ended up sticking with the CDN version, not because of the cache lottery, but because serving it from the Google CDN (faster than the average web server even if it's not cached) is a slightly better default than serving two files from one (slower) server- especially if there's a large geographical spread. Meaning, if we guaranteed that people were using a build tool the best default would be removing the CDN and serving an optimized single file (or some script loader solution- whatever), but since we can't guarantee that it's likely a slightly better default configuration assuming noth else happens after the files leave the repo.

For my money, the first thing i do is delete the link to the CDN, but I'm not the target for this particular line of code.

@roblarsen
H5BP member

Speaking of which, I should rerun the tests I ran a few years ago. wpt probably has a million more nodes now- more data :+1:

@alfredxing

I like the Google CDN. It offers speed not dependent on the user's own hosting and server (so if they host a Boilerplate site on a crappy server, loading the jQuery won't take long). And Google's servers should be among the best in terms of uptime and latency.

@roblarsen
H5BP member

One thing that analysis leaves out, that is interesting is a weighting towards the size of the sites using the CDN. For example, if a site like facebook was using a file from the CDN, the odds would be astronomically higher that their specific version would be cached even if they were hosting a unique version. So, while the simple distribution of URLs is interesting (and I think, telling) it's only a part of the picture. I mean, if you have a pinterest friendly audience your odds of http://ajax.googleapis.com/ajax/libs/jquery/1.7.1/jquery.min.js being in the cache are better than they would be otherwise.

@SlexAxton

In the original write up by @zoompf - he mentions that even against your server, in an uncached state, the overhead of an http request doesn't beat just building it into the same file. And further, the DNS lookup to google adds to the issue. The fastest downloads of jQuery in every test I've seen have always been critical pageload resources all in a single file asynchronously in the head. This means that you don't have multiple http requests, and you don't have an additional DNS resolution (which is slow based partly on your provider, not just based on how fast google is).

@roblarsen
H5BP member

I quickly ran some tests with wpt (10 runs in chrome). The default results hold. If you do nothing to the files and just serve them as is (multiple script files), using the Google CDN is faster by default, especially if you have a global audience. The geographical advantage that Google brings continues to matter.

location            one server    google cdn
dulles, usa         1.651         1.275
jiangsu, china      3.484         2.357
sao paolo           2.663         2.019
delhi               4.298         2.977
LA                  2.108         1.74
-------------------------------------------------------------------------
AVG                 2.8408        2.0736

Of course, we don't want people serving multiple files. But if they do, based on this slice, serving it off of the CDN is faster, by default.

@amenadiel

I've tried many options available including a bunch of scripts, concatenating them, and async loading them with RequireJS, head.js and lazyload.js

Much to my surprise, the best ratio of speed/not-breaking-the-hell-outta-the-layout was with google js API which makes me stick to cdn's version 1.7.1

@SlexAxton
@roblarsen
H5BP member

I'm not sure common research agrees with your results. Do you have some
benchmarks we could see? What does 1.7.1 have yo do with this?

1.7.1 is the version of jQuery on the Ajax CDN used by Pinterest? Beetlejuice?

@localpcguy localpcguy Removed Google CDN reference for jQuery
http://statichtml.com/2011/google-ajax-libraries-caching.html

According to that, there is a very little benefit to using the
Google CDN to serve jQuery source.  A better option would be to
encourage devs to minify and concatenate all of their script files
into one JS file served with a long-lived cache time.

This was referenced by Alex Sexton (@SlexAxton) in his talk at
jQueryTO March 2nd, 2013.

Also:
* Included the unminified version of jQuery (in the /js/vendors folder)
* Included the jQuery source map file (in the /js/vendors folder)
* Included the changes in the CHANGELOG
1cecb88
@localpcguy localpcguy closed this
@localpcguy localpcguy reopened this
@localpcguy

I updated the file to more closely match what @necolas listed as needed. Not pushing hard for this to be included (lack of build script seems to be a pretty valid reason not to) but I do think it needs to be considered.

@amenadiel

@localpcguy I guess my explanation was too brief. What I meant is:

  1. Serving all my scripts minified together with jQuery brought no noticeable speed increase over requesting Google's CDN jquery and my scripts separately
  2. Asynchronous loading, in turn, brought performance increase but
  3. Most popular async loaders, including Require JS with-bundled-jquery, HeadJS and LazyLoadJS broke my layout. I don't know why and after a few hours of debugging I decided to try Google JS API and
  4. Google JS brought me the speed of async loading and didn't break my layout, but you depend on what version of jQuery will the API offer. In my case, when I request for version 1 (as in "latest release from 1.x series") Google sends you to 1.7.1. You can manually choose another one, but you'll have to cope with shorter cache headers.
<script type="text/javascript" src="//www.google.com/jsapi"></script>
<script type="text/javascript">
//<![CDATA[
    google.load("jquery", "1");
//]]>
</script>

So yes, I agree with you in that the plain loading from Google CDN isn't the best approach, but I'm throwing in my two cents: on a Linode VPS the overhead of serving jQuery myself is above any performance benefit, and instead I'll reccomend an async loader.

@localpcguy

@amenadiel No, I understood what you were saying. I'm just not sure that your example isn't unique to your specific setup as other testing has shown otherwise. And aren't you making 2 requests then to load jQuery (for the Google code and then again for the jQuery code itself)? Fine if you plan to utilize the Google Loader for other things, but probably not best standard practice.

Also, as an aside, you should always request a specific version of jQuery rather than the 1.x "latest", because of 1) the potential for breakage following any breaking changes when your site gets auto-updated to the latest jQuery. And 2) you also won't get a long lived cached version, which is one of the "benefits" being discussed here as regards loading scripts from the jQuery CDN using a standard script tag and a specific version. (See http://paulirish.com/2009/caching-and-googles-ajax-libraries-api/ - athough that is a few years old now, my understanding is the caching information is still valid.)

@tomByrer

To bounce off the research from @roblarsen
StackExchange.com uses http://ajax.googleapis.com/ajax/libs/jquery/1.7.1/jquery.min.js also (& they rarely upgrade).
GuardianNews.com uses http://ajax.googleapis.com/ajax/libs/jquery/1.8.1/jquery.min.js (I think they did a refresh recently, so I don't see an upgrade coming soon)

Microsoft.com uses http://ajax.aspnetcdn.com/ajax/jQuery/jquery-1.7.2.min.js as well as Skype.com (MS allows public use of aspnetcdn)
Hat tip: http://w3techs.com/technologies/details/js-jquery/all/all

In the end, I have to agree with @paulirish build tools are the best bet, though Google/MS CDNs are the safest bet.

@roblarsen
H5BP member

FWIW, I'm working with one of my old colleagues from sapient and looking at this beyond pure distribution in the HTTP Archive dataset. Hopefully something interesting will shake out.

@zoompf
@alfredxing

I think we should use the CDN and add a note in the documentation that it can be removed.
This should be up to the user to decide, especially with regards to #2: if their website is geographically targeted to a local area (for example, a city), and their server is located within the area, it would be a good idea to host it locally. However, if their website is accessed globally, the CDN reference would be a good idea.

@tomByrer

I think that zoompf makes some great points. Please let me add some additional thoughts

#1: Reducing bandwidth is also important for free/"unlimited" hosts, since they are not so reliable, esp if a blog post link blows up on reddit, etc.

#2: Yes, handshaking must be factored in. Then again, most browsers can do like 8 simultaneous connections?

#3: I would say #3 is very valid. (IIRC, I looked into using the same CDN jQuery version that Twitter used about a year ago, but now it seems they compress all their JavaScript into a handful of scripts & host those themselves; hitting a moving target is not ideal.)

Either way I'd say test test test.

But really who is the target market for html5-boilerplate anyway? Web folks who just want a simple framework to slap together a website really fast for a friend or want to build a page to showcase their new library they just wrote? Or a design team who have been contracted by a major corporation with deep pockets to rework their existing site?

I would think many if not most can change 1 line of code; so I think alfredxing's suggestion is the best.

@zoompf
@localpcguy

I can't speak for everyone @tomByrer, but my view of the target market for H5BP is devs who are looking for the current best practices. I don't view it as a "quick start" guide, necessarily, but rather as a great reference that the community keeps up to date with the latest best practices. That's just the way I see it, I don't speak for the maintainers, obviously.

@davidmurdoch

I feel like our original discussion on the matter should be linked to for reference: #252.

TL;DR:

I think the resolution was that you should do whatever works best for you, as results may vary from project to project, depending on server location(s) and speed.

Run some A/B benchmarks on your sites then make an informed decision as to the optimal solution for each.

<speculation> I'd wager that most websites that include jQuery do not use a CDN for their static resources; I'm not talking about top sites, i.e., Alexa top 200, which often skew decisions like these, but your average mom-and-pop site.</speculation>
I wonder if Steve Souders has data on this? Any educated thoughts, @stevesouders (hopefully I'm pinging the right Steve Souders)?

@alfredxing

I agree with @zoompf, @tomByrer, and @localpcguy on their latest comments.
However, I don't think Boilerplate has or should have a 'target market'. This is open source code and as such it should work best for everybody as an aggregate.

@Schepp

@davidmurdoch Steve favors CDNs as can be read up here: http://www.stevesouders.com/blog/2011/08/17/http-archive-nine-months/

But he did never set up a real world test for this, as far as I know.

I argued against it in the comments basically using @zoompf's methodology of calculating the potential "hit rate" of a CDN regarding a pre-cached jQuery library. Which is low.

I am for including simple on the fly concatenation tools for a bunch of server side languages bundled up with H5BP. Could be limited to the mainstream languages (like you did include server side config for Apache and NGINX only). That would bring a lot of improvement to the average website, and due to the enormous number of those push the performance of the web a huge step forward.

And then leave the build tool in there as the better option for the experienced developers.

@anselmh

I do think H5BP should not force users using a build tool too much. Most web developers don't know how to deal with tools like grunt.js and they don't want to. Forcing them would lead them to other frameworks they actually are able to use without a build system.
It makes still sense to write about using a build tool in documentation and force the user to use it by writing down the advantages of it.

For the CDN/ non-CDN thing: I am not sure. For local sites it makes totally sense to serve local jQuery. For world-wide sites it still might make sense to use your own jQuery, especially when we're talking about the modular new jQuery. But again, this requires web developers to use build tools so we can say: H5BP users normally use it as is which means full jQuery.

What was left out in prior tests here: You cannot only test Chrome for HTTPRequests as this browser does a pretty good job here. Make sure you test it on IE and other older browsers who can't deal with 12 HTTP Requests or more in parallel.

I am in favor of leaving this to tools like Initializr who could offer a selection between CDN and non-CDNed jQuery. (But that's just my little notes here)

@Schepp

@anselmh All browsers nowadays do 6 parallel requests per host on HTTP (HTTPS can be different). The difference between newer and older browsers are more subtle like DNS prefetching or better connection pool management.

Back to topic: On globally targeted sites you should rather use a CDN for all of your static stuff. And only one. Basically meaning that even here you should also concatenate first, and then you can have e.g. an origin pull CDN distribute the result for you.

The jQuery CDN only makes sense as being that one notch better than doing nothing. That's all the benefit I see.

I totally agree on your arguing that even the best build tool is still one step to much for the average developer.

@tomByrer

Just found a solid reference for parallel requests; seems the newest major browsers can actually handle 9-17 MAX connections (by default, give/take). However, if you limit to the same hostname, you are down to 6-8 connections. http://www.browserscope.org/?category=network
Noteable: IE actually has the greatest # of (default) MAX connections. Seems 8 & 9 has more than 10.

I guess one can trick a browser into using MAX connections by using www.myslowhost.com, img.myslowhost.com, js.myslowhost.com, etc. Though IMHO an alt CDN is more ideal. Most ideal is a single concocted & compressed file like Schepp & others suggested (I think we all agree?). For the default H5PB, my gut feeling is still use Google's CDN by default, perhaps with a comment that links to better tools &/or docs that someday will be here?

@davidmurdoch

The first paragraph of Steve Webster's conclusion is a non-sequitur; just because there is a slim chance of hitting the cache lottery does not negate the benefits of Google's CDN. The benefits of using Google's CDN are (free) geographic dispersion, mitigating bandwidth, and parallelization — the cache is just a bonus.

@wordgame

Another thing to consider is that due to the widespread usage of using jQuery from the Google CDN, most people already have a various copies and versions of jQuery in their cache, ready to be retrieved locally, meaning that no request will be needed at all to get jQuery when they come to your site.

+1 for keeping Google CDN jQuery.

@Roope

Amen to this wordgame!

Isn't this the whole point of CDN hosted libraries?

@sarukuku

+1 for keeping the Google CDN jQuery

@davidmurdoch

@wordgame, you should read the article in the first post.

@Schepp

@wordgame @Roope @sarukuku Yeah, please read the article. We try to keep this area facepalm- free ;)

@kdimatteo

@wordgame, @sarukuku This is exactly what we're trying to measure -- the chances of hitting the cache lottery.

Preliminary research into from data collected by httparchive (http://httparchive.org/) indicates that v1.9.1 (which is used in the boilerplate) ranks very low.

In fact, based on requests from the top 1M sites, the most common version of jQuery is 1.4.2 (supports the article shared by @localpcguy)

@roblarsen and I are working on some additional detail and possibility of including cache-lifespan to get a clearer picture of what the cache-lottery odds are.

@cowboy

+1 the concept of static JS hosted by CDN is incredibly dated.

@roblarsen
H5BP member

The benefits of using Google's CDN are (free) geographic dispersion, mitigating bandwidth, and parallelization — the cache is just a bonus.

To this end and since the question here is what's the best default can we just test this thing? Assuming the cache lottery is a non-issue (and hopefully @kdimatteo and I can build on the article linked in the thread to put it completely to bed) we can still test the two states to see what we're actually talking about. I shared some numbers but people in the community have access to many servers in many geographical locations to put some numbers to this. No more finger in the air to see which way the wind blows.

We could test three things:

  1. The default- loading jQuery from the Google CDN
  2. Loading jQuery from the server
  3. Loading one, concatenated file from the server (since this is the final state we're advocating people reach)

We could also test
4. serving one, concatenated file from a CDN, since that should be the best of both worlds.

Test with jSperf and save the results in a spreadsheet on google docs (or we could be fancy and do a Google Analytics web timing thing)

@stevesouders

The only hard numbers I have for the speed benefits of using a CDN are from Yahoo and 5+ years old. I'm confident CDNs provide better performance in general, but variables like local vs global audience, # of resources, etc. could mitigate the benefit.

There is so much great, fun data in the HTTP Archive. I'd be happy to run some queries, but it sounds like Keith (kdimatteo) is already doing that. I'll note that the awesome Steve Webster statichtml article referenced earlier was written 16 months ago, so an update would be worthwhile.

I have access to the MySQL DB so I re-ran the queries from Steve's article on the Mar 1 2013 data. Note that back then we only crawled 30K URLs. Now we analyze the world's top 300K URLs. After errors etc the number of URLs for Mar 1 2013 was 292,297.

=== Percentage of top 300K URLs that load jquery from googleapis.com: 18.2% (53414 / 292297) (up from 13% in the article)
SELECT COUNT(DISTINCT pageid) FROM requests WHERE pageid >= 6726015 and pageid <= 7043218 and url LIKE '%://ajax.googleapis.com/ajax/libs/jquery/%';
=> 53414

=== Most popular versions of jQuery:
SELECT url, (100* COUNT(DISTINCT pageid)/292297) AS percent FROM requests WHERE pageid >= 6726015 and pageid <= 7043218 and url LIKE '%://ajax.googleapis.com/ajax/libs/jquery/%' GROUP BY url ORDER BY percent DESC;
http://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js | 4942 | 1.6907
http://ajax.googleapis.com/ajax/libs/jquery/1.7.2/jquery.min.js | 4722 | 1.6155
http://ajax.googleapis.com/ajax/libs/jquery/1.7.1/jquery.min.js | 4603 | 1.5748
http://ajax.googleapis.com/ajax/libs/jquery/1.3.2/jquery.min.js | 3457 | 1.1827
https://ajax.googleapis.com/ajax/libs/jquery/1.7.2/jquery.min.js | 3110 | 1.0640
http://ajax.googleapis.com/ajax/libs/jquery/1.8.3/jquery.min.js | 3044 | 1.0414
https://ajax.googleapis.com/ajax/libs/jquery/1.7.1/jquery.min.js | 2447 | 0.8372
http://ajax.googleapis.com/ajax/libs/jquery/1.8.2/jquery.min.js | 2134 | 0.7301
http://ajax.googleapis.com/ajax/libs/jquery/1.6.1/jquery.min.js | 1621 | 0.5546
http://ajax.googleapis.com/ajax/libs/jquery/1.5.2/jquery.min.js | 1381 | 0.4725
http://ajax.googleapis.com/ajax/libs/jquery/1.6.2/jquery.min.js | 1381 | 0.4725
http://ajax.googleapis.com/ajax/libs/jquery/1.7/jquery.min.js | 1180 | 0.4037
http://ajax.googleapis.com/ajax/libs/jquery/1.4.4/jquery.min.js | 1175 | 0.4020
http://ajax.googleapis.com/ajax/libs/jquery/1.6.4/jquery.min.js | 1119 | 0.3828
https://ajax.googleapis.com/ajax/libs/jquery/1.5.1/jquery.min.js | 1021 | 0.3493
https://ajax.googleapis.com/ajax/libs/jquery/1.6.2/jquery.min.js | 1013 | 0.3466
http://ajax.googleapis.com/ajax/libs/jquery/1.4/jquery.min.js | 929 | 0.3178
https://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js | 901 | 0.3082
https://ajax.googleapis.com/ajax/libs/jquery/1.6.1/jquery.min.js | 775 | 0.2651

Sadly, it appears that the fragmentation around jQuery version has increased since Nov 2011.

Based on this, however, I can't conclude that it's better to serve jQuery from your local server. Steve Webster suggests that it's better to bundle it with your other scripts. I probably agree with that. In order of decreasing preference I would suggest:

  • bundle it with your other scripts - fewer DNS lookups & fewer requests, better chance of using async
  • serve jQuery standalone from Google Hosted Libraries
  • server jQuery from your own server

So a good follow-up study would be to see the percentages of sites that load jQuery standalone from their own server (making assumptions about filename etc.). I don't have time to do that now (Keith?) and I wanted to get this data into the thread.

Of course, Steve Webster's advice that sites do testing and measure which is fastest is right on.

-Steve

@stevesouders

nit: the second query above should have been:

ELECT url, COUNT(DISTINCT pageid) as count, (100* COUNT(DISTINCT pageid)/292297) AS percent FROM requests WHERE pageid >= 6726015 and pageid <= 7043218 and url LIKE '%://ajax.googleapis.com/a\
jax/libs/jquery/%' GROUP BY url ORDER BY count DESC;

@roblarsen
H5BP member

And... if anyone is interested in testing this:

https://github.com/roblarsen/cdn-test

@tomByrer

@roblarsen:
4.5. Or load more than one concatenated file, (depends on a particular website's need; this is what Twitter seems to do now).
Some other thoughts on having the "ultimate test".

  • Does the webpage have many or large assets per page, like pictures, that can saturate the 6-9 hostname connections, but still have more max connections available? For this reason alone, I would personally A/B/C test on a "real"/cloned website with all assets included. & one website's performance can be different than another.
  • Is jQuery &/or other JavaScript needed to display content (thus needs to be loaded first), or is it used just for flourishes (& should be loaded in the HTML's footer)?

& what testers should consider:

  • Land internet connections vs cellular (might have radically different DNSes, routing...)?
  • Mobile OS vs OS (Android 2.3 has a much different browser connection profile than say iPhone5)

So many possibilities... :) Thanks for all the research & insights; very educational!

@zoompf
@roblarsen
H5BP member

I can't speak for everyone @tomByrer, but my view of the target market for H5BP is devs who are looking for the current best practices. I don't view it as a "quick start" guide, necessarily, but rather as a great reference that the community keeps up to date with the latest best practices. That's just the way I see it, I don't speak for the maintainers, obviously.

From what I've seen it's both. Monitor the issues here for a while and watch the questions on Stack Overflow and you'll see that there are a lot of people who are using it as a quick start who get confused much beyond the initial set of tools. Alternatively the lively discussions that happen here (just like this one- spooky) show that it serves as that best practice repository.

Which is why this question isn't easy to answer. For the experts that use this and for the people that are looking at the decisions here as indications of the smart way of doing things, I think the answer is clearly remove the CDN link and get people to use a build process.

That's obviously what I want people to do as I've spent a lot of time making sure that people have the tools to make sure their code is ready for production.

That said, I don't want to see the project go in a direction that hurts people who are afraid of the command line/severs/node/ant/whatever. That's one of the reasons I want to test this as broadly as we can. I want to see how much penalty removing the CDN would be for people who do nothing but serve the JS files as they're currently configured.

@roblarsen
H5BP member

I disagree. I don't think we have enough data to show that, for a web
server in NY and a browser in San Jose, that the page load time is slower
when downloading that jquery from NY if it was combined with other
JavaScript libraries downloaded from NY. In other words, I haven't see real
world numbers showing that (jquery + other JS from NY) is slower than
(jquery from a local CDN node and everything else from NY). All the
"testing" discussed so far seems very academic under non-representative

The whole point of this discussion is that it's not a question of "jquery from NY ... combined with other
JavaScript libraries downloaded from NY" versus anything. I think everyone is in agreement that the best case scenario is for people to use a build tool to combine their scripts in an optimal way, saving the DNS/handshake, etc.

What we're talking about is the best default and whether or not education about the above best result is enough to offset the potential slowdown people who do nothing will see.

@roblarsen
H5BP member

@tomByrer I love numbers, so I'd love to see many advanced variations. Everyone *knows * what the right answer is, but it's cool to see numbers for these things. Answers can change.

@efes0

What we're talking about is the best default and whether or not education about the above best result is enough to offset the potential slowdown people who do nothing will see.

download time numbers aside the people most likely to make changes (with/without education) are developers and not your average guy as such the best default (at least in theory) would be to leave it as is and educate the devs to take the cdn hosted script out and then host, concat, (& if needed minify) the scripts themselves

and even if the numbers say there is no great savings by using a cdn there still might be enough savings to keep it because without a build step its not being concatenated with the other files (again a dev being most likely to use a build step)

an interesting note
the report that steve souders posted earlier #issuecomment-14857390 doesn't list the version of jquery that h5bp uses (../1.9.1/..) which may change or negate the whole numbers argument

@roblarsen
H5BP member

The more I look at this, the more I think we need to just leave it alone, code-wise, and then just do a better job of talking about the issues that people might face and the decisions they might need to make when looking to optimize their JavaScript delivery. I'm not nearly done testing this thing, but right now I think the current situation is best (with the addition of more documentation)

Part of that documentation should be illustrating why this is the best default, which includes completely debunking the cache lottery canard (sorry @kdimatteo)

@ejstrobel

The linked article is only looking at potential cache hit/miss rates, but includes no analysis of their performance costs in different geographic locations. Implying a benefit from this data is worthless conjecture.

@tomByrer

I am considering a WiKi page to help explain the full decision making process CDN vs self-hosting, both facts & follies. I am very grateful that @localpcguy brought this up; made for enlightening discussion & investigation by all!

I think the final decision should be heavily weighed by real-world testing; not sure if this is the best place to ask for those tools, or once the WiKi page is started we can add the top 5 or so fan favorites....

@tomByrer tomByrer referenced this pull request in zenorocha/browser-diet
Closed

JavaScript sometimes needs to be loaded first #121

@stevesouders

I wrote a blog post with all the detailed stats and SQL.

http://www.stevesouders.com/blog/2013/03/18/http-archive-jquery/

My conclusion is we should encourage people to use Google Hosted Libraries. Creating a monolithic script that combines jQuery core with site-specific JS will likely be inefficient because of JS not being incrementally parsed and site-specific changes invalidating the cached combo file, necessitating a re-download of the same jQuery core.

-Steve

@ghost

@localpcguy @roblarsen @stevesouders @efes0 @paulirish

Here's my thoughts:

It is worth investing in your own CDN rig/setup.

If you're grabbing the latest version of jQuery from Google, many scripts could break without you even knowing it.

That scenario is a sort of dependency hell we need to avoid.

I am aware webmasters like to stick with one solid version of jQuery for peace of mind, like 1.8, or the even safer 1.4 variety to avoid the latest version of jQuery breaking our plugins, but...

A single point of failure like Google's AJAX CDN could cause problems too:

Call me extreme in my view, but aren't self-hosted solutions a more ethical approach to serving scripts?

The independent approach has no caveats because you're in control of the server. If it goes down - setup a new instance.

Also - you're not tracked by Google. How many times is your IP logged each time jQuery is served from Google's CDN?

jQuery weighs in at little more than the size of a standard sized PNG file. So it’s equivalent to loading a small graphic.

It’s not the bloated monster many blog authors like to claim it is ;) Food for thought.

I voiced these thoughts on Souders' post here:

http://www.stevesouders.com/blog/2013/03/18/http-archive-jquery/

s

@roblarsen
H5BP member

Just putting my thoughts here so that it's in my permanent record :)

I think the best default is the Google CDN. I agree with @stevesouders reasoning and just looking at the core numbers it's generally a decent default. One of the things that I saw in my testing was that the variability of the server itself can be a big issue. The best results I've seen with single server/single file solutions were on a box I've got root access on which is running mod_pagespeed. With a generic server losing out on Google's optimized delivery itself can be an issue.

So I think the code should stay where it is. That said, talking about the ways in which the default can be improved is impotant. As @higgo points out, talking about CDN options is good (while they're slightly more complicated, lower priced CDNs like Cloudfront can be both faster and cheaper than standard hosting) as is talking about build processes, script loaders, etc.

@ejstrobel

@higgo: Of course you have to link to google CDN's versioned jQuery, not their latest version link, so no dependency hell.

And re tracking: a major point of this is caching, so no, google will not see a lot of your clients' IPs, in fact hardly any at all.

Next I doubt the default server setup is expected to be more reliable than google CDN (and neither faster in all geographic locations). For your own installation this may apply, but it doesn't make self hosting a good default.

@localpcguy

re: @ejstrobel "google will not see a lot of your clients' IPs, in fact hardly any at all."

I think that was a big part of what prompted this discussion, was that the actual chance of getting a cached version of jQuery that matches your version is very slim (~1.7% if you are using 1.4.2, less for any other version.)

@ejstrobel

localpcguy: you are using phony math, and confusing % of sites with cache miss rate.

If 1.7% of sites use a given jquery version, for a cache miss that means that your clients must never have visited any of those 1.7% of sites in the last year. For only 100 sites that's 1-(1-0.017)*100 == 82.0% probability jQuery *will be cached.

Edit: corrected math

@kdimatteo

@estrobel Why are you considering a per-year period? The browser cache has a size-limit. One of the metrics that complicates the cache-lottery question is the churn-rate of the average browser cache (which is impacted by how many sites they visit in a day).

@roblarsen
H5BP member

in the last year

That's a long time to assume a file will be cached. Browser caches are tiny They may have improved since, but this is still sobering:

http://www.stevesouders.com/blog/2010/04/26/call-to-improve-browser-caching/

@ejstrobel

kdimatteo: because jQuery is even more tiny than a browser cache, and I am guessing the 100 sites number too.

Still I bet my numbers are more viable than assuming a client has exactly 1 other site in his browser cache, which you do assume if you take the % of sites which use the same jQuery version and directly take that number as your cache hit rate.

@nickshanks

To the several people who seem worried about an additional DNS lookup, this is a non-issue. In my testing, DNS lookup for ajax.googleapis.com takes about 75ms, less than half that of a 'normal' (outside top 10k) domain. Chrome does speculative DNS lookups anyway, and other browsers are heading in the same direction, so this hostname lookup will almost never be on the critical path. It contributes to domain sharding (and does so in half the time), and it's cached state can always be ensured with a Link: rel=dns-prefetch HTTP header for those who always need the greatest speed.

However the most critical thing is that individual jQuery versions never change. Once it's cached it will always be valid. A high max-age means no connection, no request, no 304 response, browsers even cache the result of parsing the JS so it doesn't need to be re-parsed. Your own website's JS will change much more frequently, and bundling the two together is almost never a benefit. The only people who would benefit are those who arrive with a cold cache. The target audiance is pertanent here. If the target audiance is "everyone", and not "high-paid front-end performance experts", then the default should be what will work best in the general case. The experts can combine their JS if A/B testing proves it to be beneficial for them. General HTML authors using this boilerplate won't have the skills to do that.

To the guy who commented saying a high cache churn rate would mean jQuery won't stick around in the cache, you're not thinking. A high churn rate means the user is visiting lots of sites. This means they are more likely to have encountered at least one site which uses jQuery from the CDN, and they are more likely to have seen several sites which use the same jQuery version. Repeated use from multiple sites will therefore make jQuery more likely to be present than someone with a low churn rate who is visiting your site for the first time.

Lastly, one person suggested that HTML clients ship with built-in copies of common libraries. This is something I have already suggested to them, but no-one has shown an interest.

@tomByrer tomByrer referenced this pull request in cdnjs/browser-extension
Open

How goes it? #2

@localpcguy

I have been pretty convinced over the last week or so that the CDN is actually the best default state, but that there should continue to be more discussion about other ways that could offer better performance. It's been a really interesting discussion and I appreciate the amount of thought that went into this request, both here and off-site, it is impressive!

@davidmurdoch

I'm sure we'll have a similar discussion again in another year or two. Maybe at that time we'll swing the other way!

@roblarsen
H5BP member

I'm sure we'll have a similar discussion again in another year or two. Maybe at that time we'll swing the other way!

I don't know which way it will go in the future, but it'll come up again. I'm really happy with this discussion though. I think it was a nice deep dive, and I'm (now) convinced that the CDN is still the way to go.

It couldn't hurt to document why it's being used and why you might want to change it, but as it stands it's the best default.

@SlexAxton

Specifically, the CDN might be the best default for HTML5Boilerplate, but likely is not the way to have the lowest average pageload time for your site. Let us not confuse the two. None of the data found suggests that.

@roblarsen
H5BP member

It depends on how nuanced we want to get. For example, a person who wants to reach the world on a host that does nothing for performance and doesn't allow tinkering with server settings (for an obvious example, setting some sort of compression at the server level) then it's probably still going to be faster to use the CDN. That person should probably just get a new host if they care about performance, but if that's not an option making a blanket statement that they should ditch the CDN and host locally is doing them a disservice.

I'd err on the side of nuanced, personally. This is a great opportunity to educate.

@Garbee

Another discussion that we could have is which CDN is best. Removing the cache lottery from the equation, shouldn't we provide by default the fastest CDN?

@RobbieF has done a local test on Google's CDN copy compared to CDNJS's copy. He finds a big speed difference as noted on his blog. I ran the same test locally and at my remote server, I had no difference locally, but that could have been due to a few things being cached in my local network such as DNS queries. While remotely I saw the same huge gap in performance.

I think something else we should do is test different CDN's to find the fastest one from a reliable source and move to using the best if we are to keep using a CDN copy.

@localpcguy

I think if we consider what @Garbee is discussing, we have consider developer momentum as well. There has been a push for the last 3 years plus/minus to encourage people to use Google Hosted Libraries, and to change that reco based purely on speed tests from a few locations seems like a rather odd choice. Might be a discussion worth having, but at the moment I would err towards not halting the momentum that has been won so far without really solid proof. Plus, part of why people will use Google Hosted Libraries is because it is from Google, and so "should" have really solid uptime and speed.

@nickshanks

It would certainly be a bad idea to use a different CDN. There's plenty of evidence presented in discussions elsewhere about jQuery CDNs that Google's is both the fastest on average from around the world (closely followed by MT, with MS trailing in third), and that it has by far the highest penetration among other sites (increasing the chances of a cache hit) regardless of whether you're considering the top 100 or top 100,000 sites.

@Garbee

Completely forget the cache hit chances. If someone is to serve a page to someone with zero cache in whole, the boilerplate should offer the fastest possible page. That means perhaps choosing another CDN other than Google's for serving jquery.

@nickshanks can you link to the other discussions you have seen? I would like to see how they have conducted tests so that we can form our own test to run. Further those tests may not include a CDN like CDNJS or other less-major providers. We should test across as many public CDNs as possible, not just the top ones.

@nickshanks

The best speed data I have seen: http://royal.pingdom.com/2012/07/24/best-cdn-for-jquery-in-2012/
The conclusion there is that, for a global audience, and if you may need HTTPS, Google is fastest.
For North America, without SSL, Media Temple (jQuery's own CDN) is fastest.

This page and the articles it links to are good background reading, which may give a few reasons you've not seen before:
http://encosia.com/3-reasons-why-you-should-let-google-host-jquery-for-you/

Some HTTPArchive jQuery version & CDN numbers of my own from 6 months ago: http://nickshanks.com/httparchive/ (no accompanying blog article, .ods file has more data than .csv)

This guy comments on the dangers of -latest breaking your site: http://www.markflint.net/pros-and-cons-of-using-latest-jquery-cdn/ but he neglects to mention that the -latest and /1.x/ version only have a 1hr cache lifetime whereas the explicit three-number versions have a 1yr cache lifetime, meaning that repeat visitors or frequent web surfers are much more likely to have it cached (assuming you are requesting a common version like 1.7.2, as determined from HTTPArchive data)

Plus these already linked-to earlier in this thread:
http://statichtml.com/2011/google-ajax-libraries-caching.html (the original article that got me interested)
http://www.stevesouders.com/blog/2013/03/18/http-archive-jquery/ (most up-to-date HTTP Archive reduction, be sure to read all the comments too)

@nickshanks

@localpcguy This is a comment about your blog post (where comments are disabled). You are only testing the cold-cache, single page load times. That's not representative of normal behaviour.

I would suggest that normally, for subsequent page loads and people arriving who have visited other websites before yours, you'd see this:

Script: jQuery
Size: 0 KB
Time: 0ms
Loaded from browser cache: y

Script: jQuery UI
Size: 0 KB
Time: 0ms
Loaded from browser cache: y

Script: scripts.js
Size (KB): 19.2 KB
Time: 160ms (avg. of 145 & 170 - I presume this was time to first byte, i.e. latency)
Loaded from browser cache: n

Total: 19.2 KB, 160ms

vs. unified result:

Total: 102 KB, 160ms (avg. of 145 & 170)

@roblarsen
H5BP member

This is a comment about your blog post (where comments are disabled). You are only testing the cold-cache, single page load times. That's not representative of normal behaviour.

Cold-cache, single page load is the only page load you can ever guarantee. You can't guarantee a hit from the Google CDN and you can't guarantee that a visitor to your page has been there before. Whether or not a primed cache view is "normal" is another line of research, but even assuming it is, *getting** to a second page view will be greatly enhanced by a fast cold-cache page view. Which is why testing against that is super useful and is really the only piece that's important here.

*based on the old Yahoo example- http://www.yuiblog.com/blog/2007/01/04/performance-research-part-2/, it's not, but... that's so old now it frightens me. Has anyone updated that research?

@localpcguy

@nickshanks I agree, and think I stated, that my test was very unscientific - single page test on a single site on a single server, and I only ran the test a few times and took the average result. That being said, I agree with @roblarsen that we should be testing as if the cache chance doesn't exist, which will give us the baseline performance. Then any additional performance that could come from a cache hit is a bonus, but I am still not convinced you can count on it.

@amenadiel

Just to honor the truth, guys, I refactored my code to use jQuery deferred objects, which led me to drop Google API loader in favor of yepnope (included in Modernizr) and then, considering I was already refactoring the hell out of my code I switched to Require.js and spent the next 48 hours getting to know it. And while the total loading time for the main app stayed about the same, the rendering time for new interfaces and new deployments dropped to 1/5th.

So, now I have to admit I'm up to self hosting just a big fat optimized script.

@Jakobud

CDNJS is faster than Google CDN

Sorry to burst your bubble, but http://royal.pingdom.com/2012/07/24/best-cdn-for-jquery-in-2012/ is a bad CDN comparison, considering it doesn't even include CDNJS or other potential alternatives. CDNJS is reported in multiple places as being consistently faster than Google's CDN:

http://www.baldnerd.com/make-your-site-faster-cloudflares-cdnjs-vs-google-hosted-libraries-shocking-results/
http://blog.cloudflare.com/cdnjs-the-fastest-javascript-repo-on-the-web
http://chetansingh.me/2012/12/25/cdnjs-the-fastest-javascript-repository-on-the-web/

And according to CDNJS they are serving up roughly 31,000,000 downloads per day right now (and it's still growing). Ignoring CDNJS as a viable replacement for Google's CDN is just short-sighted and silly. Don't assume Google's CDN is the best end-all solution just because it's been around longer. People aren't just coming out and saying "It's faster!" without proof.

This thread is absolute nonsense

People are arguing that using CDNs are pointless.... Seriously? If this was the case, then why would they possibly exist at all? There is absolutely NO WAY that not using a CDN and instead concatenating your scripts together would EVER outweigh the bandwidth and speed saved from a CDN unless your site got only a dozen visitors a day.

Tiny JS change = Massive waste of bandwidth

Also, what happens when you make a tiny change to your JavaScript? Guess what... now your visitors have to redownload your entire concatenated JavaScript file again, including the unchanged jQuery. Make a typo and need your visitors to download another version? Oops you screwed over your visitors again. This thread's ENTIRE ARGUMENT just went right out the window...

Common people.

@alfredxing

@Jakobud Google's CDN is faster for me (approximately 20ms difference). The first source only measures the download speed: CDNJS is much faster. However, with regards to the total time, Google has a much lower latency. The second source (from Cloudflare) is more trustworthy, making CDNJS worth considering. The third is the same as the second, so it doesn't really count (and there's an error: CDNJS isn't twice as fast, only 50%).

And the question here isn't just about concatenated JS versus CDN; how about self-hosting separate files?
Also, we're not arguing about whether using CDN's are pointless, but about which option would be best to include as default (remember, this isn't about a single website, but a boilerplate template for anyone to use). In that case, all arguments made should have solid proof backing them in one form or another...

I agree with your points about not just considering Google's CDN, but stability (and not just speed) is another factor that needs to be considered.

@Jakobud

@alfredxing thanks for the insights. I feel like H5BP is probably moving toward a build-able package to download. Sort of like how with Modernizr you can pick and choose what you want to include in it. Would not be a bad thing. Also, the first post in the thread is suggesting that concatenating scripts might be better than using a CDN, which is what I perceived the thread to be about.

Also, I cannot imagine that self hosting your own library files would ever be faster than using a CDN in the long run. You are virtually guaranteed that some of your visitors have jQuery cached from a major CDN already. Even if only 1% of your visitors had it cached, that would be enough to outweigh self hosting it all yourself.

@alfredxing

@Jakobud As I mentioned in a previous post, I believe it's mostly about the target audience. For example, if it's a local business whose website is hosted on a local server, hosting their own scripts might be faster (again, a reduction in latency).

I like your idea of having a custom build option; I'll try to make it if I have time but it's going to take some effort.

@nickshanks

@Jakobud thanks for the additional urls. i look forward to reading them.

CDNJS is faster than Google CDN...

how fast any particular cdn is, by milliseconds here or there, is pretty much irrelevant.
the only really important information for choosing a cdn for hosting common library files is how many other sites popular with your site's visitors are also using any particular cdn, what library version they most commonly use (of the versions your own site is compatible with) and whether you need https or not.
this is because a cache hit is much faster than any http request. the point of using a common url vs. hosting your own copy on Amazon S3 or akamai, is through serendipity, to have the library already in the user's browser cache before they come to your site.

this argument isn't just cdn vs. no cdn (which you address below), but also which cdn is "best". I assure you that for most website owners, in most parts of the world, cache hits are more important than the difference between different cdn's response time.

one of the goals here is also to reduce fragmentation between different cdns and different jquery versions by standardising on one combination.

People are arguing that using CDNs are pointless.... Seriously?

totally agree.

Also, what happens when you make a tiny change to your JavaScript? Guess what... now your visitors have to
redownload your entire concatenated JavaScript file again, including the unchanged jQuery. Make a typo and
need your visitors to download another version? Oops you screwed over your visitors again.

again, totally agree. my site-specific js changes almost daily. the library code is cached for a year.

@Garbee

@nickshanks Actually the improved speed (even by a few milliseconds) is the only real benefit we can measure (besides uptime to measure reliability.) That is what we should be deciding on, not some random chance of a cache hit.

I assure you that for most website owners, in most parts of the world, cache hits are more important than the difference between different cdn's response time.

Going by this logic, let's say 4% of visitors have a cached copy. You are then saying that 4% have a better experience by pure dumb luck. On top of that, you're saying that you are willing to give 96% of visitors a slower experience because you want to give the 4% with that random cache hit a better experience. Overall, that logic hurts businesses more than it helps.

We can only assume zero cache in any visit, so we should optimize for that scenario. Not the random chance scenario that someone actually has a copy cached.

@localpcguy

As far as the argument that site-specific JS changes much more often than library code, if that is the case for your product, then it may make sense to either server 2 JS files (one long cached that rarely changes and another for things that change frequently) or to use a CDN. None of the argument I put forth at the very beginning is about whether a CDN should be used, but whether it should be the default state for H5BP.

I think documenting other CDN's besides Google's wouldn't necessarily hurt, but it depends on the goal. If the goal is to get enough developers using a single CDN so that the cache chances are NOT a lottery, but actually something that can be a quantified benefit, then I would argue that staying with the Google CDN and not documenting others might be preferable. However, if the goal is to find the best CDN regardless of developer fragmentation, then the others like CDNJS should be documented and maybe even replace Google's CDN if it is shown to be a better service.

@Garbee

I personally don't think there is a doubt in most projects a CDN for jquery should be used. However, in a few cases depending on how the site and/or application is built that could hurt performance. The boilerplate exists to give the biggest benefit of a quickstart in most situations while using best practices, which means using a CDN is an absolute no-brainer. Therefore I don't really see this changing in the project.

The discussion has gone from possibly removing Google's CDN into which CDN is actually best to recommend for projects that use one. Since people seem to stick to Google in order to win a cache lottery, while other CDNs like CDNJS could offer enhanced speed for all visitors, not just the lucky few (if any) that have a cached copy.

Update: Although, the argument could be made that the boilerplate should be an all-inclusive starting point. Making a CDN resource unnecessary and hurt that goal. But considering it has a local fallback if the CDN is not available, I see using one as fair game.

@nickshanks

@Garbee , @localpcguy

let's say 4% of visitors have a cached copy. You are then saying that 4% have a better experience by pure dumb luck. On top of that, you're saying that you are willing to give 96% of visitors a slower experience because you want to give the 4% with that random cache hit a better experience.

My intent is to shepherd everyone onto one CDN so that that 4% figure you quote grows to 94%. If H5BP gets widely adopted, whichever CDN you choose will be greatly boosted in it's usage.

If the goal is to get enough developers using a single CDN so that the cache chances are NOT a lottery, but actually something that can be a quantified benefit, then I would argue that staying with the Google CDN and not documenting others might be preferable.

Yes, that is exactly what I was trying to guide people towards!

@ejstrobel

@Garbee I am sorry, but where is this 4% figure from? Seems very low to me, can you back that up with any data?

The original linked article only provides percentages of sites which use given jQuery versions. This does not directly translate to cache hit rates! Assuming a browser has a history of several sites cached (or at least the important parts), even a low percentage leads to a high cache hit rate, as you need only have visited ONE correct site.

The chance for a cache hit with n sites visited, and each site having a chance p to prime the cache is: 1-(1-p)^n.

That's assuming all sites are equally probable to be visited, which of course is too simplistic. Using the same version as any popular site increases your hit chance by a lot.

@Garbee

@ejstrobel Using a version that a major site has can actually end up having you serving a slower version of the library, which could end up actually negating the cache benefit by causing extra resource usage on the client.

Further, I have no real stats (nor do I know of any) for the 4%. It was never meant as an actual stat, just an example of how you may be hoping for something that generally may not be there. Then again I would love to see actual stats for sites that show a user has a cached version as well, since numbers for both sides would be interesting to see.

But, the article does show the separation of versions between sites and how slim it can be to get a hit. So why even take that into account when deciding on the fastest way to serve a page?

I also see the "only needing to hit ONE correct site" as yet again asking for hope on a cache.

@nickshanks I understand trying to shepard one CDN around. The thing we need to decide is which is the best for that. Saying Google because it has been used longer and is just a de` facto standard isn't right. We should test properly, assuming zero cache. From there pick the best CDN to recommend.

The web should be fast, even for people with no cache. Therefore, we should test with no caching and find the best CDN, from there recommend it as the standard to use. Whether is is Google's or not.

All I seem to keep seeing is that we just keep using Google's CDN out of being a de` facto standard for being the fastest/most supported. This isn't right, since we are really only guessing at speed and other possible benefits. There is no consistent and highly distributed system for testing CDNs. Until we have something, it is almost pointless to keep going in circles over which one to rightly use. This brings to mind Paul Lewis' Don't guess it, test it! talk. Which explains that we need to not just assume things (which we currently are with Google being the fastest CDN) but actually construct a solid standard test and act upon those results.

@adeelejaz

TL;DR: CDN shaves off load time massively when server is on the other side of the globe.

I'm just adding these numbers to give a bit of perspective, I've used h5bp for quite a few sites in past one year (60 and counting).

The huge benefit of the CDN is the files are locally available. The DNS lookup is irrelevant when you will spending far more time fetching it from a server on the opposite side. For example, most of the websites I work on are hosted in US and UK. For most users sites load under 3 seconds, for some with super quick connection, the time is below 500ms.

But for our friends in Oceania, Asia and Africa, the numbers can be much, much higher. Having files off-loaded to a CDN helps massively. In my humble stats gathering, it can take up to 7 seconds for sites to load in Australia or New Zealand for some users (particularly ones using mobile or cellular network).

I can see why it might seem like an extra few DNS lookups might hurt, but I can assure you when you are sending stuff all over the world, being able to utilize local content via CDN does help*.

PS: Unless for some very odd reason you have ridiculous number of CDNs, in which case you then have a completely different issue to deal with.

@Ganginator

I don't understand why using a CDN is bad, just have a backup of the current working library, and if there is a major issue, you can change back quick.

@Erick-Ribeiro

What about removing from CDN and putting all the CSS and JS files into an HTML5 appcache?

@Garbee

Appcache is a bad thing right now. For instance, if any resources are updated it won't take affect until the next reload.

There needs to be a new revision which is being discussed to fix some issues in it before it will be widely used. appcachefacts.info has numerous details on the current spec, some are fine others are just bad.

At this time, appcache is a bad idea to recommend for people to use in general in my opinion.

@tomByrer tomByrer referenced this pull request in moment/momentjs.com
@timrwood timrwood adding cdnjs note 49665ed
@zenorocha
H5BP member

I think front-end dependencies should be managed via Bower, not only jQuery but also Modernizr can be fetched.

@patrickkettner

Modernizr is not planning to go via bower - the variance required for every user makes a build step much more attractive.

@arthurgouveia

I was planning to ask that. H5BP uses a customized version of it. I'm not 100% sure about what was changed but I'm guessing there's no way ATM for bower to request it with appropriate flags or any sort of thing to fetch with what H5BP judges as appropriate.

+1 for the jQuery being fetched by bower, tho.

@patrickkettner

It uses the main modernizr.js file. That is going away in the yet-to-be-release 3.0. It has yet to be determined what is going to happen after that..

If you were to load jQuery via bower, you might as well do the custom build of it. I would be -1 on both requests in favor advocating proper build steps.

@Ganginator

Proper build steps are a good thing, as long as there is documentation helping the user walk down the correct path. The worst thing to do is to remove common necessities, and then leave the user lost without any direction.

@roblarsen
H5BP member

Discussion of bower here misses the point of the discussion, I think. The question is "what's the best default way to include jQuery for consumers of HTML5 Boilerplate and their users?" Saying "you should manage your dependencies with Bower" isn't really an answer to that question since it sidesteps the most important part of the equation- what's the fastest default way to serve jQuery to end users.

For now, unless something's changed in the past few months, that remains the Google CDN.

@Ganginator

I agree with that 100%.
Is there a reason the main http://code.jquery.com/jquery-1.10.2.min.js CDN is not used, versus Google?
Either way, then document the last tested build, and advise the user to consider CDN versus a build?
Using the CDN's to get "out-of-the-box" functionality will make it easier to adapt by new people.

@roblarsen
H5BP member

If you're interested in this subject at a "why" level, there's a lot of detailed discussion of the issue in this very thread. Just start at the top and work your way down. The short answer is

  1. The Google CDN has much higher penetration and is, therefore, more likely to serve a cache-lottery winner
  2. The Google CDN supports https:// the jqury cdn does not
@tomByrer

+1 for the jQuery being fetched by bower, tho.

Future jQ versions will have its own AMD loader. Though IMHO so many people use various jQurey plugins, I'm not sure if that will save much bandwidth.

Google CDN has much higher penetration and is, therefore, more likely to serve a cache-lottery winner

MAYBE 1.69%
Almost as good reason as your 2. :
3. Google has multiple PoPs in many many countries, including China IIRC.

@roblarsen
H5BP member

The question is a thin one. Why are we serving from Google and not some other CDN?

So, even though the odds aren't great (and pure penetration of any single library isn't the only factor) they're going to be better with Google than with someone else who is less popular. If you read through this thread, you'll see that I think the cache lottery is a canard. It's just that, if the cache lottery matters to you at all, the Google CDN is a much better option than anything else as it's got much higher penetration.

Of course, this is about the best default, not the best possible answer. The best possible answer can only be answered by the individual developer testing options on their individual site or application.

@pankajparashar

I think @roblarsen nailed it with this statement -

Of course, this is about the best default, not the best possible answer.

+1

@tomByrer

The best possible answer can only be answered by the individual developer testing options on their individual site or application.

Yes, which is why I said "Test test test" before. And why we need to be aware of pros & cons.
As far as 'cache lottery', the technical reasons (number of PoPs, high uptime) are more likely going to weigh heavier. It could be worth looking into if a large percentage of your site's traffic is refereed from a single particular site, then share the same CDN & version, if that does not break your other code.

@roblarsen
H5BP member

Pinterest would be a great candidate for that technique

@tomByrer

Pinterest would be a great candidate for that technique

Unfortunately, they don't seem to use jQuery.js at all, perhaps concocted. I was thinking more stackoverflow/StackExchange, who uses //ajax.googleapis.com/ajax/libs/jquery/1.7.1/jquery.min.js.
But then, one has to test their site if they change their jQuery version... might not be worth it.

@roblarsen
H5BP member

oh they used to. they did when we had this discussion originally.

@robwierzbowski

...Most H5BP projects use jQuery via Google CDN. (#oroboros #selfFulfillingProphecy)

@alrra alrra was assigned
@alrra
H5BP member

build step

H5BP tries to be relatively agnostic of any high level development philosophy or framework, so that it can be used:

  • as a base on which other projects can be build upon
    (projects that can ultimately provide the build step)
  • even by less experienced developers
    (developers that don't use a build step or even know what that is)

Thank you all for your comments!

I'm sure there will be a similar discussion in the near future (especially as things such as SPDY / HTTP 2.0 get more traction), but for the time being, we'll stick with the CDN.

@alrra alrra closed this
@roblarsen roblarsen referenced this pull request
Closed

Update html.md #1498

@roblarsen roblarsen added a commit to roblarsen/html5-boilerplate that referenced this pull request
@roblarsen roblarsen Extended comments about use of jQuery CDN
As promised in #1498
Encapsulates the discussion from #1327
a153cdd
@roblarsen roblarsen added a commit to roblarsen/html5-boilerplate that referenced this pull request
@roblarsen roblarsen Extended comments about use of jQuery CDN
As promised in #1498
Encapsulates the discussion from #1327
2bdb7d1
@roblarsen roblarsen added a commit to roblarsen/html5-boilerplate that referenced this pull request
@roblarsen roblarsen Extended comments about use of jQuery CDN
As promised in #1498
Encapsulates the discussion from #1327
008227f
@tomByrer
@robwierzbowski
@tomByrer

@robwierzbowski You must have missed this post; expecting hitting the cache with same version is dismal, esp now 10+ releases later...?
#1327 (comment)

@tomByrer tomByrer added a commit to tomByrer/html5-boilerplate that referenced this pull request
@tomByrer tomByrer removed inconclusive proof for Google CDN caching
Perhaps the rise in [AngularJS](http://angularjs.org/)'s popularity be the real cause for the rise in popularity in ajax.googleapis.com?  Or maybe "[Sites using Google Libraries API](http://httparchive.org/trends.php#perGlibs)" rise is caused by "[Sites with Custom Fonts](http://httparchive.org/trends.php#perFonts)"?  Perhaps a revisit to see if [hitting the version lottery](h5bp#1327 (comment)) is in order, but I doubt it will prove it is worth mentioning "increases the odds of having a copy of the library in your user's browser cache".

Even though I'm involved with [jsDelivr CDN](http://www.jsdelivr.com/), and I see alot of [cdnjs](http://cdnjs.com/) usage in the wild, I conclude Google's CDN is the best to use for h5bp.  But please, an extra 1% chance of hitting cache isn't really worth it IMHO.
63a4101
@tomByrer tomByrer referenced this pull request in roblarsen/html5-boilerplate
Closed

removed inconclusive proof for Google CDN caching #1

@robwierzbowski

I have seen that and I really appreciate the research. I wonder if there is a way to track a segment of users and see how many times over the course of the day a they use the same version of jQuery between sites. It's possible user behavior could select for sites that have a smaller subset of jQuery versions (I'm a designer and I visit a lot of elitist web design blogs?), and I personally work on a small ecosystem of apps that can benefit from pulling the same version of jQuery between sites. And then there's cache lifetime: the longer a user's cache lives, the more likely they are to have a particular jQuery in their cache. How long does an average internet user need to surf until they have 80% of jQuery versions somewhere in their cache? The likeliness of a particular version being available is a curve that increases over time.

Thanks for pointing out the numbers again, and I completely agree that it's a lottery. But I'm not convinced that those numbers alone settle the "should we use a CDN" question.

@tomByrer

Seems with HTTP1.1, CDNs allow more "Max Connections" than local host alone (without sharding local, which is beyond scope of h5bp, & IMHO won't see the benefit of a separate server.).

The likeliness of a particular version being available is a curve that increases over time.

Perhaps 2 years ago, but devs don't upgrade versions much, so there is a huge range of versions out there. Plus IMHO script collation & there being 4-5 CDNs in use will reduce cache odds a bit more.

possible user behavior could select for sites that have a smaller subset of jQuery versions

I used to worry about that, until Pintrest dropped using Google's CDN (they now collate & CDN themselves). If you are the web dev for a network of sites that link together perhaps that can help. But if you're that big, you should really look into a caching CDN (eg Envato/Tuts+ uses CloudFlare).
Again, out of scope for this project.


Also, seems there is a bit of backlash against extra DNS lookups, but:

  • Thanks to other libs & versions using ajax.googleapis.com DNS entry is likely cached already
  • jQuery is a big lib; likely worth a DNS lookup.
@dwick dwick added a commit to reddit/reddit that referenced this pull request
@dwick dwick Add jquery/html5shim directly to bundle.
Also removes "load core JS libraries from reddit servers" as
a preference since it is no longer needed.

Using the google cdn for jquery adds very little benefit, see:
http://statichtml.com/2011/google-ajax-libraries-caching.html
and
h5bp/html5-boilerplate#1327
92815bb
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Commits on Mar 7, 2013
  1. @localpcguy

    Removed Google CDN reference for jQuery

    localpcguy committed
    http://statichtml.com/2011/google-ajax-libraries-caching.html
    
    According to that, there is a very little benefit to using the
    Google CDN to serve jQuery source.  A better option would be to
    encourage devs to minify and concatenate all of their script files
    into one JS file served with a long-lived cache time.
    
    This was referenced by Alex Sexton (@SlexAxton) in his talk at
    jQueryTO March 2nd, 2013.
    
    Also:
    * Included the unminified version of jQuery (in the /js/vendors folder)
    * Included the jQuery source map file (in the /js/vendors folder)
    * Included the changes in the CHANGELOG
Something went wrong with that request. Please try again.