jQuery core and its 20KB limit

April 3rd, 2007 by admin

Triggered by recent code size discussions in the jQuery community, I’ve thought a little bit more about the “all dancing all singing 20KB jQuery core limit” which is often stated. You have not heard about this until now? Well, for acceptable reasons jQuery core is meant to be not larger than 20KB and to still reach this goal people optimize the jQuery core code by single characters — even if it IMHO sometimes obscures the code to some extend.

First, the “packer” compressed jQuery SVN as of today is 20961 bytes which actually is 20.46KB. Well, I’m personally fine with this. But I’m personally also fine with a jQuery of 30KB or even 40KB in size — as long as great functionality and stability is provided. And I can image that most people also care more about other factors than about a few KB more or less.

But, ok, that’s just my personal opinion. So, let’s assume for the moment of this monolog that the download size is really the ultimative goal of jQuery and EVERY byte really counts. But, if this is the case, why to the hell 20(!) KB? I mean, 20KB is not even a multiple of any usual network MTU (we have 1500 for Ethernet and a little bit less for DSL connections because of PPTP or PPPoE overheads, etc)!?

So, let’s overplay my point here with an example: if we assume on average a maximum MTU of 1492 (which is the case under PPPoE for most DSL connections), a jQuery with exactly 20KB is 20480 bytes. Now, 20480/1492 is 13.72, which means that on downloading jQuery core one wastes 0.28 MTUs which in this example would be about 417 bytes. So, a jQuery core optimized by reducing as much single code characters as possible just to reach 20KB in practice could mean that the whole effort is totally useless as one still would have left about 417 bytes until the download performance would change at all.

What does this mean? Well, as the MTU differs for each client, jQuery on average would waste about half an MTU — and this way about half a KB — anyway, independent how hard one tries to be below a particular limit. So, IMHO fixating a particular limit to a number which is not a multiple of average MTUs and even counting single bytes is a factor 10 or even 100 overshoot the mark. At least if at the same time the code becomes harder to understand or perhaps some functionality or robustness even lost.

That’s why I was so extremely surprised these days when I was told that in jQuery core the regular expression "?'? (for matching the opening quotation in a selector expression) should be better not replaced with more correct ["']?, because the first is 4 characters and the second 5 characters and hence 1 character is wasted.

BUT PLEASE NOTICE: This musing is really not meant as an offense of any type to John Resig or any other of the really excellent jQuery developers. I just couldn’t resist to write down my musings on this “20KB jQuery core limit” and perhaps my thoughts at least lets others understand that sometimes doing byte counting to reach a particular limit can mean really nothing in practice as any particular optimization goal could be easily destroyed by other factors.

My hope is that the excellent jQuery is still kept as small as possible but not at the ultimate cost of obscuring the code or not allowing new core functionalities, as IMHO here one overshoots the mark.

2 Responses to “jQuery core and its 20KB limit”

  1. Edwin Martin says:

    Remember that:
    1) With HTTP keep-alive, the data will be “streamed” to the browser, so the JS-lib is send together with other data, so the size of the lib doesn’t really matter.
    2) With a file also comes the HTTP-header, which you also have to take into account.

    T think 20k is the right balance between data overhead and functionality. Do you want more, then you have to use plugins.

  2. Ralf S. Engelschall says:

    Edwin Martin: Oh, good catch. Yes, you’re right. We have the HTTP protocol overhead, too. I totally forgot this. Well, actually we also have the IP, TCP and HTTP overhead, of course. Yes, fully agreed. Nevetheless, independent of those back and forth calculations, my point is that it seems a little bit unbalanced to me to count single bytes on the one hand while at the same other hand we are faced with all those bucket wastes in the KB area. Not to mention the fact that on an average styled web page the most prominent downloads certainly are the embedded images. But as I said, I don’t want to be offensive to anyone on this point. I’m cool with the fact that people like John Resig try such extremely hard to optimize jQuery. I’m just asking myself whether this single byte counting isn’t a little bit too much overshoot the mark when we take all those related factors into account, too…

Leave a Reply