If you ship a large lookup bundle, redirect map, or routing table, steal the pattern Vercel applied to its CDN metadata cache: group entries into shards, add an index, and search it instead of keeping one object per key. The numbers are Vercel's own, and nobody has reproduced them. P99 lookup fell from 215.8 ms to 19.1 ms, the average from 8.59 ms to 1.81 ms.
The old design held a separate cache object per target path. The replacement packs many paths into one shard of key-sorted JSONL, with an optional inline fixed-width index. Lookup does a binary search over byte offsets computed at build time, decodes just the matched entry, and leaves the remainder of the shard unparsed.
Shard size is the other half. Vercel tuned it against live traffic rather than guessing: shards much larger than roughly 200 KB made cache misses expensive to fill, while smaller ones pushed too many requests onto regional caches. Roughly 200 KB is where those costs balanced.
As a rule of thumb, one object per key starts to hurt once a lookup table passes a few hundred kilobytes, which a router or redirect map hits after a few thousand entries (Vercel's balance point was about 200 KB). If that is your bundle, shard it and measure. Treat any vendor latency table, this one included, as a hypothesis until you reproduce it.