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

“O IPFS é lento” é uma das queixas mais comuns entre programadores — e também uma das mais fáceis de resolver. 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.

Escolha o seu Método de Acesso IPFS por Velocidade#

Se estiver a utilizar gateways públicos em produção, mude para um gateway dedicado e a maioria da latência desaparece imediatamente.

Por Que os Gateways Públicos São Lentos#

Os gateways públicos realizam uma pesquisa DHT (Distributed Hash Table) em cada CID que não viram recentemente. A pesquisa DHT implica consultar dezenas de pares na rede para encontrar quem detém o conteúdo — essa ida e volta demora entre 2 e 15 segundos num pedido frio.

Mesmo com um acerto de cache, os gateways públicos servem milhões de utilizadores. O seu ficheiro recentemente fixado tem baixa prioridade de cache e pode ser removido entre pedidos.

Solução 1: Gateway Dedicado#

Um gateway dedicado é privado para a sua conta. Os ficheiros que fixa ficam imediatamente em cache nesse gateway — sem pesquisa DHT em qualquer pedido, frio 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. Os slugs de gateway suportam modo de acesso restrito (token necessário) ou modo aberto para recursos estáticos públicos.

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

Fixe os ficheiros no momento em que são criados para que o gateway os tenha antes de qualquer pedido de utilizador. O pedido mais rápido é aquele que nunca provoca uma falha de cache.

# Carregar e fixar num único passo
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 — guarde o CID, sirva o url imediatamente
# {
#   "cid": "bafy...",
#   "sizeMB": 0.24,
#   "uris": {
#     "ipfs": "ipfs://bafy...",
#     "url": "https://ipfs.ninja/ipfs/bafy..."
#   }
# }

Se tiver CIDs existentes de outro nó ou serviço de pinning, volte a fixar sem re-carregar:

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

Consulte como carregar ficheiros para o IPFS para a referência completa da API de carregamento.

Solução 3: CDN à Frente do Gateway#

Os gateways dedicados servem a partir de uma região fixa. Se os seus utilizadores abrangem 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 resolve sempre para bytes idênticos — pode fazer cache indefinidamente:

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

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

1. Adicione o subdomínio do seu gateway (my-app.gw.ipfs.ninja) como CNAME proxiado pelo Cloudflare.
2. Crie uma Regra de Página: my-app.gw.ipfs.ninja/ipfs/* → Armazenar Tudo em Cache, TTL de Cache Edge: um mês.
3. O primeiro pedido chega ao gateway e fica em cache no PoP de edge mais próximo. Todos os pedidos subsequentes são servidos 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 tornam as páginas lentas e prejudicam os Core Web Vitals. Use o endpoint de otimização de imagens para redimensionar no edge e servir formatos modernos:

# Original (resolução completa 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 faz cache de cada combinação (cid, largura, formato) — pedidos subsequentes com os mesmos parâmetros ignoram completamente a origem.

Lista de Verificação#

• Mudar dos gateways públicos para um gateway dedicado
• Fixar conteúdo no momento da escrita (no carregamento), não no momento da leitura
• Definir Cache-Control: immutable nas respostas do gateway
• Adicionar CDN à frente do gateway para tráfego global
• Servir imagens via endpoint de otimização em vez de URLs brutas do gateway

Para informações sobre por que o pinning é importante para a disponibilidade — não apenas para a velocidade — consulte o que é o pinning IPFS.

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

Sobre este artigo: Este artigo foi redigido por um assistente de IA utilizando o fluxo de geração de conteúdo da IPFS.NINJA, depois revisto e aprovado por Nacho Coll. Todos os exemplos de código foram verificados contra a API IPFS.NINJA em produção. Se detetar uma imprecisão, abra um problema em https://github.com/ipfs-ninja/feedback. Leia mais sobre como utilizamos IA no nosso conteúdo e conheça as pessoas por trás do IPFS.NINJA.