IPFS-prestanda: snabba upp filhämtning och gateway-svarstider

“IPFS är långsamt” är ett av de vanligaste klagomålen från utvecklare — och också ett av de mest åtgärdbara. Boven är nästan alltid åtkomstmetoden, inte protokollet i sig. Den här guiden täcker fyra tekniker som eliminerar IPFS-latens i produktion.

Välj din IPFS-åtkomstmetod efter hastighet#

Om du träffar publika gateways i produktion, byt till en dedikerad gateway och merparten av latensen försvinner omedelbart.

Varför publika gateways är långsamma#

Publika gateways utför en DHT (Distributed Hash Table)-sökning för varje CID de inte nyligen sett. DHT-sökning innebär att man frågar dussintals peers över nätverket för att hitta vem som har innehållet — den rundresan tar 2–15 sekunder vid en kall förfrågan.

Även vid en cache-träff betjänar publika gateways miljontals användare. Din nyligen pinnade fil har låg cache-prioritet och kan rensas bort mellan förfrågningar.

Lösning 1: Dedikerad gateway#

En dedikerad gateway är privat för ditt konto. Filer du pinnar cachas på den gatewayen omedelbart — ingen DHT-sökning vid någon förfrågan, kall eller varm.

# Före: publik gateway, långsam och opålitlig
curl https://ipfs.io/ipfs/bafybeigdyrzt5sfp7udm7hu76uh7y26nf3efuylqabf3oclgtqy55fbzdi

# Efter: dedikerad gateway, snabb och deterministisk
curl https://my-app.gw.ipfs.ninja/ipfs/bafybeigdyrzt5sfp7udm7hu76uh7y26nf3efuylqabf3oclgtqy55fbzdi

Skapa en gateway i din IPFS.NINJA-dashboard och sätt slug:en till att matcha ditt projekt. Gateway-sluggar stödjer restricted access mode (token krävs) eller open mode för publika statiska resurser.

Lösning 2: Pinna vid skrivtid, inte läsningstid#

Pinna filer i samma ögonblick de skapas så att gatewayen har dem innan någon användare begär dem. Den snabbaste förfrågan är den som aldrig orsakar en cache-miss.

# Ladda upp och pinna i ett steg
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"
  }'

# Svar — spara CID:n, servera url:en omedelbart
# {
#   "cid": "bafy...",
#   "sizeMB": 0.24,
#   "uris": {
#     "ipfs": "ipfs://bafy...",
#     "url": "https://ipfs.ninja/ipfs/bafy..."
#   }
# }

Om du har befintliga CID:er från en annan nod eller pinning-tjänst, pinna om utan att ladda upp igen:

curl -X POST https://api.ipfs.ninja/pin \
  -H "X-Api-Key: bws_a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4" \
  -H "Content-Type: application/json" \
  -d '{"cid": "bafybeigdyrzt5sfp7udm7hu76uh7y26nf3efuylqabf3oclgtqy55fbzdi"}'

Se hur man laddar upp filer till IPFS för fullständig API-referens.

Lösning 3: CDN framför din gateway#

Dedikerade gateways serverar från en fast region. Om dina användare sträcker sig över kontinenter, lägg till ett CDN edge-lager för att servera från närmaste närvaro.

Eftersom IPFS är content-addressed — ett givet CID löser alltid till identiska bytes — kan du cacha för evigt:

Cache-Control: public, max-age=31536000, immutable

Cloudflare-exempel (gratistjänsten täcker de flesta arbetsbelastningar med statiska resurser):

1. Lägg till din gateway-subdomän (my-app.gw.ipfs.ninja) som ett Cloudflare proxied CNAME.
2. Skapa en Page Rule: my-app.gw.ipfs.ninja/ipfs/* → Cache Everything, Edge Cache TTL: en månad.
3. Den första förfrågan träffar gatewayen och cachas vid närmaste edge PoP. Alla efterföljande förfrågningar serveras från Cloudflare.

Resultat: global TTFB sjunker från 50–200 ms till 10–50 ms.

Lösning 4: Bildoptimerings-API#

Råa IPFS-bilder serverade i full upplösning gör sidor långsamma och skadar Core Web Vitals. Använd bildoptimerings-endpointen för att ändra storlek vid edge och servera moderna format:

# Original (full upplösning via gateway)
https://my-app.gw.ipfs.ninja/ipfs/bafy...

# Ändrad till 800 px bred, konverterad till WebP
https://api.ipfs.ninja/image/bafy...?w=800&format=webp

# Kvadratisk miniatyrbild
https://api.ipfs.ninja/image/bafy...?w=200&h=200&fit=cover

I React:

function IPFSImage({ cid, width }) {
  return (
    <img
      src={`https://api.ipfs.ninja/image/${cid}?w=${width}&format=webp`}
      width={width}
      loading="lazy"
      decoding="async"
    />
  );
}

Optimerings-endpointen cachar varje (cid, width, format)-kombination — efterföljande förfrågningar med samma parametrar hoppar helt över origin.

Checklista#

• Byt från publika gateways till en dedikerad gateway
• Pinna innehåll vid skrivtid (vid uppladdning), inte vid läsningstid
• Sätt Cache-Control: immutable på gateway-svar
• Lägg till CDN framför gatewayen för global trafik
• Servera bilder via optimerings-endpointen istället för råa gateway-URL:er

För bakgrund om varför pinning spelar roll för tillgänglighet — inte bara hastighet — se vad är IPFS pinning.

Redo att börja pinna? Skapa ett gratis konto — 50 filer, 1 GB lagring, 2 GB bandbredd/mån. Inget kreditkort krävs.

Om den här artikeln: Den här artikeln utformades av en AI-assistent med hjälp av IPFS.NINJA:s arbetsflöde för innehållsgenerering och granskades sedan och godkändes av Nacho Coll. Alla kodexempel verifierades mot det live IPFS.NINJA API:et. Om du hittar en felaktighet, öppna gärna ett ärende på https://github.com/ipfs-ninja/feedback. Läs mer om hur vi använder AI i vårt innehåll och möt personerna bakom IPFS.NINJA.