I skimmed trough your JavaScript code and basically all you do is AJAX requests. Everything else could be written with same amount pure-JS (and some polyfills for older IEs). Now jQuery is ~32kB gzipped. For AJAX you could use for example https://github.com/visionmedia/superagent which is only 3kB when gzipped.
As for library evaluation speed I mixed up some test cases (http://jsperf.com/jquery-vs-superagent). Bear in mind, that even tough jQuery can be cached, it needs to be reexecuted from scratch for EVERY load. So you can think that every load is counting 2*2 for 1 million times. Waste of processing power, isn't it?
On side note it is pretty hard to write Javascript that IE is willing to execute.
Will it make a big difference? Obviously a lighter version of jQuery is fewer bytes to download. But then again, there's no Google CDN to use maybe and because the Google CDN URL for jQuery is the same across different sites people who visit my site might already have it in cache.
The question is, does loading big standard jQuery result in excessive amounts of Javascript executions? That might really matter on a mobile device. Perhaps more so than saving 10Kb.
So because on an average computer it can only do it 250 times per second it's an issue...
This is typically one of those cases of optimization where it's not necessary. Saving 4ms on a request isn't going to change the users experience. In fact, if you have a high concurrent amount of users, transmitting that small library from your own servers would probably cause more delay than 50 page loads combined, and it might even influence the concurrency. (Of course, this is just as minor and neglectable as the 4ms it takes to load jQuery.)
Think about the whole picture, before talking about optimizing. In fact, there are sites that load slow, because they're built to serve 10K requests per second to all people, if they'd optimize the experience for each individual person, the page might load half a second faster, but only 2K requests could be handled per second.
Comment
I skimmed trough your JavaScript code and basically all you do is AJAX requests. Everything else could be written with same amount pure-JS (and some polyfills for older IEs).
Now jQuery is ~32kB gzipped. For AJAX you could use for example https://github.com/visionmedia/superagent which is only 3kB when gzipped.
As for library evaluation speed I mixed up some test cases (http://jsperf.com/jquery-vs-superagent).
Bear in mind, that even tough jQuery can be cached, it needs to be reexecuted from scratch for EVERY load. So you can think that every load is counting 2*2 for 1 million times. Waste of processing power, isn't it?
On side note it is pretty hard to write Javascript that IE is willing to execute.
Parent comment
Will it make a big difference? Obviously a lighter version of jQuery is fewer bytes to download. But then again, there's no Google CDN to use maybe and because the Google CDN URL for jQuery is the same across different sites people who visit my site might already have it in cache. The question is, does loading big standard jQuery result in excessive amounts of Javascript executions? That might really matter on a mobile device. Perhaps more so than saving 10Kb.
Replies
So because on an average computer it can only do it 250 times per second it's an issue...
This is typically one of those cases of optimization where it's not necessary. Saving 4ms on a request isn't going to change the users experience. In fact, if you have a high concurrent amount of users, transmitting that small library from your own servers would probably cause more delay than 50 page loads combined, and it might even influence the concurrency. (Of course, this is just as minor and neglectable as the 4ms it takes to load jQuery.)
Think about the whole picture, before talking about optimizing. In fact, there are sites that load slow, because they're built to serve 10K requests per second to all people, if they'd optimize the experience for each individual person, the page might load half a second faster, but only 2K requests could be handled per second.