Rendimiento IPFS: Acelera la Recuperación con Gateways

“IPFS es lento” es una de las quejas más comunes entre desarrolladores — y también una de las más solucionables. El culpable casi siempre es el método de acceso, no el protocolo en sí. Esta guía cubre cuatro técnicas que eliminan la latencia de IPFS en producción.

Elige tu método de acceso a IPFS por velocidad#

Si estás usando gateways públicos en producción, cambia a un gateway dedicado y la mayor parte de tu latencia desaparecerá de inmediato.

Por qué los gateways públicos son lentos#

Los gateways públicos realizan una búsqueda DHT (Distributed Hash Table) para cada CID que no han visto recientemente. La búsqueda DHT implica consultar docenas de peers a lo largo de la red para encontrar quién tiene el contenido — ese viaje de ida y vuelta tarda de 2 a 15 segundos en una solicitud en frío.

Incluso con un acierto de caché, los gateways públicos atienden a millones de usuarios. Tu archivo recién anclado tiene baja prioridad en caché y puede ser desalojado entre solicitudes.

Solución 1: Gateway dedicado#

Un gateway dedicado es privado para tu cuenta. Los archivos que anclas se almacenan en caché en ese gateway de inmediato — sin búsqueda DHT en ninguna solicitud, en frío o en caliente.

# Antes: gateway público, lento e impredecible
curl https://ipfs.io/ipfs/bafybeigdyrzt5sfp7udm7hu76uh7y26nf3efuylqabf3oclgtqy55fbzdi

# Después: gateway dedicado, rápido y determinista
curl https://my-app.gw.ipfs.ninja/ipfs/bafybeigdyrzt5sfp7udm7hu76uh7y26nf3efuylqabf3oclgtqy55fbzdi

Crea un gateway en tu panel de IPFS.NINJA y establece el slug para que coincida con tu proyecto. Los slugs de gateway admiten modo de acceso restringido (se requiere token) o modo abierto para recursos estáticos públicos.

Solución 2: Ancla al escribir, no al leer#

Ancla los archivos en el momento en que se crean para que el gateway los tenga antes de que cualquier usuario los solicite. La solicitud más rápida es aquella que nunca provoca un fallo de caché.

# Sube y ancla en un solo paso
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"
  }'

# Respuesta — guarda el CID, sirve la URL de inmediato
# {
#   "cid": "bafy...",
#   "sizeMB": 0.24,
#   "uris": {
#     "ipfs": "ipfs://bafy...",
#     "url": "https://ipfs.ninja/ipfs/bafy..."
#   }
# }

Si tienes CIDs existentes de otro nodo o servicio de anclado, vuelve a anclar sin volver a subir:

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

Consulta cómo subir archivos a IPFS para la referencia completa de la API de subida.

Solución 3: CDN delante de tu gateway#

Los gateways dedicados sirven desde una región fija. Si tus usuarios abarcan continentes, añade una capa de CDN edge para servir desde el punto de presencia más cercano.

Como IPFS es direccionado por contenido — un CID dado siempre se resuelve en bytes idénticos — puedes almacenar en caché para siempre:

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

Ejemplo con Cloudflare (el nivel gratuito cubre la mayoría de cargas de trabajo con recursos estáticos):

1. Agrega el subdominio de tu gateway (my-app.gw.ipfs.ninja) como un CNAME proxiado de Cloudflare.
2. Crea una regla de página: my-app.gw.ipfs.ninja/ipfs/* → Cache Everything, Edge Cache TTL: un mes.
3. La primera solicitud llega al gateway y se almacena en caché en el PoP edge más cercano. Todas las solicitudes posteriores se sirven desde Cloudflare.

Resultado: el TTFB global baja de 50–200 ms a 10–50 ms.

Solución 4: API de optimización de imágenes#

Las imágenes IPFS sin procesar servidas en resolución completa ralentizan las páginas y perjudican los Core Web Vitals. Usa el endpoint de optimización de imágenes para redimensionar en el edge y servir formatos modernos:

# Original (resolución completa vía gateway)
https://my-app.gw.ipfs.ninja/ipfs/bafy...

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

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

En React:

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

El endpoint de optimización almacena en caché cada combinación de (cid, width, format) — las solicitudes posteriores con los mismos parámetros omiten el origen por completo.

Lista de verificación#

• Cambia de gateways públicos a un gateway dedicado
• Ancla el contenido al escribir (al subir), no al leer
• Establece Cache-Control: immutable en las respuestas del gateway
• Agrega CDN delante del gateway para el tráfico global
• Sirve imágenes a través del endpoint de optimización en lugar de URLs de gateway sin procesar

Para información sobre por qué el anclado importa para la disponibilidad — no solo para la velocidad — consulta qué es el anclado IPFS.

¿Listo para empezar a anclar? Crea una cuenta gratuita — 50 archivos, 1 GB de almacenamiento, 2 GB de ancho de banda/mes. No se requiere tarjeta de crédito.

Acerca de este artículo: Este artículo fue redactado por un asistente de IA utilizando el flujo de generación de contenido de IPFS.NINJA, y luego revisado y aprobado por Nacho Coll. Todos los ejemplos de código fueron verificados contra la API en vivo de IPFS.NINJA. Si detectas una inexactitud, abre un issue en https://github.com/ipfs-ninja/feedback. Lee más sobre cómo usamos la IA en nuestro contenido y conoce a las personas detrás de IPFS.NINJA.