min = YUI Compressor jsmin = JSMin pak = Packer
normal gzipped reduction wikibits.js 40.9 KB 12.1 KB 70.4% wikibits.min.js 25.5 KB 7.1 KB 72.1% reduction 37.6% 41.2% 82.6% wikibits.jsmin.js 26.0 KB 7.3 KB 71.9% reduction 36.4% 39.6% 82.2% wikibits.pak.js 25.5 KB 7.2 KB 71.8% reduction 37.7% 40.5% 82.4%
I may have made a mistake on a few of the percentages (just rounding errors)... But minifying does shave at least 1/4 the size off the file. Additionally, that would grow even more if we decided to document everything inside of wikibits.js nicely in a format we could throw something similar to MW's doxygen through, to get some nice documentation on the JS inside of wikibits. Additionally, as you can see, when gzipped rather than shaving 1/4 the file, we shave nearly 1/2 the file off. And honestly, as noted, we can't send a gzipped file 100% of the time, so having minification is good since we still get some reduction even when the browser does not support gzip. And when it does, we end up with less than 1/5 the size of the original file.
Do remember that also, gziping should improve even more when we group the files together. So file grouping + minification + gzip where possible will result in some astonishing file size differences. (Also, if php has the gzip module setup, I can probably get it to send in gzip when supported... Even if mod_gzip isn't on the webserver.)
Hmmm... multiple includes rather than one file... Ok... but that's going to need a bit more complex logic than before to make sure that dependencies are included in the right order. Additionally I'll have to setup some sort of notion of a dependency tree, where including one thing will make sure that other needed things are included, and that they are included inside the current scope, but not moved to the current scope if they are already included in a broader scope.
Additionally it would probably be best to collapse a few more of those groups together. The final set, in order of load should probably be: - 100% (wikibits, site scripts [libraries wanted for site scripts, or things like sortable or collapse, not common.js], things actively used in articles [ie: SMW, but not TagCloud]) - skin stuff (Any libraries that the skin uses to do dynamic stuff) - per-page (Any library or additionally the actual scripts which pages use, with a dependency chain)
The important notes would be: * Having the Articles set, which was previously included in all, but not special pages, isn't such a good idea unless you are putting it all inside one file. This adds a side scope, and is the most likely case where a dependency issue will arise where either a script will be loaded before the stuff it needs are loaded, or the dependency logic will force an alteration to a more general scope causing multiple variations of them as a result of the dependency logic trying to prevent dependency load issues. So, it would be best to have anything which would be used for articles (which make up most of the views anyways) something that is loaded all the time. * The notion of user includes is similar to article only includes... It's a side scope, and is likely to result in issues with dependency logic for library use cases. So, normal user stuff may end up on it's own... But this will be loaded after everything else, and outside the dependency logic. So it will not support conditionally loading certain JS libraries for user use. If a site wants to let it's user's make user scripts and use those, then it would be best for them to include the libraries they want to let users use inside of the 100% loads group so they are always there for use.
~Daniel Friesen(Dantman) of: -The Gaiapedia (http://gaia.wikia.com) -Wikia ACG on Wikia.com (http://wikia.com/wiki/Wikia_ACG) -and Wiki-Tools.com (http://wiki-tools.com)
Simetrical wrote:
On Tue, Mar 18, 2008 at 7:13 AM, DanTMan dan_the_man@telus.net wrote:
The idea is to have a single script in the page which contains all of the needed JS Libraries... And even wikibits.js inside it... All of them minified to compact space... Of course, if you need to debug any errors or anything, simply reload the page with &allinone=0 and the system automatically includes the separate non-minified files in individual script tags for debugging. Perhaps even a no-allinone preference for those doing heavy debugging in areas where they have a post request they can't add &allinone=0 to.
Maybe. Does anyone have any hard figures on how much good minification actually does, given that the files are being compressed? Even if you tout these extra URL options, where are a pain for developers, every user who reports a JS error will report it as being on line 1 of the file, etc. I'm not convinced it will be worth it if we gzip, especially if we use consistent tab and brace conventions (having "if( " all the time will compress better than sometimes "if( ", sometimes "if (", sometimes "if(", sometimes "if ( ").
I assume compression, though, when we don't seem to be doing it. IE6 apparently has issues with it under some circumstances. http://support.microsoft.com/kb/321722/EN-US/ isn't an issue for wikibits.js and so on, since we rename that when we update it, but it might be an issue for generated CSS/JS. http://support.microsoft.com/default.aspx?scid=kb;en-us;Q312496 is solved in the latest SP for IE6, and anyway seems like it would break the HTML page too. At any rate it should be safe to compress for anything but IE6, unless there are reported problems with IE7 or non-IE browsers. I'm guessing IE6 only accounts for something like 20% or 30% of our traffic by now? This avenue should definitely be looked at before minification, IMO.
The extra HTTP hits are an issue, however, mainly because browsers will only send two HTTP requests at once to the same server. (Some people have gone so far as to host each couple of includes on a different domain.) Combining things into the same file where possible would certainly be a win.
If the example SMW had loaded it's libraries 100% of the time when on articles because of the high use of it... Then there would only be two variations, one for with tag cloud, and one for when it's not...
If a large chunk of included CSS/JS (henceforth, "includes") is needed rarely enough that we don't want to load it on the first view unless necessary, then it would almost certainly be better to include it as a second file in the case when it is needed, not maintain a different version of the file. This allows many fewer bytes to be transferred, assuming that the stock includes will often be cached already, and is large.
In some cases there may be some includes that must *not* be loaded on some page views, particularly skin and user includes. Skin-specific includes should be bundled with wikibits.js, etc., with multiple versions maintained for each skin. User-specific includes that really are different from user to user probably need to be served as a separate file.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l