Yes; a lot of companies that want to make their services available to mobile users (which is a pretty damn large market) but do not have the capacity or do not want to invest in native apps will want their developers to build a mobile webapp, responsive website, or hybrid app.
Disclosure: I'm rebuilding a pretty big BackboneJS app (which I started building two years ago with a team that grew to two dozen people) into an AngularJS-based mobile webapp.
Note also that AngularJS is a whopping 700 KB before minification and gzipping (270 KB minified/gzipped).
yah. I usually first build REST API using HTML as main representation of resources. It looks ugly. But fully functional. Then I add user facing rendering that adds CSS, Javascript, and possibly transforming representation. For mobile pages, I rarely add javascript.
jQuery is fine, but for the sake of your user experience you should customise it to only include things that you actually use. An extra 28k download, as well as the additional overhead of the browser parsing and running it, does affect the experience to some degree. A minimal build of jQuery is better than the whole thing. "Don't use jQuery" is overkill, but "Use jQuery wisely" is common-sense.
The key thing to remember is that your time as a developer should be spent making software that the user will enjoy using - your job is not to make your own life as easy as possible by throwing in libraries with no thought about how it'll affect the user experience. Learn a build tool and use it to optimise your web apps.
You can fall back to jQuery on IE, if needed. Whether a site is responsive shouldn't matter—you aren't going to load choose jQuery/Zepto based on screen size, but based on browser capability.
Luckily nobody will volunteer to support anything older, and will discourage customers from supporting it if they value their developers' sanity and their customers' experience and security.
I could never use this if I wanted to put it in any project I work on. For most projects I have worked on so far I have needed to support at least IE 8. That probably wont be changing anytime soon because some user still havent upgraded since they first had a laptop with Windows 7.
I got told that Zepto does some things poorly, such as garbage collecting. It would seem like that would be especially important when it comes to mobile.
I've worked on a big tablet-first site where we first built everything using Zepto, because of the assumption that 'everything would work the same as jQuery, but it's smaller and faster'.
Unfortunately, we encountered a lot of bugs, inconsistencies with the jQuery API and general lack of interest in supporting IE. Somewhere halfway through the project we switched to jQuery and we didn't have any performance problems. Some things actually worked better because jQuery has better workarounds for some of the bugs in older Android browsers.
> Don’t forget that if you’re loading jQuery from a common CDN like Google’s or Microsoft’s, you’re likely introducing zero network latency as the browser will almost certainly have it cached already.
This claim is frequently made, but I’ve also seen many people express skepticism of it. The many different versions of jquery, and several different CDNs, combined with actual typical user behavior patterns, the limited cache capacity of some mobile environments, etc…. it MAY still be true, but I’d really want to see some evidence one way or another before assuming it either way.
It’s not an easy thing to measure though, because we are making claims about “most people’s browsers”, and there’s no easy way to measure other peoples browsers. But is anyone aware of anyone trying to approach it?
Why does it matter? If the "cached in most people's browsers" theory is true, then we would not want to concatenate JQuery into one big JS file (as the OP suggests), and we would not want to customize JQuery to include only the AMD modules actually used (as the OP hints at considering), as either one would prevent cache reuse accross sites.
Me, being skeptical of the theory, I still choose to concatenate (I think it's clearly the way to go), and would consider modular customization in the future if it were more convenient for development workflow or it was for a site where size/speed were an absolute priority.
> Me, being skeptical of the theory, I still choose to concatenate (I think it's clearly the way to go)
I have to agree with you. Seeing how my non techy friends use their not high end mobiles, I've decided to go down that road too.
Some of my friends clear cache very frequently, their main point is that images take too much room and this slows device down. Knowing that this is not the case and cheap phones just are slow, they pretty much defeat the whole purpose of cache. I've found that the only way to make web faster for them is to concatenate everything.
I did some research on this a few years ago [1], and Steve Souders recently re-ran the test with the latest http archive data [2]. Given the percentages, I'm still not convinced that it makes sense to reference jQuery or any other library from a shared CDN.
That said, you also need to be careful with concatenation. It's tempting to go for a 'concatenate everything into one file' approach, but that can be suboptimal. When you've got a large library like jQuery that changes infrequently, concatenating that with your constantly-evolving application code results in your users paying the download cost for jQuery every time you make a change (albeit without the connection overhead). Instead, it make sense for some applications to bundle third party libraries into one file, and the application code into another.
As I said in my original article, the most important thing you can do to improve the performance of your site is to measure client-side performance from your real user traffic, establish a baseline and only then try various techniques and see which ones have the greatest impact for your site and your visitors. There are various techniques that /might/ help, and some are more universal than others, but you won't know for sure if a change helped or hindered if you can't look at your stats.
And to throw another cargo-culty idea into the mix: If you load resources from multiple domains it will lower your Google pagespeed (and YSlow) score. Which can negatively affect your pagerank. So they say. Another point for the "concatenate everything" team.
FWIW, this is the approach that I use. And I probably care about those pagespeed and yslow numbers probably way more than I should.
hm.. its been a while since I've investigated the issue. However, I don't think this is the case if the JS is loaded asynchronously faster than the rest of the page. I mean what is JQuery, like 20KB?
In my experience, JQuery is downloaded faster than most analytics tags/logic.
Why does loading from multiple domains lower pagespeed score? Wouldn't loading from multiple domains in parallel improve load time and thus improve pagespeed score?
The big issue here on mobile isn't caching, but that unless you've absolutely nailed the caching headers (and omitted! etags), the phone will still burn an entire RTT on checking the file. If the only people you serve are in SF or NYC, that's probably fine. If you want to target anyone anywhere else on earth, get rid of that wasted RTT.
Or you could be in a situation where you are trying to demo an app to investors, and you find you don't have proper access to wifi.
Or your adsl comes down and you find that over the spotty 3g your app suddenly takes 30s+ just to come up with an error message just due to the google fonts you used.
Those two are JUST personal experience in the last 6 months. Last time I brought this up publicly somebody mentioned that most CDN's are blocked in China too.
Given my past experience, I can think of no possible benefit that can make the additional fragility introduced in my systems worthwhile.
I'm not using CDN's for anything more than the odd jsfiddle in the future.
If the point is to perform dead code elimination, why would you declare it as an extern? It seems reasonable to me to just treat it as another of your javascript files to be included in the compilation run.
its a tad more complex that you would imagine from the get go. Certain coding patterns don't work well with closure; for example obj["name"] = a and elsewhere obj.name will cause issues.
Of course it would make a lot of sense if they simply wrote it for AO, but I doubt that will happen.
tldr: The reason people pull it as an extern is because it does not work with advanced optimisations.
This post is asking the wrong question. Steve Souders (someone help me find the reference) from Google has done some measurement a few years back and concluded that you pretty much should just concat and minify every script into one file for mobile and forget about serving multiple scripts from a CDN. Setting up a connection and the latency involved on mobile is what's killing first load speed.
Having that said, the problem isn't that jQuery is too big for mobile. Lots of things incur a largish download size for mobile. Bootstrap's ginormous CSS bundle first comes to mind. The biggest headache with jQuery on mobile is that it's too damn slow in execution. On a tablet where you have tons of screen space to display lots of widgets, creating largish amount (> 200) jQuery contexts can easily kill your frame rate to something < 10fps.
Too big, a bit slow. The issue is the compressed file size. It's still huge (81kb) and mobile user will notice if your combined web app JS size goes beyond 200kb (speaking about mobile on Edge network, latency). It also slows down your web app, check out: http://jsperf.com/popular#all-time
I think that last question needs to be "do you really need jQuery in 2014 on mobile?"
If we're talking mobile, then chances are you can do without jQuery. You can almost take for granted that the mobile device has a webkit-based browser. Yes, I say that knowing that there are non-webkit browsers in use and that some browsers are based on older webkit code.
If we're talking about non-mobile users across the spectrum of browsers, I would recommend still using jQuery. It's just too useful in dealing with browser inconsistencies and bugs not to use it.
I don't a lot of web dev myself, but when I do I tend to stick with Bootstrap / Node.js / Jade / JQuery because all those things make stuff easier.
I could well be adding a bunch of crap to my pages that I don't need. What do proper web devs use for profiling their web sites? To test page size in bytes, amount of JavaScript you've loaded in libs that you don't use, etc.?
One of the assumptions made by this article is that the user in question is loading your web page with jQuery on a mobile device running on a 4G network. In reality, however, it is unlikely that a user will be on a 4G network. In 2004, the 4G penetration is 25% in North America, and only 3% in Western Europe. [1] It's certainly growing on a yearly basis, but it's still not at the point where you can rely on users having 4G speeds on a mobile device.
The 4G worst-case scenario is still better than the best-case scenario for a 3G network, which is what you'll see with a majority of users. I'd like to see this analysis done with a 3G connection as well, because I suspect the real jQuery tax for a majority of mobile users is over a second.
I do like the point made about latency and the suggestions at the bottom of the article. It's a strong incentive for apps to introduce a real asset pipeline and js and css minifiers.
4G and 3G often falls back to Edge (or even GPRS with bad latency) in Europe. And with Edge you better make sure your JS file is smaller than 200kb (for a web app), otherwise your mobile user with Edge connection will have to wait some seconds (load time). jQuery itself is already 81kb (compressed).
1Mbsp == "worst mobile networks"? Maybe if your website is a social network for US millionaires :-P. What if your visitors are from around the world? Here in Croatia, we don't even have 3G in some parts of the country.
It seems like their answer to this question is "no", but that's hard to understand when I see this quote from the same article:
> But let’s get back to the numbers. Per the data above, a typical user on an average device and network will take ~50ms to download jQuery and another ~250ms to parse it.
An average delay of 300ms is simply unacceptable. I have a hard time believing that 50ms to download jQuery is average, so I assume that the author isn't including round-trip time.
To be fair, this is also from the article:
> And in my opinion, the painfully slow parsing and interpretation of scripts on mobile browsers – particularly older Android ones – is the only compelling reason to prefer tiny JavaScript libraries.
It's the author's opinion that this is the only compelling reason, but it is a VERY compelling reason.
I don't think the author understands how TCP works - the claim that jQuery takes "229ms to download on the worst mobile networks (1Mbsp)" completely ignores latency and TCP slow-start.
Even with a initial congestion window of 10 segments there's going to be at least two round trips, if the window is smaller then it's going to me more.
Using devtools on my office network connection it takes 1.3s to download jQuery from the site with the post
Not a Web guy here: why do people use <script src="foo.js" /> instead of just including the code inline in the script tag?
I understand that as a dev you definitely want your JS in separate files for practical reasons, but couldn't you just have separate .js files and have your framework stick them inline "at runtime"?
PS: Is there any talk with HTTP 2.0 of allowing data like images to be somehow "inlined"? It would then be possible to serve up a 21st century website with a single RTT, right
If the code is inside the script tag, it has to be downloaded with each page. If it's a separate file, it only has to be downloaded once, when the first page is loaded.
If I use foo.js, when the user reload the page, or goes to another page that also uses foo.js, the javascript file is in his cache and he won't need to re-download it. Given the size some of those js are, it makes a significant decrease. Especially in the mobile context this article talks about, when I visit my parents my phone's data connection is slow enough that 40kb of js make a huge difference.
Of course, that also needs a properly configured server (a very large number of sites out there don't see proper client caching so the browser still need to ask the server if the file has changed every single time, for example).
Doing that would be adding filesize to the request, so the amount of time to show "something" would be increased. It would also make it harder to cache your scripts (maybe using session + localstorage :/). Can't comment on http 2.0.
Nice article. Good to finally see some numbers instead of people parroting that 'jQuery is slow' without any evidence. It's clear that you should worry more about latency and parsing time than the actual library size.
57 comments
[ 3.1 ms ] story [ 112 ms ] threadDisclosure: I'm rebuilding a pretty big BackboneJS app (which I started building two years ago with a team that grew to two dozen people) into an AngularJS-based mobile webapp.
Note also that AngularJS is a whopping 700 KB before minification and gzipping (270 KB minified/gzipped).
Here is the file http://code.angularjs.org/1.2.14/angular.min.js And here you can get the gzipped size http://closure-compiler.appspot.com/home
The key thing to remember is that your time as a developer should be spent making software that the user will enjoy using - your job is not to make your own life as easy as possible by throwing in libraries with no thought about how it'll affect the user experience. Learn a build tool and use it to optimise your web apps.
Unfortunately, we encountered a lot of bugs, inconsistencies with the jQuery API and general lack of interest in supporting IE. Somewhere halfway through the project we switched to jQuery and we didn't have any performance problems. Some things actually worked better because jQuery has better workarounds for some of the bugs in older Android browsers.
> Don’t forget that if you’re loading jQuery from a common CDN like Google’s or Microsoft’s, you’re likely introducing zero network latency as the browser will almost certainly have it cached already.
This claim is frequently made, but I’ve also seen many people express skepticism of it. The many different versions of jquery, and several different CDNs, combined with actual typical user behavior patterns, the limited cache capacity of some mobile environments, etc…. it MAY still be true, but I’d really want to see some evidence one way or another before assuming it either way.
It’s not an easy thing to measure though, because we are making claims about “most people’s browsers”, and there’s no easy way to measure other peoples browsers. But is anyone aware of anyone trying to approach it?
Why does it matter? If the "cached in most people's browsers" theory is true, then we would not want to concatenate JQuery into one big JS file (as the OP suggests), and we would not want to customize JQuery to include only the AMD modules actually used (as the OP hints at considering), as either one would prevent cache reuse accross sites.
Me, being skeptical of the theory, I still choose to concatenate (I think it's clearly the way to go), and would consider modular customization in the future if it were more convenient for development workflow or it was for a site where size/speed were an absolute priority.
I have to agree with you. Seeing how my non techy friends use their not high end mobiles, I've decided to go down that road too.
Some of my friends clear cache very frequently, their main point is that images take too much room and this slows device down. Knowing that this is not the case and cheap phones just are slow, they pretty much defeat the whole purpose of cache. I've found that the only way to make web faster for them is to concatenate everything.
That said, you also need to be careful with concatenation. It's tempting to go for a 'concatenate everything into one file' approach, but that can be suboptimal. When you've got a large library like jQuery that changes infrequently, concatenating that with your constantly-evolving application code results in your users paying the download cost for jQuery every time you make a change (albeit without the connection overhead). Instead, it make sense for some applications to bundle third party libraries into one file, and the application code into another.
As I said in my original article, the most important thing you can do to improve the performance of your site is to measure client-side performance from your real user traffic, establish a baseline and only then try various techniques and see which ones have the greatest impact for your site and your visitors. There are various techniques that /might/ help, and some are more universal than others, but you won't know for sure if a change helped or hindered if you can't look at your stats.
[1] http://statichtml.com/2011/google-ajax-libraries-caching.htm... [2] http://www.stevesouders.com/blog/2013/03/18/http-archive-jqu...
FWIW, this is the approach that I use. And I probably care about those pagespeed and yslow numbers probably way more than I should.
This greatly depends on the rest of your content.
In my experience, JQuery is downloaded faster than most analytics tags/logic.
Or your adsl comes down and you find that over the spotty 3g your app suddenly takes 30s+ just to come up with an error message just due to the google fonts you used.
Those two are JUST personal experience in the last 6 months. Last time I brought this up publicly somebody mentioned that most CDN's are blocked in China too.
Given my past experience, I can think of no possible benefit that can make the additional fragility introduced in my systems worthwhile.
I'm not using CDN's for anything more than the odd jsfiddle in the future.
https://developers.google.com/closure/compiler/docs/api-tuto...
tldr: The reason people pull it as an extern is because it does not work with advanced optimisations.
Having that said, the problem isn't that jQuery is too big for mobile. Lots of things incur a largish download size for mobile. Bootstrap's ginormous CSS bundle first comes to mind. The biggest headache with jQuery on mobile is that it's too damn slow in execution. On a tablet where you have tons of screen space to display lots of widgets, creating largish amount (> 200) jQuery contexts can easily kill your frame rate to something < 10fps.
Edit: added "on mobile" in the last question
If we're talking mobile, then chances are you can do without jQuery. You can almost take for granted that the mobile device has a webkit-based browser. Yes, I say that knowing that there are non-webkit browsers in use and that some browsers are based on older webkit code.
If we're talking about non-mobile users across the spectrum of browsers, I would recommend still using jQuery. It's just too useful in dealing with browser inconsistencies and bugs not to use it.
I could well be adding a bunch of crap to my pages that I don't need. What do proper web devs use for profiling their web sites? To test page size in bytes, amount of JavaScript you've loaded in libs that you don't use, etc.?
The 4G worst-case scenario is still better than the best-case scenario for a 3G network, which is what you'll see with a majority of users. I'd like to see this analysis done with a 3G connection as well, because I suspect the real jQuery tax for a majority of mobile users is over a second.
I do like the point made about latency and the suggestions at the bottom of the article. It's a strong incentive for apps to introduce a real asset pipeline and js and css minifiers.
[1] http://graphics.wsj.com/4g-european-investment/
> But let’s get back to the numbers. Per the data above, a typical user on an average device and network will take ~50ms to download jQuery and another ~250ms to parse it.
An average delay of 300ms is simply unacceptable. I have a hard time believing that 50ms to download jQuery is average, so I assume that the author isn't including round-trip time.
To be fair, this is also from the article:
> And in my opinion, the painfully slow parsing and interpretation of scripts on mobile browsers – particularly older Android ones – is the only compelling reason to prefer tiny JavaScript libraries.
It's the author's opinion that this is the only compelling reason, but it is a VERY compelling reason.
Even with a initial congestion window of 10 segments there's going to be at least two round trips, if the window is smaller then it's going to me more.
Using devtools on my office network connection it takes 1.3s to download jQuery from the site with the post
I understand that as a dev you definitely want your JS in separate files for practical reasons, but couldn't you just have separate .js files and have your framework stick them inline "at runtime"?
PS: Is there any talk with HTTP 2.0 of allowing data like images to be somehow "inlined"? It would then be possible to serve up a 21st century website with a single RTT, right
Of course, that also needs a properly configured server (a very large number of sites out there don't see proper client caching so the browser still need to ask the server if the file has changed every single time, for example).
The real issue is design decisions, jq's not incredibly light, but at least there is some real value in it.
Those numbers on avg web page size and rts are atrocious, people should be ashamed of themselves.