Speed Up IPFS File Retrieval with Dedicated Gateways

To speed up IPFS file retrieval, route requests through a dedicated gateway instead of public ones, pin content at write time so no cold DHT lookup runs, cache responses at a CDN edge for global reach, and serve images via an optimization endpoint. These four levers cut typical time-to-first-byte from 2–15 seconds to under 100 ms.

Last verified: 2026-08-27.

Quick-Reference: IPFS Access Methods by Speed#

Which IPFS access method should your app use in production? Public gateways like ipfs.io and dweb.link typically deliver a 2–15-second cold TTFB — fine for development, unusable for user-facing traffic. A dedicated gateway with content pinned to your account brings TTFB down to 50–200 ms; adding a CDN edge lowers it to 10–50 ms globally.

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 slow IPFS retrieval because they run a DHT (Distributed Hash Table) lookup on every CID they have not recently cached — querying dozens of peers to find who holds the content, a round-trip that takes 2–15 seconds on a cold request. Even cache hits are unreliable: your file competes with millions of other users and gets evicted quickly.

The IPFS gateway concept docs describe this handshake in detail — every public gateway shoulders it on your behalf for every uncached CID.

Solution 1: Dedicated Gateway#

A dedicated gateway is a private HTTP endpoint tied to your pinning account — every file you pin is cached there the moment it is written, and every request skips the DHT lookup entirely, cold or warm. IPFS.NINJA provisions each dedicated gateway on a {slug}.gw.ipfs.ninja subdomain in seconds, giving your app a deterministic 50–200 ms TTFB from day one.

# 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/bafybeigdyrzt5sfp7udm7hu76uh7y26nf3efuylqabf3oclgtqy55fbzdi

Create 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, immutable

Cloudflare example (free tier covers most static-asset workloads):

1. Add your gateway subdomain (my-app.gw.ipfs.ninja) as a Cloudflare proxied CNAME.
2. Create a Page Rule: my-app.gw.ipfs.ninja/ipfs/* → Cache Everything, Edge Cache TTL: a month.
3. 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=cover

In 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: immutable on 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? Start your 7-day trial — 10 GB / 200 files / 20 GB bandwidth / 1 dedicated gateway (trial file cap — Bodhi lifts to unlimited). No credit card required. Then Bodhi $5/mo, Karma $19/mo, or Nirvana $59/mo.