Продуктивність IPFS: прискорте отримання файлів
Практичні техніки для підвищення швидкості отримання файлів IPFS: виділені gateway, стратегії кешування, preloading та інтеграція з CDN.
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.

- Замініть публічні шлюзи на виділений шлюз, щоб скоротити затримку IPFS з секунд до менш ніж 200 мс.
- Публічні шлюзи виконують пошук у DHT для холодних CID, додаючи 2–15 секунд до отримання вмісту.
- Закріплюйте файли під час запису, а не читання, щоб шлюз уже мав їх до першого запиту.
- Поєднайте виділений шлюз з CDN-edge, щоб знизити глобальну затримку IPFS до 10–50 мс.
«IPFS повільний» — одна з найпоширеніших скарг розробників, і водночас одна з найлегших у вирішенні. Причина майже завжди криється в методі доступу, а не в самому протоколі. У цьому посібнику розглянуто чотири техніки, які усувають затримку IPFS у продакшн-середовищах.

Оберіть метод доступу до IPFS за швидкістю#
| Метод доступу | Типовий TTFB | Коли використовувати |
|---|---|---|
Публічний gateway (ipfs.io, dweb.link) | 2–15 с | Лише для розробки та тестування |
| Виділений gateway (pinned-контент) | 50–200 мс | Весь продакшн-трафік |
| Виділений gateway + CDN edge | 10–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 (безкоштовний тариф покриває більшість навантажень статичних ресурсів):
- Додайте субдомен вашого gateway (
my-app.gw.ipfs.ninja) як проксований CNAME Cloudflare. - Створіть Page Rule:
my-app.gw.ipfs.ninja/ipfs/*→ Cache Everything, Edge Cache TTL: a month. - Перший запит потрапляє на 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.
Про цю статтю
Ця стаття створена за допомогою ШІ, перевірена людиною та протестована на реальній платформі 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.
