IPFS teljesítmény: gyorsítsa a fájllekérést gateway-jel

„Az IPFS lassú” az egyik leggyakoribb fejlesztői panasz — és egyben az egyik legjobban megoldható is. A hibás szinte mindig a hozzáférési módszer, nem maga a protokoll. Ez az útmutató négy technikát mutat be, amelyek kiküszöbölik az IPFS latenciát éles környezetben.

Gyors összefoglaló: IPFS hozzáférési módszerek sebesség szerint#

Ha éles környezetben nyilvános gatewayeket használsz, válts dedikált gatewayre, és a latencia nagy része azonnal eltűnik.

Miért lassúak a nyilvános gatewayek#

A nyilvános gatewayek DHT (Distributed Hash Table) keresést végeznek minden CID-re, amelyet nem láttak nemrég. A DHT keresés azt jelenti, hogy tucatnyi peer-t kérdeznek meg a hálózaton a tartalom gazdájának megtalálásához — ez az oda-vissza út hideg kérésnél 2–15 másodpercet vesz igénybe.

Még gyorsítótár-találat esetén is, a nyilvános gatewayek millió felhasználót szolgálnak ki. A nemrég rögzített fájlod alacsony gyorsítótár-prioritással rendelkezik, és kérések között ki is ürülhet.

1. megoldás: Dedikált gateway#

A dedikált gateway privát a fiókod számára. A rögzített fájlok azonnal gyorsítótárba kerülnek a gatewayen — nincs DHT keresés egyetlen kérésnél sem, legyen az hideg vagy meleg.

# Előtte: nyilvános gateway, lassú és megbízhatatlan
curl https://ipfs.io/ipfs/bafybeigdyrzt5sfp7udm7hu76uh7y26nf3efuylqabf3oclgtqy55fbzdi

# Utána: dedikált gateway, gyors és determinisztikus
curl https://my-app.gw.ipfs.ninja/ipfs/bafybeigdyrzt5sfp7udm7hu76uh7y26nf3efuylqabf3oclgtqy55fbzdi

Hozz létre egy gatewayt az IPFS.NINJA irányítópulton, és állítsd be a slugot a projektednek megfelelően. A gateway slugok korlátozott hozzáférési módot támogatnak (token szükséges) vagy nyílt módot nyilvános statikus erőforrásokhoz.

2. megoldás: Rögzítsd íráskor, ne olvasáskor#

Rögzítsd a fájlokat létrehozásuk pillanatában, hogy a gateway rendelkezzen velük, mielőtt bármely felhasználó kéri azokat. A leggyorsabb kérés az, amely soha nem okoz gyorsítótár-kihagyást.

# Feltöltés és rögzítés egy lépésben
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"
  }'

# Válasz — tárold a CID-et, azonnal szolgáld ki az url-t
# {
#   "cid": "bafy...",
#   "sizeMB": 0.24,
#   "uris": {
#     "ipfs": "ipfs://bafy...",
#     "url": "https://ipfs.ninja/ipfs/bafy..."
#   }
# }

Ha meglévő CID-jeid vannak egy másik csomópontból vagy rögzítési szolgáltatásból, rögzítsd újra feltöltés nélkül:

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

A teljes feltöltési API-referenciáért lásd: hogyan tölts fel fájlokat IPFS-re.

3. megoldás: CDN a gateway elé#

A dedikált gatewayek rögzített régióból szolgálnak ki. Ha a felhasználóid több kontinensen szétszórva vannak, adj hozzá egy CDN edge réteget a legközelebbi jelenléti pontból való kiszolgáláshoz.

Mivel az IPFS tartalomcímzést használ — egy adott CID mindig azonos bájtokat old fel —, örökre gyorsítótárazhatod:

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

Cloudflare-példa (az ingyenes szint lefedi a legtöbb statikus erőforrás-terhelést):

1. Add hozzá a gateway aldomainedet (my-app.gw.ipfs.ninja) Cloudflare proxyzott CNAME-ként.
2. Hozz létre egy Page Rule-t: my-app.gw.ipfs.ninja/ipfs/* → Cache Everything, Edge Cache TTL: a month.
3. Az első kérés eléri a gatewayt, és a legközelebbi edge PoP-on gyorsítótárba kerül. Az összes további kérés Cloudflare-ből kerül kiszolgálásra.

Eredmény: a globális TTFB 50–200 ms-ről 10–50 ms-re csökken.

4. megoldás: Képoptimalizálási API#

A teljes felbontásban kiszolgált nyers IPFS-képek lassítják az oldalakat és rontják a Core Web Vitals értékeit. Használd a képoptimalizálási endpointot az átméretezéshez az edgeen és modern formátumok kiszolgálásához:

# Eredeti (teljes felbontás gatewayen keresztül)
https://my-app.gw.ipfs.ninja/ipfs/bafy...

# 800 px szélességűre átméretezve, WebP-vé konvertálva
https://api.ipfs.ninja/image/bafy...?w=800&format=webp

# Négyzetes bélyegkép
https://api.ipfs.ninja/image/bafy...?w=200&h=200&fit=cover

Reactban:

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

Az optimalizálási endpoint minden (cid, width, format) kombinációt gyorsítótáraz — az azonos paraméterekkel érkező további kérések teljesen kihagyják az origint.

Ellenőrzőlista#

• Váltás nyilvános gatewayekről dedikált gatewayre
• Tartalom rögzítése íráskor (feltöltéskor), nem olvasáskor
• Cache-Control: immutable beállítása a gateway válaszokon
• CDN hozzáadása a gateway elé a globális forgalomhoz
• Képek kiszolgálása az optimalizálási endpointon keresztül, nem nyers gateway URL-eken

A háttérről, hogy miért fontos a rögzítés az elérhetőség szempontjából — nem csak a sebesség miatt —, lásd: mi az IPFS rögzítés.

Készen állsz a rögzítés megkezdésére? Hozz létre ingyenes fiókot — 50 fájl, 1 GB tárhely, 2 GB sávszélesség/hó. Nem szükséges bankkártya.

A cikkről: ezt a cikket egy AI-asszisztens készítette az IPFS.NINJA tartalomgenerálási munkafolyamata segítségével, majd Nacho Coll átnézte és jóváhagyta. Minden kódpéldát az élő IPFS.NINJA API-val szemben ellenőriztek. Ha pontatlanságot talász, nyiss issue-t a https://github.com/ipfs-ninja/feedback oldalon. Tudj meg többet arról, hogyan használjuk az AI-t tartalmainban, és ismerkedj meg az IPFS.NINJA mögötti emberekkel.