On Tue, Mar 18, 2008 at 7:13 AM, DanTMan <dan_the_man(a)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.