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

«IPFS работает медленно» — одна из самых распространённых жалоб разработчиков и при этом одна из наиболее легко устранимых. Виновником почти всегда является метод доступа, а не сам протокол. В этом руководстве рассматриваются четыре метода, позволяющие устранить задержки IPFS в продакшене.

Краткая справка: методы доступа IPFS по скорости#

Если вы используете публичные шлюзы в продакшене, переключитесь на выделенный шлюз — и большая часть задержки исчезнет сразу.

Почему публичные шлюзы работают медленно#

Публичные шлюзы выполняют поиск по DHT (Distributed Hash Table) для каждого CID, который они не видели в последнее время. Поиск по DHT означает запрос к десяткам узлов сети с целью выяснить, у кого хранится контент, — этот обмен занимает от 2 до 15 секунд при холодном запросе.

Даже при попадании в кэш публичные шлюзы обслуживают миллионы пользователей. Ваш недавно закреплённый файл имеет низкий приоритет в кэше и может быть вытеснен между запросами.

Решение 1: Выделенный шлюз#

Выделенный шлюз является приватным для вашей учётной записи. Закреплённые вами файлы немедленно кэшируются на этом шлюзе — без поиска по DHT при любом запросе, холодном или тёплом.

# До: публичный шлюз, медленный и ненадёжный
curl https://ipfs.io/ipfs/bafybeigdyrzt5sfp7udm7hu76uh7y26nf3efuylqabf3oclgtqy55fbzdi

# После: выделенный шлюз, быстрый и детерминированный
curl https://my-app.gw.ipfs.ninja/ipfs/bafybeigdyrzt5sfp7udm7hu76uh7y26nf3efuylqabf3oclgtqy55fbzdi

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

Решение 2: Закрепляйте при записи, а не при чтении#

Закрепляйте файлы в момент их создания, чтобы шлюз получил их до любого запроса от пользователя. Самый быстрый запрос — тот, который никогда не вызывает промаха кэша.

# Загрузка и закрепление за один шаг
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"}'

Полный справочник по API загрузки см. в разделе как загружать файлы в IPFS.

Решение 3: CDN перед шлюзом#

Выделенные шлюзы обслуживают запросы из фиксированного региона. Если ваши пользователи расположены на разных континентах, добавьте слой CDN edge для обслуживания из ближайшей точки присутствия.

Поскольку IPFS использует адресацию по содержимому — заданный CID всегда указывает на идентичные байты — кэшировать можно бесконечно:

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

Пример с Cloudflare (бесплатный тарифный план покрывает большинство рабочих нагрузок со статическими ресурсами):

1. Добавьте субдомен вашего шлюза (my-app.gw.ipfs.ninja) как проксируемую CNAME-запись Cloudflare.
2. Создайте правило страницы: my-app.gw.ipfs.ninja/ipfs/* → Cache Everything, Edge Cache TTL: месяц.
3. Первый запрос поступает на шлюз и кэшируется на ближайшем edge PoP. Все последующие запросы обслуживаются из Cloudflare.

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

Решение 4: API оптимизации изображений#

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

# Оригинал (полное разрешение через шлюз)
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, ширина, формат) — последующие запросы с теми же параметрами полностью обходят источник.

Контрольный список#

• Переключиться с публичных шлюзов на выделенный шлюз
• Закреплять контент при записи (при загрузке), а не при чтении
• Установить Cache-Control: immutable на ответы шлюза
• Добавить CDN перед шлюзом для глобального трафика
• Отдавать изображения через эндпоинт оптимизации, а не через сырые URL шлюза

О том, почему pinning важен для доступности — не только для скорости, — читайте в статье что такое IPFS pinning.

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

Об этой статье: Статья написана AI-ассистентом с использованием рабочего процесса генерации контента IPFS.NINJA, затем проверена и одобрена Nacho Coll. Все примеры кода проверены на действующем API IPFS.NINJA. Если вы обнаружили неточность, откройте issue по адресу https://github.com/ipfs-ninja/feedback. Подробнее о том, как мы используем AI в нашем контенте, и познакомьтесь с командой IPFS.NINJA.