Vercel cuts CDN metadata lookup latency 91% with sharded index

Vercel's CDN used to store one metadata object per path and fetch the whole thing on every cold lookup. It now packs metadata into JSONL shards of roughly 200 KB, each with an embedded index and base64 byte offsets, so the router can binary-search a shard and parse only the entry it needs, per Vercel's writeup.

The numbers are the story. P99 lookup latency fell from 215.8ms to 19.1ms, a 91% cut. Average latency dropped to 1.81ms. Deploys got 10-25% faster, because deploy time was partly gated on the same lookup path.

Nothing about this is exotic. It's the same lesson object storage teaches everyone eventually: one object per key means every read pays full fetch-and-parse cost even when you want three bytes out of it. Batch the keys, index the batch, and a lookup becomes a seek instead of a round trip.

I've eaten this cost in S3 more than once, storing one JSON blob per record because it was the obvious shape, then watching cold-path latency climb as the key count grew. The fix is always some version of what Vercel did here: group records into shards, build an index you can binary-search, and only deserialize the slice you asked for.

The thing to check is whether a directory full of one-object-per-key files is taxing every cold read without anyone noticing. If P99 latency on a lookup path looks high relative to average, that gap is usually cold fetches of small objects, and shard-plus-index is a known fix, not a novel one.