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.
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
Minification alone only reduces a file by about 40%. However gzipping
reduces a file by about 70% alone.
When it comes down to it, once you gzip minification can barely even
save you 10% of a file's size. And honestly, that measly 10% is not
worth how badly it screws up the readability of the code.
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.
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.
Gzipping and reducing the number of script tags we use are the only
useful things that can be done to speed up viewing.
~Daniel Friesen (Dantman, Nadir-Seen-Fire)
~Profile/Portfolio:
On Sun, Oct 5, 2008 at 1:00 PM, Gregory Maxwell
<gmaxwell(a)gmail.com> wrote:
The page text is gzipped. CSS/JS are not. Many
of the CSS/JS are
small enough that gzipping would not be a significant win (see above)
but I don't recall the reason the the CSS/JS are not. Is there a
client compatibility issue here?
Some of the CSS/JS *is* gzipped, so there had better not be a client
compatibility issue. Styles/scripts served from index.php are
gzipped, it's only statically-served files that aren't. I'm guessing
this would just require a line or two changed in Apache config.
Hm. There are expire headers on the skin provided images, but not ones
from upload. It does correctly respond with 304 not modified, but a
not-modified is often as time consuming as sending the image.
Looking at the URL, this doesn't seem to identify the version at all,
so we can't safely send an Expires header. I'm guessing we use a
non-versioned URL here to avoid purging parser/Squid caches when a new
image is uploaded. This is probably a losing proposition, except
maybe for very widely used images (but those shouldn't change often?).
But it would be a pain to change.
In any case, from the second page onwards pages
typically display in
<100ms for me, and the cold cache (first page) load time for me looks
like it's about 230ms, which is also not bad. The grade 'f' is hardly
deserved.
I've found that YSlow is kind of flaky in its grades. Some of its
advice is fairly brainless. But there's definitely room for
improvement on our part -- gzipping stuff at the very least!
On Sun, Oct 5, 2008 at 3:52 PM, Gregory Maxwell <gmaxwell(a)gmail.com> wrote:
Compare the gzipped sizes. Post gzipping the
savings from whitespace
removal and friends is much smaller. Yet it makes the JS unreadable
and makes debugging into a pain.
What I was thinking (not that the idea is original to me :P) is that
we could have all JS and all CSS sent from some PHP file, call it
compact.php. So you would have just one script tag and one style tag,
like
<script type="text/javascript"
src="/w/compact.php?type=js&..."></script>
<link rel="stylesheet" type="text/css"
href="/w/compact.php?type=css&..." />
That could concatenate the appropriate files, add on
dynamically-generated stuff, gzip everything, and send it in one
request, with appropriate Expires headers and so on. This would
dramatically cut round-trips (15 total external CSS/JS files
logged-out for me right now, 24 logged-in!).
Round-trips are serialized in modern browsers a lot more than they
should be -- Firefox 3 will stop all other requests while it's
requesting any JS file for some crazy reason (is there a bug open for
that?), and IE is apparently similar. It's even worse with older
browsers, which are unreasonably cautious about how many parallel
requests to send to the same domain.
Once you're already serving all the JS together from a script, you
could minify it with no real extra cost, and prepend a helpful comment
like /* Add &minify=0 to the URL for a human-readable version */.
Minification tends to save a few percent of the original filesize on
top of gzipping (which can be like 20% of the file size after
gzipping), which can make a difference for big scripts. Here are a
couple of examples to illustrate the point (from the O'Reilly book
"High Performance Web Sites", by Steve Souders of Yahoo!):
http://stevesouders.com/hpws/js-large-normal.php
http://stevesouders.com/hpws/js-large-minify.php
I see a saving of a few hundred milliseconds according to those pages
-- and yes, this is after gzipping.
Since this is you, though, I wait to be corrected. :)
If it takes 75ms to get to the nearest Wikimedia
datacenter and back
then a new HTTP get can not finish in less than 150ms. If you want to
improve performance you need to focus on shaving *round trips* rather
than bytes. Byte reduction only saves you round trips if you're able
to reduce the number of TCP windows worth of data, it's quantized and
the lowest threshold is about 8kbytes.
The example above has a script that's 76 KB gzipped, but only 29 KB
minified plus gzipped. On the other hand, the script is three times
as large as the scripts we serve to an anon viewing the main page (377
KB vs. 126 KB ungzipped).
