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: http://nadir-seen-fire.com -The Nadir-Point Group (http://nadir-point.com) --It's Wiki-Tools subgroup (http://wiki-tools.com) --The ElectronicMe project (http://electronic-me.org) -Wikia ACG on Wikia.com (http://wikia.com/wiki/Wikia_ACG) --Animepedia (http://anime.wikia.com) --Narutopedia (http://naruto.wikia.com)
Aryeh Gregor wrote:
On Sun, Oct 5, 2008 at 1:00 PM, Gregory Maxwell gmaxwell@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.
- Add expire header (e.g.
http://upload.wikimedia.org/wikipedia/en/9/9d/Commons-logo-31px.png)
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@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).