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.