The server is taking a long time to render the response. In the first link, 650ms or so. Open the network tab in your browser developer tools to see the details.
Slashdot's solution to this was to render the HTML on write, instead of on read. Whenever someone posted a new commend, a static HTML file would get generated, so that it could be rapidly served to readers. Movable Type works (can work?) much in the same way, though for blogs.
I know that caching achieves a similar result and is an accepted component of a modern architecture, but I wonder if we wouldn't be better served by implementing these sort of "upfront caches" in more software.
Whenever someone posted a new commend, a static HTML file would get generated
It's essentially still a cache, with the same concerns/issues - mainly cache invalidation - as a HTTP cache.
An on-disk cache of that sort has other issues though. For example, what if a request is received whilst the file is being written? Does the system deliver a half-written HTML page? You can introduce locking or atomic file operations (write to a temporary directory, then mv the file into the correct location: mv is an atomic operation), but this adds more complexity to the cache logic.
One of the benefits of a HTTP cache is that they generally have a default graceful failure mode: if the cached data doesn't exist, request it from the backend application server.
The issue doesn't seem any different - assuming you have concurrent requests, you also have to make sure the cache doesn't return a result until the whole document is written to it.
I know that caching achieves a similar result and is an accepted component of a modern architecture, but I wonder if we wouldn't be better served by implementing these sort of "upfront caches" in more software.