Prestazioni IPFS: accelera il recupero con gateway dedicato

“IPFS è lento” è una delle lamentele più comuni degli sviluppatori — e anche una delle più facili da risolvere. Il colpevole è quasi sempre il metodo di accesso, non il protocollo in sé. Questa guida illustra quattro tecniche che eliminano la latenza IPFS in produzione.

Riferimento rapido: metodi di accesso IPFS per velocità#

Se stai usando gateway pubblici in produzione, passa a un gateway dedicato e la maggior parte della latenza scomparirà immediatamente.

Perché i gateway pubblici sono lenti#

I gateway pubblici eseguono una ricerca DHT (Distributed Hash Table) per ogni CID che non hanno visto di recente. La ricerca DHT significa interrogare dozzine di peer attraverso la rete per trovare chi detiene il contenuto — questo viaggio di andata e ritorno richiede 2–15 secondi su una richiesta fredda.

Anche in caso di cache hit, i gateway pubblici servono milioni di utenti. Il file che hai appena pinnato ha bassa priorità di cache e può essere espulso tra una richiesta e l’altra.

Soluzione 1: Gateway dedicato#

Un gateway dedicato è privato per il tuo account. I file che pinni vengono memorizzati immediatamente in cache su quel gateway — nessuna ricerca DHT su nessuna richiesta, fredda o calda.

# Prima: gateway pubblico, lento e inaffidabile
curl https://ipfs.io/ipfs/bafybeigdyrzt5sfp7udm7hu76uh7y26nf3efuylqabf3oclgtqy55fbzdi

# Dopo: gateway dedicato, veloce e deterministico
curl https://my-app.gw.ipfs.ninja/ipfs/bafybeigdyrzt5sfp7udm7hu76uh7y26nf3efuylqabf3oclgtqy55fbzdi

Crea un gateway nella tua dashboard IPFS.NINJA e imposta lo slug per corrispondere al tuo progetto. Gli slug del gateway supportano la modalità di accesso limitato (token richiesto) o la modalità aperta per risorse statiche pubbliche.

Soluzione 2: Pinna al momento della scrittura, non della lettura#

Pinna i file nel momento in cui vengono creati così il gateway li ha prima che qualsiasi utente li richieda. La richiesta più veloce è quella che non causa mai un cache miss.

# Carica e pinna in un unico passaggio
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"
  }'

# Risposta — salva il CID, servi subito l'url
# {
#   "cid": "bafy...",
#   "sizeMB": 0.24,
#   "uris": {
#     "ipfs": "ipfs://bafy...",
#     "url": "https://ipfs.ninja/ipfs/bafy..."
#   }
# }

Se hai CID esistenti da un altro nodo o servizio di pinning, ri-pinna senza ricaricare:

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

Consulta come caricare file su IPFS per il riferimento completo dell’API di upload.

Soluzione 3: CDN davanti al tuo gateway#

I gateway dedicati servono da una regione fissa. Se i tuoi utenti sono distribuiti su più continenti, aggiungi un livello CDN edge per servire dal punto di presenza più vicino.

Poiché IPFS usa l’indirizzamento per contenuto — un dato CID risolve sempre in byte identici — puoi memorizzare in cache per sempre:

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

Esempio con Cloudflare (il piano gratuito copre la maggior parte dei carichi di lavoro con risorse statiche):

1. Aggiungi il sottodominio del tuo gateway (my-app.gw.ipfs.ninja) come CNAME proxiato Cloudflare.
2. Crea una Page Rule: my-app.gw.ipfs.ninja/ipfs/* → Cache Everything, Edge Cache TTL: a month.
3. La prima richiesta raggiunge il gateway e viene memorizzata in cache nel PoP edge più vicino. Tutte le richieste successive vengono servite da Cloudflare.

Risultato: il TTFB globale scende da 50–200 ms a 10–50 ms.

Soluzione 4: API di ottimizzazione immagini#

Le immagini IPFS grezze servite a piena risoluzione rallentano le pagine e penalizzano i Core Web Vitals. Usa l’endpoint di ottimizzazione immagini per ridimensionare all’edge e servire formati moderni:

# Originale (piena risoluzione via gateway)
https://my-app.gw.ipfs.ninja/ipfs/bafy...

# Ridimensionato a 800 px di larghezza, convertito in WebP
https://api.ipfs.ninja/image/bafy...?w=800&format=webp

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

L’endpoint di ottimizzazione memorizza in cache ogni combinazione (cid, width, format) — le richieste successive con gli stessi parametri saltano completamente l’origine.

Checklist#

• Passa dai gateway pubblici a un gateway dedicato
• Pinna il contenuto al momento della scrittura (all’upload), non della lettura
• Imposta Cache-Control: immutable sulle risposte del gateway
• Aggiungi un CDN davanti al gateway per il traffico globale
• Servi le immagini tramite l’endpoint di ottimizzazione invece degli URL raw del gateway

Per capire perché il pinning è importante per la disponibilità — non solo per la velocità — consulta cos’è il pinning IPFS.

Pronto a iniziare a pinnare? Crea un account gratuito — 50 file, 1 GB di spazio, 2 GB di banda/mese. Nessuna carta di credito richiesta.

Informazioni su questo articolo: questo articolo è stato redatto da un assistente AI usando il workflow di generazione dei contenuti di IPFS.NINJA, poi revisionato e approvato da Nacho Coll. Tutti gli esempi di codice sono stati verificati sull’API IPFS.NINJA in produzione. Se noti un’inesattezza, apri una segnalazione su https://github.com/ipfs-ninja/feedback. Scopri di più su come usiamo l’AI nei nostri contenuti e conosci le persone dietro IPFS.NINJA.