What Actually Determines IPFS Retrieval Speed

IPFS retrieval speed is not one number, and asking "is IPFS fast" without saying which path you mean doesn't have a real answer. This series has covered transport, routing, and gateway mechanics separately across a dozen articles; this one pulls those threads together into a single question worth answering directly: for a given request, what's actually adding time, and which of those costs are fixable versus structural.

TL;DR:

• A cold peer-to-peer request pays several costs in sequence: transport handshake, routing lookup (DHT or delegated routing), then the actual Bitswap block exchange, each one a real, separate source of latency
• QUIC collapses the transport handshake to one round-trip instead of TCP-plus-TLS's two, but that's a small piece of the total compared to routing and discovery
• Routing is where the largest, most fixable cost lives: a 2025 caching update to delegated routing infrastructure cut P95 latency by 560ms (29%) simply by caching peer addresses instead of re-resolving them on every request
• A gateway request skips almost this entire stack at once, no transport negotiation with an unknown peer, no routing lookup, no Bitswap negotiation, which is the real, structural reason gateway retrieval is consistently faster than a cold peer-to-peer fetch
• None of this is fixed by "IPFS being fast or slow" as a property; it's fixed (or not) at each layer independently, and knowing which layer is actually the bottleneck for a given use case is what actually helps

Speed Isn't One Number Because Retrieval Isn't One Step

Every article in this series that's touched performance has actually been describing one piece of a longer chain: a transport handshake, then a routing lookup, then a content exchange. Treating "IPFS speed" as a single property collapses three genuinely different costs into one vague impression. Splitting them back apart is what actually explains why the same protocol can feel instant through one path and sluggish through another.

Cost One: Getting Connected At All

Before any content moves, two peers need a connection, and this series' transports article already covers what that costs: a plain TCP-plus-TLS or TCP-plus-Noise handshake takes two round-trips before any application data can flow, while QUIC collapses that to one round-trip for a new connection, and effectively zero for a peer it's already talked to recently. This is a real cost, and a genuinely fixable one at the protocol level, but it's also usually the smallest of the three: a round-trip or two, tens of milliseconds on a typical connection, not the dominant factor in most slow requests.

Cost Two: Figuring Out Who Has It

This is where the largest, most variable cost actually lives. A cold DHT lookup, this series' DHT article covers the mechanics, walks the network hop by hop, each hop another round-trip, until it finds peers holding a provider record. Delegated routing, covered in this series' dedicated article, replaces that walk with a single HTTP request to a server that already has the answer or fetches it on the client's behalf, and a 2025 caching update to that infrastructure produced a real, measured result: cutting P95 latency by 560 milliseconds, a 29% improvement, simply by not re-resolving peer addresses that were already known good. That's the clearest evidence in this whole series that routing, not transport, is where a meaningful chunk of "IPFS feels slow" actually comes from, and that it's fixable through infrastructure improvements rather than being an inherent property of the protocol.

Cost Three: Actually Getting the Blocks

Once a peer's been found, this series' DHT-and-Bitswap article covers the want-have/want-block exchange that actually moves data, plus the fallback to a fresh routing lookup if none of a peer's existing connections have what it needs. This step's cost depends heavily on circumstances outside any single node's control: how many peers actually have the content, how well-connected they are, whether this series' reproviding article's concern, a stale or unrenewed provider record, means the peer that's supposed to have it isn't even findable. A popular, well-seeded file behaves very differently here than one held by a single lightly-connected node.

Why a Gateway Request Skips Nearly All of This

Stacked together, a cold peer-to-peer fetch pays all three costs in sequence: connect, route, exchange. A request to a gateway, this series has made this point about several individual mechanisms separately, DHT and Bitswap, libp2p connection setup, delegated routing, collapses almost the entire stack into one HTTP request to infrastructure that's already connected, already knows it has the content, and just serves it. This isn't a separate speed trick layered on top of IPFS, it's the direct consequence of not needing to pay costs one and two at all when the destination is already known and already reachable. That's the actual mechanism behind every "gateway retrieval is faster" claim made piecemeal across this series, stated once, together, here.

What This Means for Choosing a Retrieval Path

None of this makes peer-to-peer retrieval the wrong choice, it's the only path that doesn't depend on a specific provider staying online and well-resourced, the exact tradeoff this series' content-addressing article covers. It does mean the honest answer to "why is this IPFS fetch slow" is almost never "IPFS is slow," it's one of three specific, separately diagnosable costs: a cold connection, an expensive routing lookup, or content that's genuinely hard to find. Knowing which one is actually the bottleneck, rather than treating the whole stack as one opaque property, is what separates a real fix from switching providers and hoping.

Frequently Asked Questions

Why does IPFS sometimes feel slow? Retrieval isn't one step, it's a transport handshake, a routing lookup, and a content exchange stacked in sequence, and slowness usually comes from one specific layer, most often routing, not the protocol as a whole.

Which part of IPFS retrieval is usually the biggest cost? Routing, finding who has the content. A 2025 measurement showed a caching improvement to routing infrastructure alone cut P95 latency by 560ms (29%), larger than the transport-layer gains QUIC provides.

Does QUIC make IPFS retrieval significantly faster overall? It meaningfully reduces connection-setup time, roughly a round-trip compared to TCP-plus-TLS, but that's typically a smaller piece of total latency than routing lookup cost.

Why is a gateway request faster than a peer-to-peer fetch? Because it skips almost the entire cost stack at once: no transport negotiation with an unknown peer, no routing lookup, no Bitswap negotiation, since the gateway is already a known, connected, content-holding destination.

Is peer-to-peer retrieval just worse than using a gateway? It trades some speed for not depending on any single provider staying online, the core tradeoff behind content addressing generally. Which one matters more depends on what a specific use case actually needs.

Can IPFS retrieval speed actually be improved, or is it a fixed property of the protocol? It's improvable, and demonstrably has been: the delegated routing caching update is a real, measured example of infrastructure-side work directly reducing latency without any change to the underlying protocol.

Related Reading

• Delegated Routing: How Light Clients Skip Running a DHT - the exact caching improvement this article's routing-cost section is built on
• IPFS Transports: TCP vs. QUIC Explained - the connection-setup cost covered here in full
• How IPFS Finds and Retrieves Your Files: DHT Provider Records and Bitswap Explained - the full routing-and-exchange mechanics this article synthesizes
• Why IPFS Provider Records Expire and Get Renewed - why content can be well-seeded and still hard to find if reproviding has lapsed

References

• IPFS Blog: Faster Peer-to-Peer Retrieval in Browsers With Caching in the Delegated Routing HTTP Server
• libp2p: QUIC