Продуктивність IPFS: прискорте отримання файлів

Практичні техніки для підвищення швидкості отримання файлів IPFS: виділені gateway, стратегії кешування, preloading та інтеграція з CDN.

Nacho Collавтор Оновлено: 5 хв читання
Практичні техніки для підвищення швидкості отримання файлів IPFS: виділені gateway, стратегії кешування, preloading та інтеграція з CDN.
Коротко
  • Замініть публічні шлюзи на виділений шлюз, щоб скоротити затримку IPFS з секунд до менш ніж 200 мс.
  • Публічні шлюзи виконують пошук у DHT для холодних CID, додаючи 2–15 секунд до отримання вмісту.
  • Закріплюйте файли під час запису, а не читання, щоб шлюз уже мав їх до першого запиту.
  • Поєднайте виділений шлюз з CDN-edge, щоб знизити глобальну затримку IPFS до 10–50 мс.

«IPFS повільний» — одна з найпоширеніших скарг розробників, і водночас одна з найлегших у вирішенні. Причина майже завжди криється в методі доступу, а не в самому протоколі. У цьому посібнику розглянуто чотири техніки, які усувають затримку IPFS у продакшн-середовищах.

IPFS Ninja

Оберіть метод доступу до IPFS за швидкістю#

Метод доступуТиповий TTFBКоли використовувати
Публічний gateway (ipfs.io, dweb.link)2–15 сЛише для розробки та тестування
Виділений gateway (pinned-контент)50–200 мсВесь продакшн-трафік
Виділений gateway + CDN edge10–50 мсГлобальна аудиторія
Ендпоінт оптимізації зображень<100 мс (warm)Весь графічний контент

Якщо ви використовуєте публічні gateway в продакшні — перейдіть на виділений gateway, і більша частина затримки зникне негайно.

Чому публічні gateway повільні#

Публічні gateway виконують DHT (Distributed Hash Table) lookup для кожного CID, який вони нещодавно не бачили. DHT lookup означає запит до десятків вузлів у мережі для пошуку того, хто зберігає контент — цей round-trip займає 2–15 секунд на холодному запиті.

Навіть при попаданні в кеш публічні gateway обслуговують мільйони користувачів. Ваш нещодавно запиначений файл має низький пріоритет кешування і може бути витіснений між запитами.

Рішення 1: Виділений gateway#

Виділений gateway приватний для вашого облікового запису. Файли, які ви pinуєте, кешуються на цьому gateway миттєво — жодного DHT lookup на жодному запиті, холодному чи теплому.

# До: публічний gateway, повільний і ненадійний
curl https://ipfs.io/ipfs/bafybeigdyrzt5sfp7udm7hu76uh7y26nf3efuylqabf3oclgtqy55fbzdi

# Після: виділений gateway, швидкий і передбачуваний
curl https://my-app.gw.ipfs.ninja/ipfs/bafybeigdyrzt5sfp7udm7hu76uh7y26nf3efuylqabf3oclgtqy55fbzdi

Створіть gateway у своєму дашборді IPFS.NINJA і задайте slug відповідно до вашого проекту. Slug gateway підтримує режим обмеженого доступу (потрібен токен) або відкритий режим для публічних статичних ресурсів.

Рішення 2: Pinуйте при записі, а не при читанні#

Pinуйте файли в момент їх створення, щоб gateway мав їх до того, як користувачі їх запросять. Найшвидший запит — той, який ніколи не призводить до cache miss.

# Завантажити і запінити за один крок
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"
  }'

# Відповідь — збережіть CID, відразу використовуйте url
# {
#   "cid": "bafy...",
#   "sizeMB": 0.24,
#   "uris": {
#     "ipfs": "ipfs://bafy...",
#     "url": "https://ipfs.ninja/ipfs/bafy..."
#   }
# }

Якщо у вас є наявні CID від іншого вузла або сервісу pinning, запінте їх без повторного завантаження:

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

Дивіться як завантажувати файли до IPFS для повного довідника по API завантаження.

Рішення 3: CDN перед вашим gateway#

Виділені gateway обслуговують з фіксованого регіону. Якщо ваші користувачі розкидані по континентах, додайте CDN edge-шар для обслуговування з найближчої точки присутності.

Оскільки IPFS використовує адресацію за вмістом — заданий CID завжди резолвиться до однакових байтів — можна кешувати вічно:

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

Приклад з Cloudflare (безкоштовний тариф покриває більшість навантажень статичних ресурсів):

  1. Додайте субдомен вашого gateway (my-app.gw.ipfs.ninja) як проксований CNAME Cloudflare.
  2. Створіть Page Rule: my-app.gw.ipfs.ninja/ipfs/*Cache Everything, Edge Cache TTL: a month.
  3. Перший запит потрапляє на gateway і кешується на найближчому edge PoP. Усі наступні запити обслуговуються Cloudflare.

Результат: глобальний TTFB знижується з 50–200 мс до 10–50 мс.

Рішення 4: API оптимізації зображень#

Сирі IPFS-зображення у повній роздільній здатності уповільнюють сторінки та погіршують Core Web Vitals. Використовуйте ендпоінт оптимізації зображень для зміни розміру на edge та подачі у сучасних форматах:

# Оригінал (повна роздільна здатність через gateway)
https://my-app.gw.ipfs.ninja/ipfs/bafy...

# Ширина 800 пікселів, конвертовано у WebP
https://api.ipfs.ninja/image/bafy...?w=800&format=webp

# Квадратна мініатюра
https://api.ipfs.ninja/image/bafy...?w=200&h=200&fit=cover

У React:

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

Ендпоінт оптимізації кешує кожну комбінацію (cid, width, format) — наступні запити з тими самими параметрами повністю оминають origin.

Чеклист#

  • Перейти з публічних gateway на виділений gateway
  • Pinувати контент при записі (під час завантаження), а не при читанні
  • Встановити Cache-Control: immutable на відповіді gateway
  • Додати CDN перед gateway для глобального трафіку
  • Подавати зображення через ендпоінт оптимізації замість сирих URL gateway

Для загального розуміння того, чому pinning важливий для доступності — не лише для швидкості — дивіться що таке IPFS pinning.


Готові почати pinувати? Створіть безкоштовний акаунт — 50 файлів, 1 ГБ сховища, 2 ГБ пропускної здатності/міс. Кредитна картка не потрібна.

Про цю статтю: ця стаття була складена AI-асистентом за допомогою робочого процесу генерації контенту IPFS.NINJA, а потім перевірена та схвалена Nacho Coll. Усі приклади коду перевірені на живому API IPFS.NINJA. Якщо ви помітили неточність, будь ласка, відкрийте issue на https://github.com/ipfs-ninja/feedback. Дізнайтеся більше про те, як ми використовуємо AI у нашому контенті та познайомтеся з людьми, які стоять за IPFS.NINJA.

Nacho Coll

Про автора

Founder & Engineer at IPFS.NINJA

Nacho founded IPFS.NINJA to make content-addressed storage feel as simple as an S3 PUT — a single API call, a permanent CID, no wallets or peer discovery to reason about. Writes about IPFS internals, decentralized storage patterns, and the pinning-service landscape from the operator side of the wire.

Назад до Блогу

Схожі статті