It is caching the static assets (js, css, png, etc) based on default extensions[1]. The page itself is dynamic, likely for the comment feature at the bottom of the page. If they wanted to cache it, they could probably add some caching headers (have to change the responses on the origin) or a Page Rule in cloudflare (and not have to change anything on the server). But that won't be a good idea if people can login to the page to comment (not sure if CloudFlare can tell if someone is not-logged-in and return a cached version; that would be interesting). I see CF-Cache-Status: DYNAMIC header, which is:

"The resource content type was not cached by default and your current Cloudflare caching configuration doesn't instruct Cloudflare to cache the resource. Instead, the resource was requested from the origin web server. Use Page Rules to implement custom caching options."

[1] https://support.cloudflare.com/hc/en-us/articles/200172516-U...

I don't have much static content, no cdn, do multiple database queries per request, my server isn't beefy enough to run any of the common content managers like WordPress or typo3 (well, each pageload took a very long time), and yet it survived the HN homepage on a few occasions.

A huge system like WordPress can't do dynamic content for more than a small number of visitors per second no matter how beefy the server and has to hackily convert content from dynamic to static content. Which is fine since it uses a lot less power to do static content instead of buying beefier and beefier servers, but it is not how WordPress meant its blogging software to have to be (maybe they gave up by now and do static rendering by default, but it used to be all plugin based). By writing my own tiny blogging software I implemented what I needed and it worked just fine on an Intel Atom CPU, even on the HN homepage.