Consider using CDN for the site

Firstly, because the authoritative name server for the domain dprevived.com is located in Europe, the initial query time for the A record of the site is very long.
Below is a query from a client based in Japan.

~ % dig -t A dprevived.com. | grep "Query time"
;; Query time: 267 msec

267 msec is beyond bad. Add to this the fact that the site doesn't use CDN, I won't be surprised if the time to first byte to access the site exceeds 1 second, which further degrades user experience.

Please consider:

• Changing the authoritative name server to Cloudflare DNS. It's free for non-critical, hobby projects such as this site.
• Using Cloudflare CDN to accelerate static objects delivery. Similar to the above Cloudflare DNS, there's a free tier for sites like this.

Not sure what all that means but the various pages on this site load extremely quickly here.

The 267ms figure is for a DNS query, which are cached in normal usage, and as such doesn't really mean anything as far as visitor experience is concerned. Likewise setting up a CDN at this point would almost certainly be an overkill and needlessly complicate development and deployment operations. I wouldn't worry about it until they grow at least one order of magnitude in activity.

I have suggested using Cloudflare as Web Application Firewall in another thread, but sure, the built-in CDN / caching functionality is also useful to reduce both bandwidth and load on the web server. While I'm sure one can find good arguments against this particular vendor, their configuration interface is really nice to work with for mere mortals like myself. Example:

There is an ICANN rule that says you can't transfer a domain if it's registered within the last 60 days, so I guess even if you want you can't do it right now.

After the above period, if you still want to change, I can help. It's not without risk of course, but I consider domain transfer to this vendor a trivial, straightforward task.

@Shmoopix @43review

How do you know that it's cached apart from the very first query?

Below is from my ISP's default resolver (IPv6). 1-sec interval.

~ % dig -t A dprevived.com. | grep "Query"
;; Query time: 254 msec
~ % dig -t A dprevived.com. | grep "Query"
;; Query time: 258 msec
~ % dig -t A dprevived.com. | grep "Query"
;; Query time: 248 msec
~ % dig -t A dprevived.com. | grep "Query"
;; Query time: 276 msec
~ % dig -t A dprevived.com. | grep "Query"
;; Query time: 20 msec
~ % dig -t A dprevived.com. | grep "Query"
;; Query time: 273 msec

Below is from Google Public DNS.

~ % dig -t A dprevived.com. @8.8.8.8 | grep "Query"
;; Query time: 226 msec
~ % dig -t A dprevived.com. @8.8.8.8 | grep "Query"
;; Query time: 223 msec
~ % dig -t A dprevived.com. @8.8.8.8 | grep "Query"
;; Query time: 4 msec
~ % dig -t A dprevived.com. @8.8.8.8 | grep "Query"
;; Query time: 4 msec
~ % dig -t A dprevived.com. @8.8.8.8 | grep "Query"
;; Query time: 3 msec
~ % dig -t A dprevived.com. @8.8.8.8 | grep "Query"
;; Query time: 220 msec

Chromium only caches DNS for 1 minute (src).

If you read one thread for at least 1 minute, and then if you go to the landing page of this site again for example, there's high chance it will require at least 250 msec just for the DNS.

Actually I had seen your post when I created this thread. WAF is not included in the free plan, that's why I didn't write about it.
As you said there's really no downside in using this vendor's CDN (and DNS) even with free plan.

It depends on your definition of 'extremely quick', of course.
Also if you live next to the data center hosting this site it might help a bit 😆

And even on the free plan there's at least basic WAF protection:
blog.cloudflare.com/waf-for-everyone/

I've transferred several domains to Cloudflare and it's been entirely transparent, zero downtime. The first step is to use them for DNS only, then you turn on the Proxy switch when you're ready to try out the WAF and CDN features.

Something upstream is presumably not doing its job, the TTL/minimum for dprevived.com is 24 hours.

Apparently Chromium uses DoH when possible, so after the 1-minute timer it sends new query to the DoH provider, bypassing whatever in the middle.

TTL is just a guide, I believe there's no strict requirement for resolvers to observe the value. (ref)