Jokes aside, it's still cool you managed to do that.

It may be horrific, but it's wonderful too.

I'm pretty sure that the website will reside in cache in any case.

Computers are fast. HTTP requests are not that hard. You have to go down to position 480-ish on the latest TechEmpower Fortune benchmark [1] to find a framework that is serving ~10,000 requests per second on this simple benchmark, and as that is running on a higher-spec system and possibly with more threads than "this guy's random laptop he had lying around" (although by the time you get that low in the benchmarks I suspect we're into single-thread-only frameworks) you could probably go to all but the last three to get something comparable in performance. (Yes, this is not a comparable task, because I'm making a point about speed of HTTP in general not static file serving.)

Also as mentioned nginx on a blog site will certainly not be hitting the disk.

Broadly speaking in 2025 if a website is slow it is 100% the fault of the app-specific code being run in the web request. I've been HN'd before on a very small VPS but since my blog is now all static content it doesn't even notice... even when it was making 4 or 5 DB reads per page it didn't notice. This web server is basically fast not because "it's fast" but simply because there's no reason for it to be slow. That's how computers are nowadays; you really have to give them a reason to be slow for a task like this.

You'd think everyone would know this but I fight a surprising amount of rule-of-thumb estimates from coworkers based on 2000 or 2010 performance of systems, even from developers who weren't developing then! It's really easy to not realize how much performance you're throwing away using a scripting language, and using multiple fancy runtime features that have multiplicative costs at runtime, and make bad use of databases with too many queries, that fail to do even basic optimizations on said databases, and come away thinking that 50 queries per second is a lot, when in fact in 2025 you hardly even need to consider the performance of the web requests themselves until you're into the range of interest until you're in the many thousands per core... and that's just when you need to start thinking about it.

Depending on what you are doing, of course, you may need to be considering how your code runs well before that, if your web requests are intrinsically expensive. But you don't need to worry about the web itself until at least that level of performance, and generally it'll be your code struggling to keep up, not the core web server or framework.

[1]: https://www.techempower.com/benchmarks/#section=data-r23

They might not have a static public IP, perhaps they're even behind CGNAT.