Month: July 2007

All it took was some open flattery.

Powered by ScribeFire.

Mahalo, I’m not sure I totally get what you’re doing just yet.  However, it seems to be really close to what about is doing, except maybe with a different take on how to go about it.

So, if that’s any indication, your results will rank well in google, and when I use google to search for things, you’ll show up high.  If that’s the case, please, please, please don’t be like about.

I really don’t like about.com, and I’d love it if they just dropped out of the rankings.  Their articles are usually low quality, and I end up wishing I hadn’t clicked.

When you’re building Mahalo, please, don’t be another ABOUT.

Powered by ScribeFire.

I kinda decided to go to law school so that I could say something like this and be taken seriously.

Not completely, but many lawmakers don’t understand technology, and often, they make bad laws because of this. (Well, either it’s because they don’t understand it or because of pervasive corruption. See Lessig.)

I don’t care if things run slow.  I can wait 5, 10, 15 more minutes for something to encode.

I want my user interface to be fast.

I want my windows to move around fast, and I want to switch programs quickly.  When I click on menus, I don’t want to wait for disk access to do basic menus.

Biggest offender:  Windows XP Start menu — why the hell do you hit my disk when I click start->all programs?  It would take so little to cache that.

More on optimization now. I’ve gone from running on a super low end VPS to one that has much more resources. Therefore, I’m not under the same extreme memory limitations I once was (although I’m unsuccessfully trying to migrate tomcat+axis to a 512 openvz server for another project).

So, what’s this about? CPU cycles are cheap. RAM costs a bit more. Bandwidth is … well, it’s cheap too, but bandwidth requirements rise with usage higher than the other two. This isn’t a hard and fast rule, but there’s a “high Y intercept” for memory requirements. With ram, you can’t run an application at all without it. However, with bandwidth, if you have zero users, you use (almost) zero bandwidth.

So, now I’m going to talk about two sites I run. UrbanPug.com and Resizr.com. Urban Pug is a simple pug focused blog that I recently redesigned. Resizr is an image resizing web application. A REALLY simple web app that resizes and crops images. It also offers image hosting, send-via-email, and send-via-SMS. With Urban Pug, the bandwidth gets consumed by lots of people looking at pictures of my dogs. With resizr, well, free image hosting. That takes up bandwidth.

So what do I do to optimize the sites?

1) Make sure all your images are fully compressed.

This first one is super important. I feel a little ignorant for having just discovered this, but Photoshop includes ICC color profiles in JPG files. I recently found that I had created the Urban Pug redesign with 14 62×62 jpeg files that were 25k each. Most of that was extraneous data. The solution is to use photoshop’s “save to web” function. Alternatively, but EVEN BETTER THAN THAT is something I found called littleutils that takes advantage of several other programs / libraries (jpegtran, pngcrush, etc) to give you some pretty kickass image compression. In almost every case, littleutils / jpegtran / pngcrush has been able to reduce the size of the files i’ve been serving. Also, in just about every case, i’ve been able to LOSSLESSLY reduce the size of files saved by photoshop (using “save to web”) by another 1-2 KB.

What’s even better about this is that the littleutils “opt-jpg” script will work in batch. I was able to save a couple hundred megs of disk space on my server (hey, i’ve got a 10 gig limit and i’m pushing it)

Message to take: make sure your images are as compressed as they can be w/o losing quality.

2) Use mod_gzip or the like.

Use something like mod_gzip which can automatically compress outgoing text. Can’t wait til there is support for mod_7zip.

3) Compress your css.

Big CSS files get loaded by every user. This can add up, even with mod_gzip. If you want to help things you, you can use a CSS compressor. When you read this, you might not see CSS as the problem. However, at some point, you’ll thank me!

4) Check what’s causing the problem!

Use the tried and true optimization technique. CHECK AND SEE. Here’s a really simple php shell script I wrote to check my access.log for what’s going on. I’m not guaranteeing it will work for you, but if you want to check it out, try it! (view script here)

Work on the biggest problems first. Optimize what you can, rinse, repeat. After some time goes by, you’ll optimize away everything you can.

5) Let hotlinkers link? But… ?

With resizr.com, I give people free image hosting for their resized images. I let people hotlink. However, this adds up. Here’s what I do to help with the bandwidth.

1. I have a PHP script that reads and recompresses images on the fly. I use mod_rewrite to hide this.
2. I tell the difference via a time sensitive password hash technique. Basically, PHP scripts can send “image” HTTP headers. This means that a browser will display a PHP file as an image if you do things right. You can pass GET variables into a php file that’s being displayed as an image. If you make the script require a password via HTTP GET that is varied based on a secret key plus the time plus some salt, you get something that works pretty well.
3. I give viewers of images who are ON my site, a high quality image. I
   give hotlinkers a lesser quality image that has a black box / watermark. I tell the difference based on the password technique just above.
4. Hotlinked images are displayed w/ added “black boxes” that tell people to come to my site. I don’t mind serving up a high quality image that uses bandwidth, but I can’t do it for free, ya know? When people actually come to my site, I can show them CPM ads and recover the costs. For an example of this, check out these hot chicks on myspace that apparently use resizr (and were using lots of bandwidth before I did all this optimization!)

I hope these tips help!