The shown page could be served on 0.01 seconds if it was...html. Or, if you MUST lob complexity at it, use a static site generator... that generates...HTML
Try playing around with the pagespeed link provided in the article. You can see that in the default view the network is set to slow 4G throttling with an RTT of 150 ms so it's going to be impossible to get times like 0.01 seconds. Even just loading https://x.com, a site that literally serves a single character of content "x", gets 0.8 seconds.
You can see for yourself with the provided Pagespeed metrics that the root document was served in around 30ms (corresponding to TTFB).
If you can elaborate on how statically-served HTML would render orders of magnitude faster than server-sider-rendered HTML with a similar response time, I'd love to hear it.
You've shown a way to add multiples of ~0.0000000003 seconds to the time but haven't explained how the page is going to go from .01 seconds to 1.0 seconds as a result when TTFB is 0.03 seconds.
It's not, unless "static site generator" is one of those terms (like "literally" or "REST"[0]) that has morphed to mean the opposite of what it was supposed to mean. (Not to be confused with "serverless", which never meant what the word suggests.)
This application is generating HTML on the server, but so does PHP. A Web site backed by a PHP application is the antithesis of a static site.
The shown page is HTML. It's a plain-old website that works the same way websites have always worked: the page is generated at request time, and HTML is served directly to the client. It's not technically a "static" site because the HTML is not cached ahead of time, but apart from the fact that the whole back-end is a single JS file, there's nothing special here.