Performance IPFS : accélérez la récupération avec gateway

« IPFS est lent » est l’une des plaintes les plus fréquentes des développeurs — et aussi l’une des plus faciles à résoudre. Le coupable est presque toujours la méthode d’accès, pas le protocole lui-même. Ce guide couvre quatre techniques qui éliminent la latence IPFS en production.

Choisissez votre méthode d’accès IPFS par vitesse#

Si vous utilisez des gateways publiques en production, passez à une gateway dédiée et la plupart de votre latence disparaît immédiatement.

Pourquoi les gateways publiques sont lentes#

Les gateways publiques effectuent une recherche DHT (Distributed Hash Table) pour chaque CID qu’elles n’ont pas vu récemment. La recherche DHT consiste à interroger des dizaines de pairs à travers le réseau pour trouver qui détient le contenu — cet aller-retour prend 2–15 secondes sur une requête froide.

Même en cas de succès du cache, les gateways publiques servent des millions d’utilisateurs. Votre fichier récemment épinglé a une faible priorité de cache et peut être évincé entre les requêtes.

Solution 1 : Gateway dédiée#

Une gateway dédiée est privée à votre compte. Les fichiers que vous épinglez sont mis en cache sur cette gateway immédiatement — aucune recherche DHT sur aucune requête, froide ou chaude.

# Avant : gateway publique, lente et peu fiable
curl https://ipfs.io/ipfs/bafybeigdyrzt5sfp7udm7hu76uh7y26nf3efuylqabf3oclgtqy55fbzdi

# Après : gateway dédiée, rapide et déterministe
curl https://my-app.gw.ipfs.ninja/ipfs/bafybeigdyrzt5sfp7udm7hu76uh7y26nf3efuylqabf3oclgtqy55fbzdi

Créez une gateway dans votre tableau de bord IPFS.NINJA et définissez le slug pour correspondre à votre projet. Les slugs de gateway supportent le mode d’accès restreint (token requis) ou le mode ouvert pour les ressources statiques publiques.

Solution 2 : Épingler à l’écriture, pas à la lecture#

Épinglez les fichiers au moment de leur création afin que la gateway les ait avant toute requête utilisateur. La requête la plus rapide est celle qui ne provoque jamais de défaut de cache.

# Uploader et épingler en une seule étape
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"
  }'

# Réponse — stockez le CID, servez l'url immédiatement
# {
#   "cid": "bafy...",
#   "sizeMB": 0.24,
#   "uris": {
#     "ipfs": "ipfs://bafy...",
#     "url": "https://ipfs.ninja/ipfs/bafy..."
#   }
# }

Si vous avez des CID existants provenant d’un autre nœud ou d’un service d’épinglage, ré-épinglez sans re-uploader :

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

Consultez comment uploader des fichiers vers IPFS pour la référence complète de l’API d’upload.

Solution 3 : CDN devant votre gateway#

Les gateways dédiées servent depuis une région fixe. Si vos utilisateurs sont répartis sur plusieurs continents, ajoutez une couche edge CDN pour servir depuis le point de présence le plus proche.

Comme IPFS utilise l’adressage par contenu — un CID donné se résout toujours en des octets identiques — vous pouvez mettre en cache indéfiniment :

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

Exemple Cloudflare (le niveau gratuit couvre la plupart des charges de travail avec ressources statiques) :

1. Ajoutez le sous-domaine de votre gateway (my-app.gw.ipfs.ninja) comme CNAME proxifié Cloudflare.
2. Créez une Page Rule : my-app.gw.ipfs.ninja/ipfs/* → Cache Everything, Edge Cache TTL: a month.
3. La première requête atteint la gateway et est mise en cache au PoP edge le plus proche. Toutes les requêtes suivantes sont servies depuis Cloudflare.

Résultat : le TTFB global passe de 50–200 ms à 10–50 ms.

Solution 4 : API d’optimisation d’images#

Les images IPFS brutes servies en pleine résolution ralentissent les pages et nuisent aux Core Web Vitals. Utilisez l’endpoint d’optimisation d’images pour redimensionner au edge et servir des formats modernes :

# Original (pleine résolution via gateway)
https://my-app.gw.ipfs.ninja/ipfs/bafy...

# Redimensionné à 800 px de large, converti en WebP
https://api.ipfs.ninja/image/bafy...?w=800&format=webp

# Miniature carrée
https://api.ipfs.ninja/image/bafy...?w=200&h=200&fit=cover

En 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’optimisation met en cache chaque combinaison (cid, width, format) — les requêtes suivantes avec les mêmes paramètres contournent entièrement l’origine.

Liste de contrôle#

• Passer des gateways publiques à une gateway dédiée
• Épingler le contenu à l’écriture (lors de l’upload), pas à la lecture
• Définir Cache-Control: immutable sur les réponses de la gateway
• Ajouter un CDN devant la gateway pour le trafic mondial
• Servir les images via l’endpoint d’optimisation plutôt que les URLs brutes de la gateway

Pour comprendre pourquoi l’épinglage est important pour la disponibilité — pas seulement la vitesse — consultez qu’est-ce que l’épinglage IPFS.

Prêt à commencer l’épinglage ? Créez un compte gratuit — 50 fichiers, 1 Go de stockage, 2 Go de bande passante/mois. Aucune carte de crédit requise.

À propos de cet article : cet article a été rédigé par un assistant IA à l’aide du workflow de génération de contenu d’IPFS.NINJA, puis relu et approuvé par Nacho Coll. Tous les exemples de code ont été vérifiés par rapport à l’API IPFS.NINJA en production. Si vous repérez une inexactitude, ouvrez un ticket sur https://github.com/ipfs-ninja/feedback. En savoir plus sur la façon dont nous utilisons l’IA dans notre contenu et rencontrez les personnes derrière IPFS.NINJA.