· · Guides  · 6 min read

IPFS Performance: How to Speed Up File Retrieval and Gateway Response Times

Practical techniques to improve IPFS file retrieval speed: dedicated gateways, caching strategies, preloading, and CDN integration.

Practical techniques to improve IPFS file retrieval speed: dedicated gateways, caching strategies, preloading, and CDN integration.

“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.

IPFS Ninja

Quick-Reference: IPFS Access Methods by Speed

Access methodTypical TTFBWhen to use
Public gateway (ipfs.io, dweb.link)2–15 sDevelopment and testing only
Dedicated gateway (pinned content)50–200 msAll production traffic
Dedicated gateway + CDN edge10–50 msGlobal 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/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? Create a free account — 50 files, 1 GB storage, 2 GB bandwidth/mo. No credit card required.

About this article: This article was drafted by an AI assistant using IPFS.NINJA’s content generation workflow, then reviewed and approved by Nacho Coll. All code examples were verified against the live IPFS.NINJA API. If you spot an inaccuracy, please open an issue at https://github.com/ipfs-ninja/feedback. Read more about how we use AI in our content and meet the people behind IPFS.NINJA.

Back to Blog

Related Posts

View All Posts »