Solving the Wrong Problem

Occasionally, against my better judgement, I peek into discussion threads about things I’ve written to see what the general vibe is, to see if I’ve made some ridiculous mistake that no one bothered to tell me directly about. The most unexpected comments have been about how quickly this site loads, that most pages involve only two requests—the HTML file and style sheet—for less than ten kilobytes in total, and that this is considered impressive.




Some of that speed is luck. I use shared hosting, and I have no control over what other sites on the same server are doing.




But I’ve also got a clear picture of how people interact with a blog: they read it. With the sole exception of myself, all people do with the prog21 site is grab files and read them. There’s no magic to serving simple, static pages. What’s surprising is that most implementers of blogging software are solving the wrong problems.




An SQL database of entries that can be on-the-fly mapped to themed templates? That’s a solution designed to address issues of blog maintainers, not readers, yet all readers pay the price of slower page loads or not being able to see a page at all after a mention on a high-profile site.




(At one time, the Sieve of Eratosthenes—an algorithm for finding all prime numbers up to a given limit—was a popular benchmark for programming language performance. As an example of raw computation, the Sieve was fine, but suppose you needed a list of the primes less than 8,000 in a performance-sensitive application. Would you bother computing them at run time? Of course not. You already know them. You’d run the program once during development, and that’s that.)




Tracking cookies and Google Analytics scripts? Those solve a problem specific to the site owner: “How can I know exactly how much traffic I’m getting”? Readers don’t care.




Widgets for Google+ and Twitter and Facebook? These don’t solve anyone’s problems. You can tweet easily enough without a special button. Aggregation sites, Google Reader, and even Google search results have the equivalent of “like” buttons, so why duplicate the functionality? More importantly, only a small minority of users bother with these buttons, but all the associated scripting and image fetching slows down page loads for everyone.




(If you liked this, you might enjoy It’s Like That Because It Has Always Been Like That.)