Is crates.io slow?

One crates.io surface: the API metadata document for the serde crate, about 440 KB of JSON listing every published version. This is the request the crates.io website and API clients make to learn about a crate. It sits behind Fastly, but the responses we saw came from the origin rather than from the cache. It does not stand for cargo build: Cargo reads the sparse index and downloads .crate files from static.crates.io, and both are served differently. From outside we cannot see where the origin runs or why the document is served uncached. We see only that the Fastly edge nearest each city answered, and that the body arrived at a speed set by the distance behind that edge.

Between 27 September and 10 October 2026 the typical time ranged from 146 ms in Montreal to 1,555 ms in Mumbai, with Singapore at 1,315 ms, Tokyo at 1,202 ms, Amsterdam at 676 ms and San Francisco at 445 ms. Montreal's daily median sat at 136 to 151 ms until 1 October and at 206 to 231 ms from the 2nd, apart from one 56 ms day on 5 October. Mumbai stayed at 1,502 to 1,684 ms on 10 of the 13 daily runs, Amsterdam at 661 to 764 ms on nine, and San Francisco at 417 to 466 ms on ten. Most exceptions were one fast city on one day: Amsterdam's daily median fell to 112 ms on 30 September, Tokyo's to 190 ms on 1 October and Mumbai's to 213 ms on 6 October, and the controlled run of 4 October found medians of 481 to 944 ms in the three Asian cities against more than 900 ms on most days. A few went the other way: Tokyo took 2,195 ms on 28 September and Mumbai 2,609 ms on the 29th. From outside we cannot tell whether the document was cached at the edge on the fast days. PyPI, measured the same way on the same days from a cached document, took 11 to 68 ms.