Incidentally, how is HN for speed?
The front page loads with 10 HTTP requests on an empty cache, and doesn't have any user-perceptible blockage while waiting on elements. (Pulled this straight out of YSlow.)
Improvement is overkill, but if you wanted to:
1) Creates images{1,2}.ycombinator.com and split y18.gif, s.gif, and grayarrow.gif, and your JS and CSS files across the three domains. This will cause older browsers to load them all in parallel. (The HTTP spec suggests having no more than 2 requests to any one domain open at a time, so you end up with stairstep loading graphs on browsers which are spec-compliant, such as IE6. Browsers which have a more pragmatic view towards compliance with published specifications, such as Firefox 3, will do 8 ~ 10 requests in parallel.)
Note the balancing act in that every domain you add is another DNS query that needs to get resolved once. Ideally you want to keep it to about 4 domains or less.
2) Put far future expires headers on your static assets. You can bust caches by using the Rails-y filename.js?timestampOfLastModificationOfCode method.
But, again, this site is probably the fastest one I use on a regular basis, even from braindead clients like my Kindle. I wouldn't guess the marginal improvement is worth the expensive engineer time.
a) The CSS file should be inline.
b) The images should be done away with entirely by including them as a data uri.
c) For IE6-7 (data uris not supported) the fallback image should be sprited.
d) For bonus points (if you want HN to be served nearly instantly, globally) splurge for an application caching CDN provider like Akamai.
I could fix this by only loading stuff the moment I need to display it. Right now I load enough to generate 7 pages of threads, but people rarely click on the More link, so I'm dragging a lot of items into memory unnecessarily.
I'll try fixing this when I have time. Unfortunately I have to write a talk right now, and this is going to require turning some code inside out.
When logged in, most things take a few seconds to load. I find myself opening things in new tabs and waiting to come back to them.
Threads, comments, all take a long time to load and often timeout.
Making a mistake in a comment costs 5-10 seconds, since you'll have to click on [edit].
Usable, but only just.
Aside from the threads issue everyone else has mentioned, I've noticed that apart from the main HTML, the co2stats tracker is the only part of the site that doesn't have proper cache-control headers and thus incurs a query every time (resulting in a 200 OK, not a 304 Not Modified, say); worse, the javascript portion can also take a while to load (up to 2 seconds), even though the returned content never actually seems to change. The co2stats image also never is cached. You should probably prod them to fix that (they're YC funded, right?).
But perhaps that is just me. My use pattern here is at the extreme end of the distribution.
Not that I/we don't appreciate everything you do. I mean, this whole site is an act of charity so I guess I expect some bugs.
Also, I thought I remember a problem with reverse proxies and the hacker news server? Can't remember the specifics though.
When replying, often I'm returned to a random page instead of the one in the whence parameter. After making this comment, I was redirected to /threads?id=pg instead of to /item?id=1243793
The markup in comment threads is extremely broken in Mobile Safari -- font sizes change randomly, sometimes some of the vote arrows will randomly be huge or teeny-tiny.
Using Image() to generate GET requests for the vote links is at the very least stupid if not a bug, you should be making a POST using XHR -- and then you could get the new vote total in the response instead of mindlessly incr/decr-ementing the number in the DOM.