IPFS Performance: Dateiabfrage per Gateway beschleunigen

„IPFS ist langsam” ist eine der häufigsten Beschwerden von Entwicklern – und gleichzeitig eine der am einfachsten behebbaren. Der Schuldige ist fast immer die Zugriffsmethode, nicht das Protokoll selbst. Dieser Leitfaden behandelt vier Techniken, die IPFS-Latenz in der Produktion eliminieren.

Wählen Sie Ihre IPFS-Zugriffsmethode nach Geschwindigkeit#

Wenn Sie in der Produktion auf öffentliche Gateways zugreifen, wechseln Sie zu einem dedizierten Gateway – und der Großteil Ihrer Latenz verschwindet sofort.

Warum öffentliche Gateways langsam sind#

Öffentliche Gateways führen bei jedem CID, den sie nicht kürzlich gesehen haben, eine DHT-Suche (Distributed Hash Table) durch. DHT-Suche bedeutet, Dutzende von Peers im Netzwerk abzufragen, um herauszufinden, wer den Inhalt besitzt – dieser Roundtrip dauert bei einer kalten Anfrage 2–15 Sekunden.

Selbst bei einem Cache-Treffer bedienen öffentliche Gateways Millionen von Nutzern. Ihre kürzlich gepinnte Datei hat eine niedrige Cache-Priorität und kann zwischen Anfragen gelöscht werden.

Lösung 1: Dediziertes Gateway#

Ein dediziertes Gateway ist privat für Ihr Konto. Dateien, die Sie pinnen, werden sofort auf diesem Gateway gecacht – keine DHT-Suche bei irgendeiner Anfrage, kalt oder warm.

# Vorher: öffentliches Gateway, langsam und unzuverlässig
curl https://ipfs.io/ipfs/bafybeigdyrzt5sfp7udm7hu76uh7y26nf3efuylqabf3oclgtqy55fbzdi

# Nachher: dediziertes Gateway, schnell und deterministisch
curl https://my-app.gw.ipfs.ninja/ipfs/bafybeigdyrzt5sfp7udm7hu76uh7y26nf3efuylqabf3oclgtqy55fbzdi

Erstellen Sie ein Gateway in Ihrem IPFS.NINJA-Dashboard und setzen Sie den Slug entsprechend Ihrem Projekt. Gateway-Slugs unterstützen den eingeschränkten Zugriffsmodus (Token erforderlich) oder den offenen Modus für öffentliche statische Assets.

Lösung 2: Beim Schreiben pinnen, nicht beim Lesen#

Pinnen Sie Dateien in dem Moment, in dem sie erstellt werden, damit das Gateway sie vor einer Benutzeranfrage hat. Die schnellste Anfrage ist eine, die nie einen Cache-Miss verursacht.

# Hochladen und in einem Schritt pinnen
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"
  }'

# Antwort — speichern Sie die CID, dienen Sie die URL sofort
# {
#   "cid": "bafy...",
#   "sizeMB": 0.24,
#   "uris": {
#     "ipfs": "ipfs://bafy...",
#     "url": "https://ipfs.ninja/ipfs/bafy..."
#   }
# }

Wenn Sie vorhandene CIDs von einem anderen Node oder Pinning-Dienst haben, pinnen Sie sie erneut, ohne erneut hochzuladen:

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

Weitere Informationen finden Sie unter Dateien zu IPFS hochladen für die vollständige Upload-API-Referenz.

Lösung 3: CDN vor Ihrem Gateway#

Dedizierte Gateways bedienen aus einer festen Region. Wenn Ihre Nutzer über Kontinente verteilt sind, fügen Sie eine CDN-Edge-Schicht hinzu, um vom nächsten Point of Presence zu bedienen.

Da IPFS content-addressed ist – ein gegebener CID löst immer zu identischen Bytes auf – können Sie unbegrenzt cachen:

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

Cloudflare-Beispiel (kostenlose Stufe deckt die meisten Static-Asset-Workloads ab):

1. Fügen Sie Ihre Gateway-Subdomain (my-app.gw.ipfs.ninja) als Cloudflare-proxied CNAME hinzu.
2. Erstellen Sie eine Page Rule: my-app.gw.ipfs.ninja/ipfs/* → Cache Everything, Edge Cache TTL: ein Monat.
3. Die erste Anfrage trifft das Gateway und wird am nächsten Edge PoP gecacht. Alle nachfolgenden Anfragen werden von Cloudflare bedient.

Ergebnis: Der globale TTFB fällt von 50–200 ms auf 10–50 ms.

Lösung 4: Bildoptimierungs-API#

Rohe IPFS-Bilder in voller Auflösung verlangsamen Seiten und schaden den Core Web Vitals. Verwenden Sie den Bildoptimierungs-Endpunkt, um an der Edge zu skalieren und moderne Formate bereitzustellen:

# Original (volle Auflösung über Gateway)
https://my-app.gw.ipfs.ninja/ipfs/bafy...

# Auf 800 px Breite skaliert, in WebP konvertiert
https://api.ipfs.ninja/image/bafy...?w=800&format=webp

# Quadratisches 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"
    />
  );
}

Der Optimierungs-Endpunkt cachet jede (cid, width, format)-Kombination – nachfolgende Anfragen mit denselben Parametern überspringen den Origin vollständig.

Checkliste#

• Von öffentlichen Gateways auf ein dediziertes Gateway wechseln
• Inhalte beim Schreiben (beim Hochladen) pinnen, nicht beim Lesen
• Cache-Control: immutable auf Gateway-Antworten setzen
• CDN vor dem Gateway für globalen Verkehr hinzufügen
• Bilder über den Optimierungs-Endpunkt statt über rohe Gateway-URLs bedienen

Hintergrundinformationen dazu, warum Pinning für die Verfügbarkeit – nicht nur für die Geschwindigkeit – wichtig ist, finden Sie unter Was ist IPFS Pinning.

Bereit, mit dem Pinnen zu beginnen? Erstellen Sie ein kostenloses Konto — 50 Dateien, 1 GB Speicher, 2 GB Bandbreite/Monat. Keine Kreditkarte erforderlich.

Über diesen Artikel: Dieser Artikel wurde von einem KI-Assistenten mithilfe des Content-Generierungs-Workflows von IPFS.NINJA erstellt und anschließend von Nacho Coll überprüft und genehmigt. Alle Code-Beispiele wurden gegen die Live-API von IPFS.NINJA verifiziert. Wenn Sie eine Ungenauigkeit entdecken, öffnen Sie bitte ein Issue unter https://github.com/ipfs-ninja/feedback. Lesen Sie mehr darüber, wie wir KI in unseren Inhalten einsetzen und lernen Sie die Menschen hinter IPFS.NINJA kennen.