Edit: the paper I found related to this is here[1]
[0]: https://github.com/stagas/http-geolocate
[1]: https://homes.cs.washington.edu/~tom/support/geoloc.pdf
This page contains websocket addresses of a CDN that returns ping pong from a huge number of locations. It works surprisingly well for working out very fine grain location in just playing with it.
Edit: no, I misunderstood, the location dot that's being displayed isn't the product of triangulation, they're just doing reverse geoip lookup. So, I wonder now if the edge network would perform better.
Update: it doesn't perform better. Either there is some kind of proxy redirecting their traffic or these servers aren't where they say they are, the center is skewed out completely. The universities win so far being correct and accurate most of the time.
Now yours consistently puts me somewhere into, or onto the shores of the Black Sea, while Vercels doesn't. So that makes me suspicious of your claim by using latency alone.
Edit: There seems to be outdated geo-ip information factored in somewhere. Why else it would put me IN the Black Sea?
Anyways, time to sleep. Sun's getting too bright.
You should take a look at network path convergence for geolocation instead. You can see a demo of the tool I wrote at https://traceroute.guru/tr/209.216.230.240
You can easily be next door to someone, and your packets go all the way across the country to get there.
I've definitely seen cases where my latency to two servers in the same building were wildly different, depending on the paths my ISP and their ISP(s) routed the traffic.
I'm about 22 ms roundtrip away from ISPs facility at the local internet exchange in Seattle. If a server is connected to that exchange, and traffic flows through the exchange both ways, I see ping times of about 22 ms. Sometimes, my ISP will send traffic through San Jose instead, but the server returns the traffic in Seattle, and that adds about 26ms, so I get a 48 ms ping. If both sides route through San Jose for whatever reason, I'll get 74 ms, which is close to what I'd get if the routing was sensible and the server was in the Washington, DC area. (You normally can't see the routing back from the server, but sometimes you control the server, too).
If I were building something like this, I'd want to try to determine how much of the latency was the user getting to where their ISP interconnects with other networks (or with multiple routes within their own network), and then where that interconnection location is. I'd guess you can get a pretty good idea of the interconnection location, based on reasonable network paths from there, but distance from the interconnection point is going to be tricky, most residential networking technologies add much more latency than the speed of light, so your upper bound of distance is going to be pretty far off. Of the roughly 22 ms I see to Seattle, about 20 ms is just coming from the DSL termination; when I had AT&T GPON, it added about 4 ms to my pings; that's a lot of distance.
In the end, unless you've got machines next door pinging your target you won't be able to differentiate between houses or city blocks.