> This page (http://pharo.org/news/pharo8.0-released) is currently offline. However, because the site uses Cloudflare's Always Online™ technology you can continue to surf a snapshot of the site.
Except that I see a big error page.
Isn't CloudFlare supposed to help with this? The message on top seems to indicate that, but when I (back in the day) tested with CF on my domain it just proxied every request and failed when my server didn't respond, having zero advantage over just using my server directly (in fact, even having the downside that Tor users now couldn't reach my site anymore). Seems like that's still the case.
It is optional to let CloudFlare cache the content. I believe you can control it from the CloudFlare control panel as well as affect it from your HTTP headers. So I bet they have the feature enabled on the panel but their HTTP headers tell CloudFlare not to cache the page, maybe accidentally.
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."
Who runs the Pharo site? Let's try to diagnose and help them. I don't actually believe in the hackers news hug of death, since many sites survive it just fine (because they take "static content" as seriously as one needs to in order to do so). I see that pharo.org has a "login" link at the bottom. Could the homepage be doing an auth cookie DB lookup on each pageview?
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.
Except that I see a big error page.
Isn't CloudFlare supposed to help with this? The message on top seems to indicate that, but when I (back in the day) tested with CF on my domain it just proxied every request and failed when my server didn't respond, having zero advantage over just using my server directly (in fact, even having the downside that Tor users now couldn't reach my site anymore). Seems like that's still the case.