No, messed up table since I was using html mode.
wikibits.js non-gz gzipped
full 27.1kb 8.9kb
minified 16.7kb 5.0kb
wp's gen.js non-gz gzipped
full 29.2kb 7.9kb
minified 16.8kb 4.5kb
When not gzipped minification cuts something from 27kb to 16kb, but when
already gzipped down to 8kb it only reduces it to 5kb...
Wikia does something similar to that idea... They have an allinone.js,
and you use &allinone=0 to disable it. But honesly, there are cases
where you use links, or something, or a post request or something else
that can only be done once, you get a js error, and it's a pain to find
out what's going on. Not when it only saves around 4kb.
Minification being pointless when gzipped is actually logical to
understand if you know their principles. Both gzipping and minification
follow the same principle. They take sequences that are repeated, create
an optimized tree, and then store smaller sequences that refer to the
data in that tree.
Once something has been optimized like that, it's almost impossible to
get it any smaller because you've already removed the repeat sequences
of data.
Basically trying to minify then gzip, is like trying to gzip twice, it
can't technically give you much more.
Ohwait, scratch that... ^_^ I'm thinking of js packing...
JS minification doesn't do anything except kill things like
whitespace... That obviously can't save to much.
~Daniel Friesen (Dantman, Nadir-Seen-Fire)
~Profile/Portfolio:
On Sun, Oct 5, 2008 at 6:35 PM, Daniel Friesen
<dan_the_man(a)telus.net> wrote:
I really wish people would stop spreading the
crap about the /benefits/
of minification, while only giving half the information.
Sure, minification does reduce some size in comparison to a full file.
And yes, minification+gzipping does make things insanely small. But that
there is blatantly disregarding something. It's not the minification
that makes min+gz so small, it's the gzipping, in fact once you gzip
trying to minify becomes nearly pointless.
It can cut off a significant amount of extra size on top of gzipping,
as my last post indicated, at least in some cases. It's not "nearly
pointless".
Here's the table for wikibits.js, and
wikipedia's gen.js for anons
(basically monobook.js).
wikibits.js
non-gz
gzipped
full
27.1kb
8.9kb
minified
16.7kb
5.0kb
wp's gen.js
non-gz
gzipped
full
29.2kb
7.9kb
minified
16.8kb
4.5kb
In other words, minification reduces the total size of those two files
from 16.9 KB to 9.5 KB, after gzipping. That's more than 7 KB less.
That's already not pointless, and it's probably only going to become
less and less pointless over time as we use more and more scripts
(which I'm guessing will happen).
And honestly, that measly 10% is not
worth how badly it screws up the readability of the code.
How about my suggestion to begin the code with a comment "/* Append
&minify=0 to the URL for a human-readable version */"?
As for client compatibility. There are some older
browsers that don't
support gzipping properly (notably ie6). We serve gzipped data from the
php scripts, but we only do that after detecting if the browser supports
gzipping or not. So we're not serving gzipped stuff to old browsers like
ie6 that have broken handling of gzip.
The difference with the static stuff is quite simply because it's not as
easy to make a webserver detect gzip compatibility as it is to make a
php script do it.
It should be reasonably easy to do a User-Agent check in Apache
config, shouldn't it?
The limitation in grabbing data in browsers
isn't crazy, the standard is
to restrict to only 2 open http connections for a single hostname.
Yes, which ended up being crazy as the web evolved. :) That's fixed
in recent browsers, though, with heavier parallelization of most
files' loading. But Firefox <= 3 and IE <= 7 will still stop loading
everything else when loading scripts. IE8 and recent WebKit
thankfully no longer do this:
http://blogs.msdn.com/kristoffer/archive/2006/12/22/loading-javascript-fileā¦
http://webkit.org/blog/166/optimizing-page-loading-in-web-browser/