Prestasi IPFS: Percepatkan Pengambilan Fail dengan Gateway

“IPFS lambat” adalah salah satu aduan pembangun yang paling biasa — dan juga salah satu yang paling mudah diselesaikan. Punca masalahnya hampir selalu kaedah akses, bukan protokol itu sendiri. Panduan ini merangkumi empat teknik yang menghapuskan kependaman IPFS dalam persekitaran pengeluaran.

Rujukan Pantas: Kaedah Akses IPFS Mengikut Kelajuan#

Jika anda menggunakan gateway awam dalam pengeluaran, beralih ke gateway khusus dan kebanyakan kependaman anda akan hilang serta-merta.

Mengapa Gateway Awam Lambat#

Gateway awam melakukan carian DHT (Distributed Hash Table) pada setiap CID yang tidak pernah mereka lihat baru-baru ini. Carian DHT bermakna menanya berpuluh-puluh rakan sebaya merentasi rangkaian untuk mencari siapa yang menyimpan kandungan — perjalanan balik itu mengambil masa 2–15 saat pada permintaan sejuk.

Walaupun pada hits cache, gateway awam melayan jutaan pengguna. Fail yang baru anda pin mempunyai keutamaan cache yang rendah dan mungkin disingkirkan antara permintaan.

Penyelesaian 1: Gateway Khusus#

Gateway khusus adalah peribadi untuk akaun anda. Fail yang anda pin di-cache pada gateway itu dengan serta-merta — tiada carian DHT pada mana-mana permintaan, sejuk atau panas.

# Sebelum: gateway awam, lambat dan tidak boleh dipercayai
curl https://ipfs.io/ipfs/bafybeigdyrzt5sfp7udm7hu76uh7y26nf3efuylqabf3oclgtqy55fbzdi

# Selepas: gateway khusus, cepat dan deterministik
curl https://my-app.gw.ipfs.ninja/ipfs/bafybeigdyrzt5sfp7udm7hu76uh7y26nf3efuylqabf3oclgtqy55fbzdi

Cipta gateway dalam papan pemuka IPFS.NINJA anda dan tetapkan slug agar sepadan dengan projek anda. Slug gateway menyokong mod akses terhad (token diperlukan) atau mod terbuka untuk aset statik awam.

Penyelesaian 2: Pin pada Masa Tulis, Bukan Masa Baca#

Pin fail pada saat ia dicipta supaya gateway mempunyainya sebelum mana-mana pengguna memintanya. Permintaan terpantas adalah yang tidak pernah menyebabkan cache miss.

# Muat naik dan pin dalam satu langkah
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"
  }'

# Respons — simpan CID, hidangkan url dengan serta-merta
# {
#   "cid": "bafy...",
#   "sizeMB": 0.24,
#   "uris": {
#     "ipfs": "ipfs://bafy...",
#     "url": "https://ipfs.ninja/ipfs/bafy..."
#   }
# }

Jika anda mempunyai CID sedia ada dari nod atau perkhidmatan pinning lain, pin semula tanpa muat naik semula:

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

Lihat cara memuat naik fail ke IPFS untuk rujukan API muat naik penuh.

Penyelesaian 3: CDN di Hadapan Gateway Anda#

Gateway khusus melayan dari rantau tetap. Jika pengguna anda merentasi benua, tambah lapisan tepi CDN untuk melayan dari titik kehadiran terdekat.

Kerana IPFS adalah kandungan beralamat — CID tertentu sentiasa diselesaikan kepada bait yang sama — anda boleh cache selamanya:

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

Contoh Cloudflare (tier percuma meliputi kebanyakan beban kerja aset statik):

1. Tambah subdomain gateway anda (my-app.gw.ipfs.ninja) sebagai CNAME yang diproksi Cloudflare.
2. Cipta Page Rule: my-app.gw.ipfs.ninja/ipfs/* → Cache Everything, Edge Cache TTL: sebulan.
3. Permintaan pertama menyentuh gateway dan di-cache di PoP tepi terdekat. Semua permintaan seterusnya dilayan dari Cloudflare.

Keputusan: TTFB global turun dari 50–200 ms ke 10–50 ms.

Penyelesaian 4: API Pengoptimuman Imej#

Imej IPFS mentah yang dilayan pada resolusi penuh melambatkan halaman dan menjejaskan Core Web Vitals. Gunakan titik akhir pengoptimuman imej untuk mengubah saiz di tepi dan menghidangkan format moden:

# Asal (resolusi penuh melalui gateway)
https://my-app.gw.ipfs.ninja/ipfs/bafy...

# Diubah saiz kepada lebar 800 px, ditukar ke WebP
https://api.ipfs.ninja/image/bafy...?w=800&format=webp

# Lakaran kecil segi empat sama
https://api.ipfs.ninja/image/bafy...?w=200&h=200&fit=cover

Dalam React:

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

Titik akhir pengoptimuman men-cache setiap kombinasi (cid, width, format) — permintaan seterusnya dengan parameter yang sama melangkau asal sepenuhnya.

Senarai Semak#

• Beralih dari gateway awam ke gateway khusus
• Pin kandungan pada masa tulis (semasa muat naik), bukan pada masa baca
• Tetapkan Cache-Control: immutable pada respons gateway
• Tambah CDN di hadapan gateway untuk trafik global
• Hidangkan imej melalui titik akhir pengoptimuman dan bukannya URL gateway mentah

Untuk latar belakang tentang mengapa pinning penting untuk ketersediaan — bukan sahaja kelajuan — lihat apa itu IPFS pinning.

Bersedia untuk mula pin? Cipta akaun percuma — 50 fail, 1 GB storan, 2 GB lebar jalur/bln. Tiada kad kredit diperlukan.

Tentang artikel ini: Artikel ini digubal oleh pembantu AI menggunakan aliran kerja penjanaan kandungan IPFS.NINJA, kemudian disemak dan diluluskan oleh Nacho Coll. Semua contoh kod telah disahkan terhadap API IPFS.NINJA yang aktif. Jika anda menemui ketidaktepatan, sila buka isu di https://github.com/ipfs-ninja/feedback. Baca lebih lanjut tentang cara kami menggunakan AI dalam kandungan kami dan temui orang-orang di sebalik IPFS.NINJA.