7 ms·

Is jQuery Too Big For Mobile?

47 points by remotesynth 13y ago

the1 13y ago
yes. for mobile pages, use minimal css and no javascript.
- adamors 13y ago
  Are people still making mobile pages though?
  - enscr 13y ago
    ? Bootstrap, Foundation are all mobile first ...
    - criswell 13y ago
      I think they're talking about strictly mobile pages.
  - Cthulhu_ 13y ago
    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 13y ago
      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
  - wil421 13y ago
    Not making mobile pages but making pages that are responsive.
- aurumpotest 13y ago
  No JS.. at all?
  - the1 13y ago
    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.
onion2k 13y ago
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 13y ago
Do yourself a favor and use Zepto, it's already stripped down and you already know the API http://zeptojs.com/ http://zeptojs.com/
- Artemis2 13y ago
  Or even TireJS if it fits your needs: http://tirejs.com http://tirejs.com
- mike-cardwell 13y ago
  Browser support: "Internet Explorer 10+"
  - TomAnthony 13y ago
    Yeah - Zepto isn't ideal for a responsive site, but if you're serving something different to mobile then it is great.
    - sjs382 13y ago
      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.
  - Cthulhu_ 13y ago
    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.
  - wil421 13y ago
    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.
skrowl 13y ago
TL;DR - No, it's not too big.
jrochkind1 13y ago
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.
- kivihiinlane 13y ago
  > 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.
- spjwebster 13y ago
  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. [1] http://statichtml.com/2011/google-ajax-libraries-caching.html http://statichtml.com/2011/google-ajax-libraries-caching.htm... [2] http://www.stevesouders.com/blog/2013/03/18/http-archive-jquery/ http://www.stevesouders.com/blog/2013/03/18/http-archive-jqu...
ataggart 13y ago
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-tutorial3 https://developers.google.com/closure/compiler/docs/api-tuto...
- lennel 13y ago
  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 13y ago
    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 13y ago
      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.
wyuenho 13y ago
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.
frik 13y ago
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-forms/ http://www.sitepoint.com/jquery-vs-raw-javascript-1-dom-form... Edit: added "on mobile" in the last question
- talmand 13y ago
  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.
Yuioup 13y ago
No, but Dojo is.
philbarr 13y ago
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 13y ago
  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/compilation_levels https://developers.google.com/closure/compiler/docs/compilat...
Bostwick 13y ago
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 13y ago
  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).
- SimeVidas 13y ago
  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.
sjs382 13y ago
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 13y ago
  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
bjackman 13y ago
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
- tonyblundell 13y ago
  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.
- nolok 13y ago
  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).
- dpweb 13y ago
  Not in-lining the JS keeps a nice separation between your html and js files, but I can see either approach. You can inline imgs now with Data URI. 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.
- albemuth 13y ago
  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.
deleted 13y ago
[deleted]
huskyr 13y ago
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 13y ago
Lulz: the CSS file used on the article page is 180kB...

47 points by remotesynth 13y ago

the1 13y ago

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

adamors 13y ago
Are people still making mobile pages though?
- enscr 13y ago
  ? Bootstrap, Foundation are all mobile first ...
  - criswell 13y ago
    I think they're talking about strictly mobile pages.
- Cthulhu_ 13y ago
  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 13y ago
    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
- wil421 13y ago
  Not making mobile pages but making pages that are responsive.
aurumpotest 13y ago
No JS.. at all?
- the1 13y ago
  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.

onion2k 13y ago

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 13y ago

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

Artemis2 13y ago
Or even TireJS if it fits your needs: http://tirejs.com http://tirejs.com
mike-cardwell 13y ago
Browser support: "Internet Explorer 10+"
- TomAnthony 13y ago
  Yeah - Zepto isn't ideal for a responsive site, but if you're serving something different to mobile then it is great.
  - sjs382 13y ago
    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.
- Cthulhu_ 13y ago
  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.
- wil421 13y ago
  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.

skrowl 13y ago

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

jrochkind1 13y ago

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.

kivihiinlane 13y ago
> 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.
spjwebster 13y ago
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. [1] http://statichtml.com/2011/google-ajax-libraries-caching.html http://statichtml.com/2011/google-ajax-libraries-caching.htm... [2] http://www.stevesouders.com/blog/2013/03/18/http-archive-jquery/ http://www.stevesouders.com/blog/2013/03/18/http-archive-jqu...

ataggart 13y ago

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-tutorial3 https://developers.google.com/closure/compiler/docs/api-tuto...

lennel 13y ago
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 13y ago
  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 13y ago
    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.

wyuenho 13y ago

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.

frik 13y ago

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-forms/ http://www.sitepoint.com/jquery-vs-raw-javascript-1-dom-form... Edit: added "on mobile" in the last question

talmand 13y ago
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.

Yuioup 13y ago

No, but Dojo is.

philbarr 13y ago

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 13y ago
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/compilation_levels https://developers.google.com/closure/compiler/docs/compilat...

Bostwick 13y ago

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 13y ago
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).
SimeVidas 13y ago
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.

sjs382 13y ago

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 13y ago
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

bjackman 13y ago

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

tonyblundell 13y ago
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.
nolok 13y ago
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).
dpweb 13y ago
Not in-lining the JS keeps a nice separation between your html and js files, but I can see either approach. You can inline imgs now with Data URI. 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.
albemuth 13y ago
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.

deleted 13y ago

[deleted]

huskyr 13y ago

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 13y ago

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