Wydajność IPFS: przyspiesz pobieranie z dedykowanym gateway

Praktyczne techniki poprawy szybkości pobierania plików IPFS: dedykowane gateway, strategie cachowania, wstępne ładowanie i integracja z CDN.

Nacho Collautor: Zaktualizowano: 6 min czytania
Praktyczne techniki poprawy szybkości pobierania plików IPFS: dedykowane gateway, strategie cachowania, wstępne ładowanie i integracja z CDN.
W skrócie
  • Zamień publiczne bramy na dedykowaną bramę, by skrócić opóźnienie IPFS z sekund do poniżej 200 ms.
  • Publiczne bramy wykonują wyszukiwanie DHT dla zimnych CID, co dodaje 2–15 sekund przed rozwiązaniem zawartości.
  • Pinuj pliki w momencie zapisu, a nie odczytu, by brama już je przechowywała przed pierwszym żądaniem.
  • Połącz dedykowaną bramę z edge CDN, by obniżyć globalne opóźnienie IPFS do 10–50 ms.

„IPFS jest wolny” to jedna z najczęstszych skarg deweloperów — i jedna z najbardziej do rozwiązania. Winowajcą jest prawie zawsze metoda dostępu, a nie sam protokół. Ten przewodnik opisuje cztery techniki eliminujące opóźnienia IPFS w środowisku produkcyjnym.

IPFS Ninja

Szybki przegląd: metody dostępu IPFS według szybkości#

Metoda dostępuTypowy TTFBKiedy używać
Publiczny gateway (ipfs.io, dweb.link)2–15 sTylko programowanie i testy
Dedykowany gateway (przypięta zawartość)50–200 msCały ruch produkcyjny
Dedykowany gateway + edge CDN10–50 msGlobalna baza użytkowników
Endpoint optymalizacji obrazów<100 ms (ciepły)Cała zawartość obrazów

Jeśli używasz publicznych gateway w produkcji, przejdź na dedykowany gateway — większość opóźnień zniknie natychmiast.

Dlaczego publiczne gateway są wolne#

Publiczne gateway wykonują wyszukiwanie DHT (Distributed Hash Table) dla każdego CID, którego ostatnio nie widziały. Wyszukiwanie DHT oznacza odpytywanie dziesiątek węzłów sieci w poszukiwaniu właściciela zawartości — ta podróż w obie strony trwa 2–15 sekund przy zimnym żądaniu.

Nawet przy trafieniu w cache, publiczne gateway obsługują miliony użytkowników. Twój niedawno przypięty plik ma niski priorytet w cache i może zostać usunięty między żądaniami.

Rozwiązanie 1: Dedykowany gateway#

Dedykowany gateway jest prywatny dla Twojego konta. Pliki, które przypinasz, są natychmiast cachowane na tym gateway — żadnego wyszukiwania DHT dla żadnego żądania, zimnego ani ciepłego.

# Przed: publiczny gateway, wolny i zawodny
curl https://ipfs.io/ipfs/bafybeigdyrzt5sfp7udm7hu76uh7y26nf3efuylqabf3oclgtqy55fbzdi

# Po: dedykowany gateway, szybki i deterministyczny
curl https://my-app.gw.ipfs.ninja/ipfs/bafybeigdyrzt5sfp7udm7hu76uh7y26nf3efuylqabf3oclgtqy55fbzdi

Utwórz gateway w swoim panelu IPFS.NINJA i ustaw slug odpowiadający Twojemu projektowi. Slug gateway obsługuje tryb ograniczonego dostępu (wymagany token) lub tryb otwarty dla publicznych zasobów statycznych.

Rozwiązanie 2: Przypinaj podczas zapisu, nie podczas odczytu#

Przypinaj pliki w momencie ich tworzenia, aby gateway miał je przed jakimkolwiek żądaniem użytkownika. Najszybsze żądanie to takie, które nigdy nie powoduje chybienia cache.

# Prześlij i przypnij w jednym kroku
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"
  }'

# Odpowiedź — zapisz CID, od razu serwuj url
# {
#   "cid": "bafy...",
#   "sizeMB": 0.24,
#   "uris": {
#     "ipfs": "ipfs://bafy...",
#     "url": "https://ipfs.ninja/ipfs/bafy..."
#   }
# }

Jeśli masz istniejące CID z innego węzła lub usługi przypinania, przypnij ponownie bez ponownego przesyłania:

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

Zobacz jak przesyłać pliki do IPFS, aby zapoznać się z pełną dokumentacją API przesyłania.

Rozwiązanie 3: CDN przed Twoim gateway#

Dedykowane gateway obsługują z ustalonego regionu. Jeśli Twoi użytkownicy są rozproszeni po kontynentach, dodaj warstwę edge CDN, aby obsługiwać z najbliższego punktu obecności.

Ponieważ IPFS jest adresowany treścią — dany CID zawsze resolwuje do identycznych bajtów — możesz cachować w nieskończoność:

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

Przykład Cloudflare (plan bezpłatny pokrywa większość obciążeń zasobów statycznych):

  1. Dodaj subdomenę gateway (my-app.gw.ipfs.ninja) jako proxied CNAME przez Cloudflare.
  2. Utwórz Page Rule: my-app.gw.ipfs.ninja/ipfs/*Cache Everything, Edge Cache TTL: miesiąc.
  3. Pierwsze żądanie trafia do gateway i jest cachowane w najbliższym edge PoP. Wszystkie kolejne żądania są obsługiwane z Cloudflare.

Wynik: globalny TTFB spada z 50–200 ms do 10–50 ms.

Rozwiązanie 4: API optymalizacji obrazów#

Surowe obrazy IPFS serwowane w pełnej rozdzielczości spowalniają strony i szkodzą Core Web Vitals. Użyj endpointu optymalizacji obrazów, aby zmieniać rozmiar na krawędzi i serwować nowoczesne formaty:

# Oryginał (pełna rozdzielczość przez gateway)
https://my-app.gw.ipfs.ninja/ipfs/bafy...

# Zmieniony rozmiar do 800 px szerokości, skonwertowany do WebP
https://api.ipfs.ninja/image/bafy...?w=800&format=webp

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

W React:

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

Endpoint optymalizacji cachuje każdą kombinację (cid, width, format) — kolejne żądania z tymi samymi parametrami całkowicie pomijają origin.

Lista kontrolna#

  • Przejdź z publicznych gateway na dedykowany gateway
  • Przypinaj zawartość podczas zapisu (przy przesyłaniu), a nie podczas odczytu
  • Ustaw Cache-Control: immutable na odpowiedziach gateway
  • Dodaj CDN przed gateway dla globalnego ruchu
  • Serwuj obrazy przez endpoint optymalizacji zamiast surowych URL-i gateway

Aby poznać tło dotyczące tego, dlaczego przypinanie jest ważne dla dostępności — nie tylko szybkości — zobacz czym jest IPFS pinning.


Gotowy, żeby zacząć przypinać? Utwórz bezpłatne konto — 50 plików, 1 GB pamięci, 2 GB przepustowości/mies. Karta kredytowa nie jest wymagana.

O tym artykule: Ten artykuł został opracowany przez asystenta AI przy użyciu przepływu pracy generowania treści IPFS.NINJA, a następnie przejrzany i zatwierdzony przez Nacho Coll. Wszystkie przykłady kodu zostały zweryfikowane na podstawie działającego API IPFS.NINJA. Jeśli zauważysz nieścisłość, otwórz zgłoszenie na https://github.com/ipfs-ninja/feedback. Przeczytaj więcej o tym, jak używamy AI w naszych treściach i poznaj ludzi stojących za IPFS.NINJA.

Nacho Coll

O autorze

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.

Wróć do Bloga

Powiązane Artykuły