Rendiment IPFS: Accelera la Recuperació amb Gateways

“IPFS és lent” és una de les queixes més habituals dels desenvolupadors — i també una de les més solucionables. El culpable gairebé sempre és el mètode d’accés, no el protocol en si. Aquesta guia cobreix quatre tècniques que eliminen la latència d’IPFS en producció.

Tria el teu mètode d’accés IPFS per velocitat#

Si esteu utilitzant gateways públics en producció, canvieu a un gateway dedicat i la major part de la latència desapareixerà immediatament.

Per Què els Gateways Públics Són Lents#

Els gateways públics realitzen una cerca DHT (Distributed Hash Table) per a cada CID que no han vist recentment. La cerca DHT significa consultar dotzenes de peers a la xarxa per trobar qui té el contingut — aquest viatge d’anada i tornada triga de 2 a 15 segons en una petició en fred.

Fins i tot en un encert de memòria cau, els gateways públics serveixen milions d’usuaris. El fitxer que heu fixat recentment té una prioritat de memòria cau baixa i pot ser expulsat entre peticions.

Solució 1: Gateway Dedicat#

Un gateway dedicat és privat per al vostre compte. Els fitxers que fixeu es guarden en memòria cau en aquest gateway immediatament — sense cerca DHT en cap petició, en fred o en calent.

# Abans: gateway públic, lent i poc fiable
curl https://ipfs.io/ipfs/bafybeigdyrzt5sfp7udm7hu76uh7y26nf3efuylqabf3oclgtqy55fbzdi

# Després: gateway dedicat, ràpid i determinista
curl https://my-app.gw.ipfs.ninja/ipfs/bafybeigdyrzt5sfp7udm7hu76uh7y26nf3efuylqabf3oclgtqy55fbzdi

Creeu un gateway al vostre tauler IPFS.NINJA i establiu el slug perquè coincideixi amb el vostre projecte. Els slugs de gateway admeten el mode d’accés restringit (es requereix token) o el mode obert per a recursos estàtics públics.

Solució 2: Fixeu en el Moment d’Escriptura, No de Lectura#

Fixeu els fitxers en el moment en què es creen perquè el gateway els tingui abans que cap usuari els sol·liciti. La petició més ràpida és la que mai no causa una fallada de memòria cau.

# Puja i fixa en un sol pas
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"
  }'

# Resposta — deseu el CID, serviu la URL immediatament
# {
#   "cid": "bafy...",
#   "sizeMB": 0.24,
#   "uris": {
#     "ipfs": "ipfs://bafy...",
#     "url": "https://ipfs.ninja/ipfs/bafy..."
#   }
# }

Si teniu CIDs existents d’un altre node o servei de fixació, torneu a fixar sense tornar a pujar:

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

Vegeu com pujar fitxers a IPFS per a la referència completa de l’API de pujada.

Solució 3: CDN Davant del Vostre Gateway#

Els gateways dedicats serveixen des d’una regió fixa. Si els vostres usuaris es distribueixen per continents, afegiu una capa CDN edge per servir des del punt de presència més proper.

Com que IPFS és adreçat per contingut — un CID determinat sempre es resol en bytes idèntics — podeu guardar en memòria cau per sempre:

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

Exemple amb Cloudflare (el nivell gratuït cobreix la majoria de càrregues de treball d’actius estàtics):

1. Afegiu el subdomini del vostre gateway (my-app.gw.ipfs.ninja) com a CNAME proxiat per Cloudflare.
2. Creeu una regla de pàgina: my-app.gw.ipfs.ninja/ipfs/* → Cache Everything, Edge Cache TTL: un mes.
3. La primera petició arriba al gateway i es guarda en memòria cau al PoP edge més proper. Totes les peticions posteriors es serveixen des de Cloudflare.

Resultat: el TTFB global baixa de 50–200 ms a 10–50 ms.

Solució 4: API d’Optimització d’Imatges#

Les imatges IPFS en brut servides a resolució completa alenteixen les pàgines i perjudiquen els Core Web Vitals. Utilitzeu l’endpoint d’optimització d’imatges per redimensionar al edge i servir formats moderns:

# Original (resolució completa via gateway)
https://my-app.gw.ipfs.ninja/ipfs/bafy...

# Redimensionat a 800 px d'amplada, convertit a WebP
https://api.ipfs.ninja/image/bafy...?w=800&format=webp

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

A React:

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

L’endpoint d’optimització guarda en memòria cau cada combinació de (cid, width, format) — les peticions posteriors amb els mateixos paràmetres ometen completament l’origen.

Llista de Verificació#

• Canvieu dels gateways públics a un gateway dedicat
• Fixeu el contingut en el moment d’escriptura (en pujar), no de lectura
• Establiu Cache-Control: immutable a les respostes del gateway
• Afegiu CDN davant del gateway per al trànsit global
• Serviu imatges via l’endpoint d’optimització en lloc d’URL de gateway en brut

Per obtenir informació sobre per què el pinning importa per a la disponibilitat — no només per a la velocitat — vegeu què és el pinning IPFS.

Llest per començar a fixar? Creeu un compte gratuït — 50 fitxers, 1 GB d’emmagatzematge, 2 GB d’amplada de banda/mes. No cal targeta de crèdit.

Sobre aquest article: Aquest article va ser redactat per un assistent d’IA utilitzant el flux de generació de contingut d’IPFS.NINJA, i després revisat i aprovat per Nacho Coll. Tots els exemples de codi van ser verificats contra l’API d’IPFS.NINJA en viu. Si detecteu una inexactitud, obriu una incidència a https://github.com/ipfs-ninja/feedback. Llegiu més sobre com utilitzem la IA en el nostre contingut i conegueu les persones darrere d’IPFS.NINJA.