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(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.
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l