Performa IPFS: Cara Mempercepat Pengambilan File dan Gateway

“IPFS itu lambat” adalah salah satu keluhan developer yang paling umum — dan juga salah satu yang paling mudah diperbaiki. Penyebabnya hampir selalu metode akses, bukan protokolnya itu sendiri. Panduan ini mencakup empat teknik yang menghilangkan latensi IPFS di lingkungan produksi.

Referensi Cepat: Metode Akses IPFS Berdasarkan Kecepatan#

Jika Anda menggunakan gateway publik di produksi, beralih ke gateway khusus dan sebagian besar latensi Anda akan langsung hilang.

Mengapa Gateway Publik Itu Lambat#

Gateway publik melakukan pencarian DHT (Distributed Hash Table) pada setiap CID yang belum pernah dilihat baru-baru ini. Pencarian DHT berarti melakukan kueri ke puluhan peer di seluruh jaringan untuk menemukan siapa yang menyimpan konten — perjalanan bolak-balik tersebut memakan waktu 2–15 detik pada permintaan dingin.

Bahkan saat cache hit pun, gateway publik melayani jutaan pengguna. File yang baru saja Anda pin memiliki prioritas cache rendah dan mungkin dihapus di antara permintaan.

Solusi 1: Gateway Khusus#

Gateway khusus bersifat privat untuk akun Anda. File yang Anda pin di-cache pada gateway tersebut secara langsung — tidak ada pencarian DHT pada permintaan apa pun, baik dingin maupun hangat.

# Sebelum: gateway publik, lambat dan tidak dapat diandalkan
curl https://ipfs.io/ipfs/bafybeigdyrzt5sfp7udm7hu76uh7y26nf3efuylqabf3oclgtqy55fbzdi

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

Buat gateway di dasbor IPFS.NINJA dan atur slug agar sesuai dengan proyek Anda. Slug gateway mendukung mode akses terbatas (memerlukan token) atau mode terbuka untuk aset statis publik.

Solusi 2: Pin Saat Menulis, Bukan Saat Membaca#

Pin file saat dibuat agar gateway sudah memilikinya sebelum ada permintaan pengguna. Permintaan tercepat adalah yang tidak pernah menyebabkan cache miss.

# Upload 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, sajikan url-nya langsung
# {
#   "cid": "bafy...",
#   "sizeMB": 0.24,
#   "uris": {
#     "ipfs": "ipfs://bafy...",
#     "url": "https://ipfs.ninja/ipfs/bafy..."
#   }
# }

Jika Anda memiliki CID yang sudah ada dari node atau layanan pinning lain, pin ulang tanpa mengunggah ulang:

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

Lihat cara mengunggah file ke IPFS untuk referensi API upload lengkap.

Solusi 3: CDN di Depan Gateway Anda#

Gateway khusus melayani dari region tetap. Jika pengguna Anda tersebar di berbagai benua, tambahkan lapisan CDN edge untuk melayani dari titik kehadiran terdekat.

Karena IPFS menggunakan content addressing — CID tertentu selalu menghasilkan byte yang identik — Anda dapat melakukan cache selamanya:

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

Contoh Cloudflare (tier gratis mencakup sebagian besar beban kerja aset statis):

1. Tambahkan subdomain gateway Anda (my-app.gw.ipfs.ninja) sebagai CNAME yang diproksikan oleh Cloudflare.
2. Buat Page Rule: my-app.gw.ipfs.ninja/ipfs/* → Cache Everything, Edge Cache TTL: a month.
3. Permintaan pertama menekan gateway dan di-cache di PoP edge terdekat. Semua permintaan berikutnya dilayani dari Cloudflare.

Hasil: TTFB global turun dari 50–200 ms menjadi 10–50 ms.

Solusi 4: API Optimasi Gambar#

Gambar IPFS mentah yang disajikan dalam resolusi penuh memperlambat halaman dan merusak Core Web Vitals. Gunakan endpoint optimasi gambar untuk mengubah ukuran di edge dan menyajikan format modern:

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

# Diubah ukurannya menjadi lebar 800 px, dikonversi ke WebP
https://api.ipfs.ninja/image/bafy...?w=800&format=webp

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

Di React:

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

Endpoint optimasi men-cache setiap kombinasi (cid, width, format) — permintaan berikutnya dengan parameter yang sama melewati origin sepenuhnya.

Daftar Periksa#

• Beralih dari gateway publik ke gateway khusus
• Pin konten saat menulis (saat upload), bukan saat membaca
• Setel Cache-Control: immutable pada respons gateway
• Tambahkan CDN di depan gateway untuk lalu lintas global
• Sajikan gambar melalui endpoint optimasi, bukan URL gateway mentah

Untuk latar belakang mengapa pinning penting untuk ketersediaan — bukan hanya kecepatan — lihat apa itu IPFS pinning.

Siap mulai pinning? Buat akun gratis — 50 file, 1 GB penyimpanan, 2 GB bandwidth/bln. Tidak perlu kartu kredit.

Tentang artikel ini: Artikel ini dibuat oleh asisten AI menggunakan alur kerja pembuatan konten IPFS.NINJA, kemudian ditinjau dan disetujui oleh Nacho Coll. Semua contoh kode telah diverifikasi terhadap API IPFS.NINJA yang aktif. Jika Anda menemukan ketidakakuratan, silakan buka issue di https://github.com/ipfs-ninja/feedback. Baca lebih lanjut tentang cara kami menggunakan AI dalam konten kami dan temui orang-orang di balik IPFS.NINJA.