Rendimiento IPFS: Acelera la Recuperación con Gateways

“IPFS es lento” es una de las quejas más habituales 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áis usando gateways públicos en producción, cambiad a un gateway dedicado y la mayor parte de la 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 decenas 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. El archivo que habéis anclado recientemente tiene baja prioridad en caché y puede ser desalojado entre solicitudes.

Solución 1: Gateway dedicado#

Un gateway dedicado es privado para vuestra cuenta. Los archivos que ancláis 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

Cread un gateway en vuestro panel de IPFS.NINJA y estableced el slug para que coincida con vuestro 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#

Anclad 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 — guardad el CID, servid la URL de inmediato
# {
#   "cid": "bafy...",
#   "sizeMB": 0.24,
#   "uris": {
#     "ipfs": "ipfs://bafy...",
#     "url": "https://ipfs.ninja/ipfs/bafy..."
#   }
# }

Si tenéis CIDs existentes de otro nodo o servicio de anclado, volved 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"}'

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

Solución 3: CDN delante de vuestro gateway#

Los gateways dedicados sirven desde una región fija. Si vuestros usuarios abarcan continentes, añadid 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 — podéis 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. Añadid el subdominio de vuestro gateway (my-app.gw.ipfs.ninja) como un CNAME proxiado de Cloudflare.
2. Cread 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. Usad 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#

• Cambiad de gateways públicos a un gateway dedicado
• Anclad el contenido al escribir (al subir), no al leer
• Estableced Cache-Control: immutable en las respuestas del gateway
• Añadid CDN delante del gateway para el tráfico global
• Servid 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 — consultad qué es el anclado IPFS.

¿Listos para empezar a anclar? Cread 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 detectáis una inexactitud, abrid un issue en https://github.com/ipfs-ninja/feedback. Leed más sobre cómo utilizamos la IA en nuestro contenido y conoced a las personas detrás de IPFS.NINJA.