

Is jQuery Too Big For Mobile? - remotesynth
http://flippinawesome.org/2014/03/10/is-jquery-too-big-for-mobile/

======
jrochkind1
A comment on the OP says:

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

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

~~~
continuations
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?

~~~
thaumaturgy
This is just a guess (and so a completely worthless comment), but I'd expect
that http pipelining has something to do with it.

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

[1] [http://graphics.wsj.com/4g-european-
investment/](http://graphics.wsj.com/4g-european-investment/)

~~~
frik
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).

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

------
jchrisa
Do yourself a favor and use Zepto, it's already stripped down and you already
know the API [http://zeptojs.com/](http://zeptojs.com/)

~~~
mike-cardwell
Browser support: "Internet Explorer 10+"

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

~~~
mike-cardwell
Worth mentioning that IE8 is the latest version of IE that will run on Windows
XP too.

------
frik

      Is "jQuery Mobile" too slow for mobile? 
    

Slow tap performance, slow overall performance,
[http://www.jquerymobile.com](http://www.jquerymobile.com)

    
    
      Is "jQuery" too slow for mobile?
    

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](http://jsperf.com/popular#all-time)

    
    
      Do you really need "jQuery" in 2014 on mobile? 
    

I would say no. I have recently coded a 30k HTML5 web app that runs on mobile
as fast as native apps. So my advice is to just use native HTML5 JS API, it
works fine. Introduction: [http://www.sitepoint.com/jquery-vs-raw-
javascript-1-dom-form...](http://www.sitepoint.com/jquery-vs-raw-
javascript-1-dom-forms/)

Edit: added "on mobile" in the last question

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

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

~~~
frik
Use a tool that supports "dead code removal". E.g. Google Closure JS compiler
with "ADVANCED_OPTIMIZATIONS" flag:
[https://developers.google.com/closure/compiler/docs/compilat...](https://developers.google.com/closure/compiler/docs/compilation_levels)

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

~~~
youngtaff
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

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

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

~~~
nolok
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).

------
ataggart
Isn't this a tooling issue, namely using something like Google's Closure
Compiler to perform dead-code elimination?

[https://developers.google.com/closure/compiler/docs/api-
tuto...](https://developers.google.com/closure/compiler/docs/api-tutorial3)

~~~
lennel
the problem is that you will still include the whole of jquery given that it
is passed in through an externs file to the compiler.

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

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

------
skrowl
TL;DR - No, it's not too big.

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

------
al2o3cr
Lulz: the CSS file used on the article page is 180kB...

------
the1
yes. for mobile pages, use minimal css and no javascript.

~~~
adamors
Are people still making mobile pages though?

~~~
Cthulhu_
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).

~~~
thepoet
Did you add an extra zero in gzipped size for a previous version ? Current
AngularJS is 36KB minified/gzipped, 100KB minified

Here is the file
[http://code.angularjs.org/1.2.14/angular.min.js](http://code.angularjs.org/1.2.14/angular.min.js)
And here you can get the gzipped size [http://closure-
compiler.appspot.com/home](http://closure-compiler.appspot.com/home)

------
Yuioup
No, but Dojo is.

