Ask HN: Why and how is Hacker News so fast?
I understand that HN is built on top of Arc (http://arclanguage.org), a Lisp variant, and that the code (https://github.com/wting/hackernews/blob/master/news.arc) uses flat files to store post and vote data. This is generally speaking quite an unusual/unexpected architecture for a site presumed to serve a consistently moderate load, but HN manages to do so remarkably well, presumably because the site itself is so incredibly lightweight. I don't think the minimal HTML is the only factor though, although it probably counts for the majority.
I'm interested to understand as much as possible/practicable/relevant about the server(s') configuration, uplink bandwidth, other tunables, etc, so I can get an idea of what makes HN so exceptionally responsive and "a cut above 99% of everything else". Does CloudFlare really make that much of a difference? :P
I know there's some "secret sauce" in there somewhere, because virtually-verbatim clones of HN such as http://firespotting.com/ seem almost as fast... but just not as instantaneous as HN.
(PS: On the occasions I get hit by it, my ISP's shaping config seems quite involved/nuanced, and I actually want to profile it because it's so catalyzing and would be very useful to apply to my own projects for "worst-case" testing. For the interested, the details I have thus far can be found here: http://serverfault.com/questions/709529/how-can-i-profile-my-isps-bandwidth-shaping-settings)
109 comments
[ 401 ms ] story [ 1396 ms ] threadSo, feel free to reply here instead of the SF question if you have a response for that.
HN does not load particularly fast for me, 300-500ms is fairly slow.
Whenever I find myself on a shitty connection with high response time and (moderate) packet loss, trying to read a newspaper online is just painful, whereas HN mostly loads fine anyay.
rockpapershotgun.com takes 10 seconds to load entirely and serves 1.6 MB of data. Which is OK compared to others Like Polygon and Co which serve more that 5MB on their homepage and take 20sec to load on average.
slow Compared to what? Show me a social network/forum that you visit everyday and loads everything under 300ms.
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.
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.
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.
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.
It must be the backend ,ie when tasked to render the same page ,which backend would respond faster
It's the number of requests that's killing the NYT site. HN is very simple and old school, and doesn't do a single thing that isn't explicitly necessary to render exactly the content you see on the page, which is presented cleanly and without frills.
Client-side caching is a nothing but a lie bad front-end developers tell themselves to justify producing bad websites.
Looking at this page in my browser's network analyzer, I see a request for the page itself (3.8k), followed by requests for the css and a few images which don't impact layout. On top of that, JS isn't used for layout, so the HTML renderer can do its job.
Besides this thread we had a bunch of "We discovered that adblockers clean up and speed up browsing experience by x%. Now why is that?" threads in the last month posted here. There's a reason for that.
As for reliability... I don't have complaints, honestly. Maybe I spend less time here than you.
My only gripe with HN is the search stuff they use (Algolia). It's almost unusable on my mobile, broken in Opera Mini, and just crappy on my desktop browser.
When your browser asks for the IP to news.ycombinator.com, you get the address of a cloudflare CDN server. Which web server the DNS server will send you is based on a GeoIP lookup of your own IP address so that they can give you the address to the server physically closest to you, and therefore the lowest possible latency.
Edit: Apparently this is not how CF does things (see below explanation by benjojo12) but is not uncommon in load-balancing and distribution.
We don't actually use GeoIP at the DNS level, we use the routing table of the internet to direct people to the closest location we have to them by announcing the same IP addresses in the routing table in many places (eg, anycast) You can find a blog post primer and general more explanation here: https://blog.cloudflare.com/cloudflares-architecture-elimina...
the upshot of this is that TCP and SSL connections start faster because of lower latency to our location, and we can pull items out of cache faster and give them to the client.
[0] https://blog.cloudflare.com/deprecating-dns-any-meta-query-t...
That is how you can make it faster even when somebody is logged in and you are delivering a somewhat personalized experience.
A thread like https://news.ycombinator.com/item?id=9976298 with ~600 comments pulls down 785KB (compressed to 143KB)
In general, looking at the network tab in the developer tools will show why one site loads faster than another:
https://developer.chrome.com/devtools/docs/network
https://developer.mozilla.org/en-US/docs/Tools/Network_Monit...
http://motherfuckingwebsite.com/
> First thing I did, as I usually do with sites that have annoyingly small text width, was inspect element to increase contrast / width / remove the doublespacing. Then I read it. ...irony.
1. Use Chrome's device emulator mode. You can ignore all other settings like screen size, user agent, etc. and just use the speed restriction. 2. Use a specialized WiFi router. I use the ones from TP-Link in which I can restrict speed for a particular device IP. DD WRT based routers can also help here.
In fact, it can simulate the scenario better as compared to Chrome as the speed is shared by everything on the system and not just that Chrome tab.
http://forum.dlang.org/
> This website is a web frontend to the DigitalMars NNTP server and mailing lists. It is part of DFeed, which is also a D news aggregator and IRC bot.
> DFeed was written mostly by Vladimir Panteleev. Portions (including style and graphics) are Copyright © by Digital Mars. The source code is available under the GNU Affero General Public License on GitHub: https://github.com/CyberShadow/DFeed
Probably as static as possible, speed is easy then.
With an empty cache, every asset except font awesome is getting to me - here in Poland - in under 200ms, with some under 150ms.
For 22 requests - even with a total payload of "only" 155kb - whether static or not, that is seriously impressive.
Write compact and easy-to-render HTML, it's no rocket science. Write some trivial CSS, you don't need Bootstrap. Make something dead-simple and call it flat design. If you have more than one stylesheet, concatenate them into one. Consider minifying. You don't need a 200 kB JS framework in order to fade in some hover menu. If you do need more than one JS file, concatenate them into one. Minify/uglify and move the <script> tag to the bottom of your HTML.
You don't need 2 MB worth of stock photos. Recently, there was a page on HN with an uncompressed 12 MB banner photo. That is insane.
You don't need those heavyweight social plugins, they ruin your day (performance-wise). If your content is great, people will find a way to share. If your boss specifically asks for Facebook and Twitter buttons, just link to https://www.facebook.com/sharer/sharer.php?u=http://www.exam... and https://twitter.com/home?status=This%20is%20great:%20http://.... [1]
Don't just embed YouTube iframes, they are even worse. Use yt-embed.js [2].
Is a web font really necessary? If it is, do you really need Bold Italic? Sure as hell you don't need Ultralight+Light+Semilight+Regular+Bold, just because there is one ubercool Ultralight tagline in the footer.
Make sure Nginx or Apache gzip HTML, CSS and JS and send far-future Expires headers for all your static assets. Make sure that there are no redirects, they add latency.
If you follow these simple rules, your page weighs under 50 kB and needs no more than 10 HTTP requests. You don't even need complicated CMS caching and CloudFlare. But hey, there are some 10,000 cache plugins for WordPress, just install one.
[1] http://www.sharelinkgenerator.com/
[2] https://gist.github.com/do18/09761dfabf60689b2cd8
You're ignoring that this site does use jQuery and webfonts and loads all of those pretty avatars separately. 22 requests, at my count.
For the reasons you list - i.e. words to the effect of "don't use all of this stuff" - I think that it is impressively fast, and their achievement shouldn't be hand-waved away quite so readily.
Many seem to believe that there is some secret sauce involved in making web pages load fast. There isn't. Server-side caching is no rocket science. The key is to keep everything so simple that you have the overview over every delivered byte at all times.
Take a look at the HTML of forum.dlang.org. It's so simple, if it wasn't minified, I could immediately start working on this site. When someone asks me to work on some existing wiki or blog template, I usually spend an hour removing unused code first and I still struggle to find my way around the codebase. At that point, maintaining efficiency becomes impossible.
When you have a simple codebase, you may add a font, avatars, and jQuery. The trick is to think about whether you need it, not throw it in "just in case." Specifically, some tiny avatars won't hurt overall performance as long as the page doesn't need to be redrawn. Therefore, always specify width and height attributes for your img elements in HTML or CSS.
[1] https://en.wikiquote.org/wiki/Antoine_de_Saint_Exup%C3%A9ry#...
Performance is not the opposite of UX, it is an important part of it.
>You don't need 2 MB worth of stock photos. Recently, there was a page on HN with an uncompressed 12 MB banner photo. That is insane.
That seems to be a big trend nowadays and a huge pain.
My working hypothesis is that I don't have a good understanding of web-development to appreciate the nuances. Much akin to me listening to Indian classical music, Jazz: I would often encounter trained listeners breaking out into a (silent) applause. At those instances I feel bad because I realize I have missed something but I wish I didn't. So all pointers appreciated.
Do you use NoScript? I feel the same way because I usually run with JS turned off. Most things are pretty zippy despite using a computer from 2009.
Making a site fast boils down to:
1) Making sure your server responds quickly.
2) Reducing the number of requests required for a page to load.
3) Reducing the number of bytes required for a page to load.
Under the same conditions, the dlang site loads in ~200ms.
That's half a second faster, which is definitely noticeable when clicking around.
As for D being quite fast, the consensus is that yes, it is. From what I gather, you'd be hard-pressed to beat or match it using any other language not counting perhaps assembly. It also seems to have a relatively low memory footprint comparable to that of C and C++.
IMO, more people need to be using D. It seems to outperform every other language in every speed benchmark I've seen, is packed with modern features, and doesn't have a steep learning curve. I'm not someone who has a bias toward D either. I've only recently become interested in it and I come from a background of C, C++, and C# (As well as many scripting languages).
Try D, I am.
> It seems to outperform every other language in every speed benchmark I've seen
I like D. A lot. But please don't do this. It a) does not help D's popularity (if that is what you are trying to do , b) it makes you look like a troll or makes you look stupid (sorry)
You should think before calling someone a troll or saying that they sound stupid when they're citing information from an outside source. If I didn't think Dlang had a performance benefit I'd have a bit less incentive to use it. Are you saying such benchmarks are false? They seem legitimate to me. Search and view them yourself. If I were a troll I'd do something like you did, citing no evidence. Commenting in such a way without citing data makes YOU sound stupid (Sorry).
Heck, I get the feeling that they impact loading time more than my own CSS, images and Javascript. I already heavily minify and concatenate everything, as well as use SPDY for improved concurrent requests, but it seems Google and Twitter add 1-2 seconds.
Javascript is really the black hole, though. When people defer their client-side libraries to whatever CDN, and then let that library manage whatever it pleases for dependencies, forget it. That's like saying, I don't even care if people's computers catch fire and explode, when they try to watch this awesome star field simulation.
Oh yeah, and all the ads and spyware analytics too, ya know...
I kind of wish the whole web worked that way. Yahoo was like that in the old, old days (akebono.stanford.edu).
http://tools.pingdom.com/fpt/#!/cnYAuq/https://news.ycombina...
5 requests, Total size 12.6kB, total time 661ms. 1 request for the content, 1 for css, and then 3 gifs, all from a single domain (so just one DNS request). If you look at the profile, 47% of the time was spent doing that one DNS lookup, so subsequent requests will be even quicker (plus caching will handle those gifs just fine)
That's almost no work for the end client to do. No javsacript for the client to download, parse and process, just straight content to render and done.
The reduced request count is especially important when it comes to the mobile experience, where bandwidth might be great, but latency is terrible. Every request you have to make to render a page significantly impacts the loading time (HTTP2 helps here). Along with trying to reduce the number of resources being loaded on the screen, it's especially important to reduce the number of domains you're getting them from so you keep the DNS queries down.
Are you sure?
request #1
1 news.ycombinator.com: 207 bytes, 1+0+4+2 records, response, noerror query: 1 news.ycombinator.com authority: ycombinator.com 172800 NS ns-225.awsdns-28.com
request #2
1 news.ycombinator.com: 225 bytes, 1+1+4+0 records, response, authoritative, noerror query: 1 news.ycombinator.com answer: news.ycombinator.com 300 CNAME news.ycombinator.com.cdn.cloudflare.net authority: ycombinator.com 172800 NS ns-1411.awsdns-48.org
request #3
1 news.ycombinator.com.cdn.cloudflare.net: 367 bytes, 1+0+5+10 records, response, noerror query: 1 news.ycombinator.com.cdn.cloudflare.net authority: cloudflare.net 172800 NS ns1.cloudflare.net
request #4
1 news.ycombinator.com.cdn.cloudflare.net: 89 bytes, 1+2+0+0 records, response, authoritative, noerror query: 1 news.ycombinator.com.cdn.cloudflare.net answer: news.ycombinator.com.cdn.cloudflare.net 300 A 198.41.190.47
A HOSTS file entry for HN will avoid this routine.
I prefer a static site without JavaScript any time of day! (over a JS bloated webs(h)ite)
Most development practices considered "modern" prevent progressive rendering. Common tools like Bootstrap or Jquery, as normally used, cause page rendering to block until large libraries are downloaded, despite the fact that only a tiny portion of bootstrap or Jquery are actually used by the page.
The largest reason of all is that most developers dismiss such concerns as old school worries and like to harp on and on about how tools like Angular enforce wonderful software engineering practices, ignoring that most such frameworks, as commonly used, bloat pages and cause incredible rendering delays.
The difficulty with improving performance is that most "modern" pages have numerous render-blocks. The page doesn't get fast until you fix all of them. This is the reason most wise suggestions to speed up a page make little difference when tested individually.
Alternatively, you could say that many people look at the tradeoffs and decide they're comfortable with trading off a certain amount of speed for the user, in order to increase development speed.
Whether these people are right or wrong really depends on the context.
But sometimes it does - e.g. I think in most cases, something existing but being slow is better than something not existing in the first place, which might be the case if the costs of making it go up.
By the nature of HN, there isn't that much hot data. Only the couple dozens of links in the HN front page are popular. May be couple hundreds or couple thousands people actively voting. All those don't take too much space and can fit in memory comfortably so the entire data set can be operated inside memory essentially.
The front page has 30 articles. Assuming 100k per one yields 3MB. It has about 1000 vote points. Assuming 50 bytes per vote, it's about 50k. So you can fit the entire front page data in under 4MB. That's tiny amount of data to work with.
Pre-rendered pages fed over the wire with minimal assets are fast, my blog http://benlowery.co.uk/ loads under 70ms on my home connection, it downloads 3 assets (and by far the biggest hit is the webfont).
I think we've grown so used to pages taking a couple of seconds to pull hundreds of assets and then render them that fast pages stand out :).
The language which generates the page is irrelevant, when the page you're viewing changes rarely (doesn't change from user to user). It's very cacheable which means you might just be loading a static file served by a regular web server. Combine that with the above, and you get your answer.
Compare this to http://qbixstaging.com/Groups, what do you see?
That's the whole answer.