3 ms·

Without looking I can tell you it's two reasons: 1) It's text based and, therefore, can keep its total response small. 2) The page is cached on the backend so

Without looking I can tell you it's two reasons: 1) It's text based and, therefore, can keep its total response small. 2) The page is cached on the backend so database lookups are kept infrequent and small. Those two reasons alone make it faster than, say, 80% of most web sites.

MichaelGG 11y ago
Non-text sites of old weren't as slow as the current ones. Progressive rendering and not bringing in a MB of JavaScript and fonts and other shit is what makes it fast. HN could easily add images and still stay fast. That this is even a question is just sad. It means the slow web is just accepted. Most web pages aren't particularly more functional than they were 15 years ago. Sure, maybe search boxes have auto-complete. But taking a screenshot to compare output? You could achieve much the same stuff, pixel-per-pixel, back with table-based layout. Yet even though we're running machines over 10x more powerful, things are laggy. It's embarrassing, annoying, and dumb.
klibertp 11y ago
> Without looking You risk being wrong this way. Your #1 is OK, but #2 is false: there's no database (in the sense of RDBMS or NoSQL) behind HN. It's just plain files on disk. Which, of course, makes fetching data blazingly fast, thanks to how filesystems are already handled and cached by the OS. Anyway, I long suspected that "gzip and cache the hell out of your site" is not the best way to go about optimizing websites. From my experience websites come in two flavours: tiny with no need for optimization at all and huge, where you need to optimize everything and you know it's not going to be enough unless you're willing to rewrite some code in C.
- justwannasing 11y ago
  You risk being wrong this way. Unless you are involved in the site and can testify to that. In any case, the page could be, or should be, cached in some form, either on the server or with the browser. Which makes me wonder with your second paragraph. gzipping and caching are the easiest and one of several ways to optimize the downloading of a web page. Server side code written in C plays no part in that except if the pages are created on the fly and anything else really does slow down delivery of the page; that is, page creation takes longer than 80ms or so, but a properly coded site won't let that happen if it can be helped. And after running my own web dev business for 11 years, I didn't have to look at anything to determine any of that.

MichaelGG 11y ago

Non-text sites of old weren't as slow as the current ones. Progressive rendering and not bringing in a MB of JavaScript and fonts and other shit is what makes it fast. HN could easily add images and still stay fast. That this is even a question is just sad. It means the slow web is just accepted. Most web pages aren't particularly more functional than they were 15 years ago. Sure, maybe search boxes have auto-complete. But taking a screenshot to compare output? You could achieve much the same stuff, pixel-per-pixel, back with table-based layout. Yet even though we're running machines over 10x more powerful, things are laggy. It's embarrassing, annoying, and dumb.

klibertp 11y ago

> Without looking You risk being wrong this way. Your #1 is OK, but #2 is false: there's no database (in the sense of RDBMS or NoSQL) behind HN. It's just plain files on disk. Which, of course, makes fetching data blazingly fast, thanks to how filesystems are already handled and cached by the OS. Anyway, I long suspected that "gzip and cache the hell out of your site" is not the best way to go about optimizing websites. From my experience websites come in two flavours: tiny with no need for optimization at all and huge, where you need to optimize everything and you know it's not going to be enough unless you're willing to rewrite some code in C.

justwannasing 11y ago
You risk being wrong this way. Unless you are involved in the site and can testify to that. In any case, the page could be, or should be, cached in some form, either on the server or with the browser. Which makes me wonder with your second paragraph. gzipping and caching are the easiest and one of several ways to optimize the downloading of a web page. Server side code written in C plays no part in that except if the pages are created on the fly and anything else really does slow down delivery of the page; that is, page creation takes longer than 80ms or so, but a properly coded site won't let that happen if it can be helped. And after running my own web dev business for 11 years, I didn't have to look at anything to determine any of that.