Will Mojeek consider deploying infrastructure in other regions? (Re: Latency)

I’ve been using Kagi more recently and noticed how fast it was. The markup in Mojeek’s pages is actually simpler than Kagi’s (though their markup is still cut down compared to the competition) and Mojeek doesn’t serve any remote fonts, so Mojeek’s pages would likely load faster if latency was comparable. It’s certainly not painful; it’s just not as fast it could be.

Edit: Kagi further reduces load times on its JS-Enabled pages by sending an XHR request to retrieve just the parts of the page that have changed instead of reloading the entire document when the user searches again. Although the downside of this approach is that JS-Enabled and JS-Disabled pages are distinctly separated with no easy way to move between them except modifying the URL.

I’m in Australia, and this is the latency for me on Mojeek:

PING mojeek.com ( 56(84) bytes of data.
64 bytes from mojeek.com ( icmp_seq=1 ttl=51 time=307 ms
64 bytes from mojeek.com ( icmp_seq=2 ttl=51 time=330 ms
64 bytes from mojeek.com ( icmp_seq=3 ttl=51 time=354 ms

Compared to Kagi:

PING kagi.com ( 56(84) bytes of data.
64 bytes from kagi.com ( icmp_seq=1 ttl=120 time=9.65 ms
64 bytes from kagi.com ( icmp_seq=2 ttl=120 time=12.0 ms
64 bytes from kagi.com ( icmp_seq=3 ttl=120 time=12.5 ms

Kagi has servers in the Oceania region, so there’s almost no latency. I was wondering if Mojeek was considering deploying nodes in other regions in the future to reduce latency.

I don’t think there are any asynchronous requests going on in Mojeek’s search results page (and there are so few requests anyway), so this latency should only be relevant for initially loading the document. However, latency definitely has an impact on the images results page because of how many requests are being made.

Not that I’m a big user of image search :slight_smile:

Anyway, I thought it was worth asking given Mojeek’s recent focus on scaling up its infrastructure.

Good question @gnome. The comparison you give on times is a ping time. Still it is a minimum time, so has some validity. Any search proxy calling another search engine, would need to factor in the total time. To answer query we are not yet at the stage of deploying infrastructure in other regions. It’s something we have considered and will revisit, but it is not on the current roadmap.


You do raise a good point about Kagi and other search proxies having to wait for a search engine to process the query, which surely shows things down.

I didn’t only test ping times; I tested page load times as well, but after looking at all the other variables, this one jumped out at me. After some more testing, I found Mojeek tends to return pages between 1.6s~2.8s (typically 1.8s~2.5s), while Kagi tends to return pages between 1.3s~2.2s (typically 1.4~1.6s), and obviously both get faster when the browser caches assets. The only thing significantly different (from where I’m sitting) is the server location, because Mojeek always gets results from its index faster than Kagi.

It’s not a significant difference, but load times are less consistent with Mojeek for me, probably due to the distance.

I can understand why you would be cautious about choosing another data centre—I’ve read Mojeek’s articles about Custodian and why you chose it. And besides that, renting infrastructure that you likely won’t have as much oversight on.