Desempenho IPFS: Acelere a Recuperação com Gateway Dedicado

“IPFS é lento” é uma das reclamações mais comuns entre desenvolvedores — e também uma das mais solucionáveis. O culpado é quase sempre o método de acesso, não o protocolo em si. Este guia aborda quatro técnicas que eliminam a latência do IPFS em produção.

Referência Rápida: Métodos de Acesso IPFS por Velocidade#

Se você está usando gateways públicos em produção, migre para um gateway dedicado e a maior parte da latência desaparece imediatamente.

Por Que Gateways Públicos São Lentos#

Gateways públicos realizam uma busca DHT (Distributed Hash Table) para cada CID que não viram recentemente. A busca DHT significa consultar dezenas de peers pela rede para encontrar quem possui o conteúdo — essa viagem de ida e volta leva de 2 a 15 segundos em uma requisição fria.

Mesmo em um cache hit, gateways públicos atendem milhões de usuários. Seu arquivo recém-fixado tem baixa prioridade no cache e pode ser removido entre requisições.

Solução 1: Gateway Dedicado#

Um gateway dedicado é privado para sua conta. Arquivos que você fixa são cacheados nesse gateway imediatamente — sem busca DHT em nenhuma requisição, fria ou quente.

# Antes: gateway público, lento e não confiável
curl https://ipfs.io/ipfs/bafybeigdyrzt5sfp7udm7hu76uh7y26nf3efuylqabf3oclgtqy55fbzdi

# Depois: gateway dedicado, rápido e determinístico
curl https://my-app.gw.ipfs.ninja/ipfs/bafybeigdyrzt5sfp7udm7hu76uh7y26nf3efuylqabf3oclgtqy55fbzdi

Crie um gateway no seu painel IPFS.NINJA e defina o slug para corresponder ao seu projeto. Slugs de gateway suportam modo de acesso restrito (token necessário) ou modo aberto para assets estáticos públicos.

Solução 2: Fixe no Momento da Escrita, Não da Leitura#

Fixe arquivos no momento em que são criados para que o gateway os tenha antes de qualquer requisição do usuário. A requisição mais rápida é aquela que nunca causa um cache miss.

# Faça upload e fixe em uma única etapa
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"
  }'

# Resposta — armazene o CID, sirva a url imediatamente
# {
#   "cid": "bafy...",
#   "sizeMB": 0.24,
#   "uris": {
#     "ipfs": "ipfs://bafy...",
#     "url": "https://ipfs.ninja/ipfs/bafy..."
#   }
# }

Se você tiver CIDs existentes de outro nó ou serviço de pinning, re-fixe sem fazer novo upload:

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

Veja como fazer upload de arquivos para o IPFS para a referência completa da API de upload.

Solução 3: CDN na Frente do seu Gateway#

Gateways dedicados servem a partir de uma região fixa. Se seus usuários estão espalhados por continentes, adicione uma camada de edge CDN para servir a partir do ponto de presença mais próximo.

Como o IPFS é endereçado por conteúdo — um determinado CID sempre resolve para bytes idênticos — você pode fazer cache para sempre:

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

Exemplo com Cloudflare (o plano gratuito cobre a maioria das cargas de trabalho de assets estáticos):

1. Adicione o subdomínio do seu gateway (my-app.gw.ipfs.ninja) como um CNAME proxied pelo Cloudflare.
2. Crie uma Page Rule: my-app.gw.ipfs.ninja/ipfs/* → Cache Everything, Edge Cache TTL: um mês.
3. A primeira requisição atinge o gateway e é cacheada no PoP de edge mais próximo. Todas as requisições subsequentes são servidas pelo Cloudflare.

Resultado: o TTFB global cai de 50–200 ms para 10–50 ms.

Solução 4: API de Otimização de Imagens#

Imagens IPFS brutas servidas em resolução total deixam as páginas lentas e prejudicam o Core Web Vitals. Use o endpoint de otimização de imagens para redimensionar na edge e servir formatos modernos:

# Original (resolução total via gateway)
https://my-app.gw.ipfs.ninja/ipfs/bafy...

# Redimensionado para 800 px de largura, convertido para WebP
https://api.ipfs.ninja/image/bafy...?w=800&format=webp

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

Em React:

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

O endpoint de otimização cacheia cada combinação de (cid, width, format) — requisições subsequentes com os mesmos parâmetros ignoram completamente a origem.

Lista de Verificação#

• Migre de gateways públicos para um gateway dedicado
• Fixe o conteúdo no momento da escrita (no upload), não no da leitura
• Defina Cache-Control: immutable nas respostas do gateway
• Adicione CDN na frente do gateway para tráfego global
• Sirva imagens pelo endpoint de otimização em vez de URLs brutas do gateway

Para entender por que o pinning é importante para disponibilidade — não apenas velocidade — veja o que é IPFS pinning.

Pronto para começar a fixar? Crie uma conta gratuita — 50 arquivos, 1 GB de armazenamento, 2 GB de largura de banda/mês. Sem necessidade de cartão de crédito.

Sobre este artigo: Este artigo foi redigido por um assistente de IA usando o fluxo de geração de conteúdo do IPFS.NINJA, depois revisado e aprovado por Nacho Coll. Todos os exemplos de código foram verificados na API ativa do IPFS.NINJA. Se você encontrar uma imprecisão, abra uma issue em https://github.com/ipfs-ninja/feedback. Leia mais sobre como usamos IA em nosso conteúdo e conheça as pessoas por trás do IPFS.NINJA.