Well... Readability is important -- when you're planning to maintain the thing!
But do you think you're going to?
I was looking for similar software, thanks for pointing to it. I manually passed all of the getid3 files to it, stripping comments and whitespace (but not doc comments because getid3 uses this in its parser... Geeky for sure, but a horrible way of doing things!), and keeping just the header comment.
Normal version: 702kb, zips to 133kb
Minified version: 522kb, zips to 98kb
Not bad...! Although I'll have to test it, I guess... It's an interesting alternative, and it only took 15 minutes or so to convert all of the files. Something I *can* do on each major release for sure...
Okay, speaking about minification. I've been thinking about many things...
- doing on-the-fly minification (i.e. not cached...) on inline JS and CSS. Do you think it's realistic? I'm not sure myself, but I could cook up a simplified minification function, although I wouldn't know how to deal with strings. Hmm. Still, just as an example, if I manually minify the noi_resize() code, I save something like 60 to 80 bytes off the page, and a reasonable ~20 bytes when gzipped. Considered it's to be found on every single page...
- media cache: I'm always tempted to add a htaccess for the media folder, just so I don't get the pagespeed warning when it can't find a far-future expiration date. Problem is -- if you replace the files with a newer version, if the files have the same name, then the generated name has the same name as well. And that's only for thumbnails... Previews and full pics are accessed through PHP, so I can't "regenerate" a new filename for them, it won't help at all.
Need I worry about caching media items at all...?
- considering using YepNope to load jQuery and subsequent code. YepNope is 1.6kb minified and gzipped, so it's not exactly super-light, but at least it would trick pagespeed into thinking no other JS is executed at page load time, so I'd be likelier to get it to a perfect score... Main problem is, I doubt I'll be saving any time here. The only 'big' script we have to load is jQuery, the rest is negligible (except maybe for script+theme). At best, jQuery will load in parallel while YN is loading other JS files, and thus will be able to execute everything at the same time instead of waiting to load script+theme and other scripts after jQ is loaded. Still, if jQ is integrated into the main local file, it's even more pointless. At worst, YN wastes time executing itself when both jQ and local scripts are already cached... :-/
- Considering using "FileETag none" in all htaccess files. I'm not a specialist though... But as soon as we have an expiration date, ETags aren't useful at all. I'm not sure if it should be done for all files.
- IP packets carry the cookie, as everyone knows. My question would be, does it carry it only in the first packet of the page, or on every single freakin' packet? In which case it'd be in our interest to make cookie size as small as possible...
- I noticed that by default, avatars are loaded into the attachment folder. I *know* AeMe will change the entire system, but since I still don't know when I'll deal with this, I'd like us to consider creating a 'custom' folder in /avatars/ and upload all avatars there by default -- and obviously, set Wedge by default to show clear URLs for these avatar images. We save *by default* as many HTTP requests (to PHP FFS!) as there are avatars on the page.
