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 (5.102.173.68) 56(84) bytes of data.
64 bytes from mojeek.com (5.102.173.68): icmp_seq=1 ttl=51 time=307 ms
64 bytes from mojeek.com (5.102.173.68): icmp_seq=2 ttl=51 time=330 ms
64 bytes from mojeek.com (5.102.173.68): icmp_seq=3 ttl=51 time=354 ms
Compared to Kagi:
PING kagi.com (34.111.242.115) 56(84) bytes of data.
64 bytes from kagi.com (34.111.242.115): icmp_seq=1 ttl=120 time=9.65 ms
64 bytes from kagi.com (34.111.242.115): icmp_seq=2 ttl=120 time=12.0 ms
64 bytes from kagi.com (34.111.242.115): 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
Anyway, I thought it was worth asking given Mojeek’s recent focus on scaling up its infrastructure.