Backend tuning also involves a lot of black magic, whereas going down the YSlow checklist and knocking things off will improve your perceived user load speed. If you don't gzip, gzip. Bam. Done. It will work. Tuning the database, on the other hand, crikey -- how many chickens does one have to sacrifice to become an expert DBA anyhow?

I think the DB equivalent of turning on gzip is slapping an index on your primary keys [EDIT: should be "on your primary data column"]. Not exactly expert material, and quite useful.

I am unaware of a commonly used database where primary keys are not indexed by default. Granted, on a good day I can spell SQL correctly, but it was my impression that primary keys imply an index by definition. Can someone rectify my understanding?

Yeah, you're right. Call it slapping an index on the column holding actual data. My bad.

(The reason that primary keys tend to be auto-indexed is simple: to verify uniqueness, you need to check whether the primary key of the record being inserted is already in any record. Doing this without indices would be painfully slow.)

Up to a certain point, lot of backend issues can be mitigated by throwing hardware at the problem. At Torbit we've seen a lot of people realize their site were slow and their first response was to add more servers and upgrade to beefier boxes. By the time we get to them they've got their backend serving up HTML in 200ms but their site still takes 20 seconds to load. More often than not the front-end is the problem.

No, but a request time improvement from 150ms to 50ms could have a demonstrable impact on your bottom line.