For most database-driven applications though the real latency is almost always in the database. You really need something like memcached to totally remove the bottleneck. I think oftentimes frontend speed demons are trying to answer the wrong question.
Realistically, though, basic client-side optimization (e.g. expires headers, minification and concatenation, unobtrusive javascript) is low-hanging performance fruit that can make a website seem a lot faster with very little work. Since, tuning a database-driven app takes a lot more skill and time, and most people haven't even done the client-side stuff, Google focuses on that.
(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.)
a lot of web sites and apps that depend on the database are aware that this is the bottleneck and optimize for that without giving the front end much consideration.
go look at the waterfall chart for techcrunch.com and tell me where you think their problem is.
Total time I've spent on front end performance in four years: maybe six hours if that.
This is one of those things whose ROI is so staggeringly high that not doing it is just wrong. It is like source control.
Figuring out how to make the page appear to load faster or how to encourage browsers to cache your files in a smarter way is quite a bit more complicated and subtle.
My main point is that the database and queries to it usually has much lower-hanging fruit for speed hacks.
Also, I can make the status bar say "Done" before my page is actually finished loading.