Speed Up IPFS File Retrieval with Dedicated Gateways
Practical techniques to improve IPFS file retrieval speed: dedicated gateways, caching strategies, preloading, and CDN integration.
Nacho founded IPFS.NINJA to make content-addressed storage feel as simple as an S3 PUT — a single API call, a permanent CID, no wallets or peer discovery to reason about.

- Swap public gateways for a dedicated gateway to cut IPFS latency from seconds to under 200 ms.
- Public gateways run a DHT lookup on cold CIDs, adding 2–15 seconds before content resolves.
- Pin files at write time, not read time, so the gateway already holds them before the first request.
- Pair a dedicated gateway with a CDN edge to bring global IPFS latency down to 10–50 ms.
“IPFS is slow” is one of the most common developer complaints — and also one of the most fixable. The culprit is almost always the access method, not the protocol itself. This guide covers four techniques that eliminate IPFS latency in production.

Quick-Reference: IPFS Access Methods by Speed#
| Access method | Typical TTFB | When to use |
|---|---|---|
Public gateway (ipfs.io, dweb.link) | 2–15 s | Development and testing only |
| Dedicated gateway (pinned content) | 50–200 ms | All production traffic |
| Dedicated gateway + CDN edge | 10–50 ms | Global user base |
| Image optimization endpoint | <100 ms (warm) | All image content |
If you’re hitting public gateways in production, move to a dedicated gateway and most of your latency disappears immediately.
Why Public Gateways Are Slow#
Public gateways perform a DHT (Distributed Hash Table) lookup on every CID they haven’t recently seen. DHT lookup means querying dozens of peers across the network to find who holds the content — that round-trip takes 2–15 seconds on a cold request.
Even on a cache hit, public gateways serve millions of users. Your recently-pinned file has low cache priority and may be evicted between requests.
Solution 1: Dedicated Gateway#
A dedicated gateway is private to your account. Files you pin are cached on that gateway immediately — no DHT lookup on any request, cold or warm.
# Before: public gateway, slow and unreliable
curl https://ipfs.io/ipfs/bafybeigdyrzt5sfp7udm7hu76uh7y26nf3efuylqabf3oclgtqy55fbzdi
# After: dedicated gateway, fast and deterministic
curl https://my-app.gw.ipfs.ninja/ipfs/bafybeigdyrzt5sfp7udm7hu76uh7y26nf3efuylqabf3oclgtqy55fbzdiCreate a gateway in your IPFS.NINJA dashboard and set the slug to match your project. Gateway slugs support restricted access mode (token required) or open mode for public static assets.
Solution 2: Pin at Write Time, Not Read Time#
Pin files the moment they’re created so the gateway has them before any user requests them. The fastest request is one that never causes a cache miss.
# Upload and pin in one step
curl -X POST https://api.ipfs.ninja/upload/new \
-H "X-Api-Key: bws_a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4" \
-H "Content-Type: application/json" \
-d '{
"content": {
"data": "BASE64_ENCODED_CONTENT",
"type": "image/png"
},
"description": "Product hero image v2"
}'
# Response — store the CID, serve the url immediately
# {
# "cid": "bafy...",
# "sizeMB": 0.24,
# "uris": {
# "ipfs": "ipfs://bafy...",
# "url": "https://ipfs.ninja/ipfs/bafy..."
# }
# }If you have existing CIDs from another node or pinning service, re-pin without re-uploading:
curl -X POST https://api.ipfs.ninja/pin \
-H "X-Api-Key: bws_a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4" \
-H "Content-Type: application/json" \
-d '{"cid": "bafybeigdyrzt5sfp7udm7hu76uh7y26nf3efuylqabf3oclgtqy55fbzdi"}'See how to upload files to IPFS for the full upload API reference.
Solution 3: CDN in Front of Your Gateway#
Dedicated gateways serve from a fixed region. If your users span continents, add a CDN edge layer to serve from the closest point of presence.
Because IPFS is content-addressed — a given CID always resolves to identical bytes — you can cache forever:
Cache-Control: public, max-age=31536000, immutableCloudflare example (free tier covers most static-asset workloads):
- Add your gateway subdomain (
my-app.gw.ipfs.ninja) as a Cloudflare proxied CNAME. - Create a Page Rule:
my-app.gw.ipfs.ninja/ipfs/*→ Cache Everything, Edge Cache TTL: a month. - The first request hits the gateway and is cached at the nearest edge PoP. All subsequent requests serve from Cloudflare.
Result: global TTFB drops from 50–200 ms to 10–50 ms.
Solution 4: Image Optimization API#
Raw IPFS images served at full resolution slow pages and hurt Core Web Vitals. Use the image optimization endpoint to resize at the edge and serve modern formats:
# Original (full resolution via gateway)
https://my-app.gw.ipfs.ninja/ipfs/bafy...
# Resized to 800 px wide, converted to WebP
https://api.ipfs.ninja/image/bafy...?w=800&format=webp
# Square thumbnail
https://api.ipfs.ninja/image/bafy...?w=200&h=200&fit=coverIn React:
function IPFSImage({ cid, width }) {
return (
<img
src={`https://api.ipfs.ninja/image/${cid}?w=${width}&format=webp`}
width={width}
loading="lazy"
decoding="async"
/>
);
}The optimization endpoint caches each (cid, width, format) combination — subsequent requests with the same parameters skip origin entirely.
Checklist#
- Switch from public gateways to a dedicated gateway
- Pin content at write time (on upload), not at read time
- Set
Cache-Control: immutableon gateway responses - Add CDN in front of the gateway for global traffic
- Serve images via the optimization endpoint instead of raw gateway URLs
For background on why pinning matters for availability — not just speed — see what is IPFS pinning.
Ready to start pinning? Create a free account — 500 files, 1 GB storage, 2 GB bandwidth/mo. No credit card required.
About this article
This article was AI-assisted, human-reviewed, and product-verified against the live IPFS.NINJA platform before publishing. Learn how we use AI in our content .

About the author
Nacho Coll
Founder & Engineer at IPFS.NINJA
Nacho founded IPFS.NINJA to make content-addressed storage feel as simple as an S3 PUT — a single API call, a permanent CID, no wallets or peer discovery to reason about. Writes about IPFS internals, decentralized storage patterns, and the pinning-service landscape from the operator side of the wire.
