Saltar al contenido

Compara el rendimiento de RPC en las principales chains

Observa cómo se comparan los proveedores en latencia, tasa de éxito y solicitudes fallidas, todo probado bajo condiciones idénticas.

Tiempo de respuesta promedio global (EVM)

En vivo

Última actualización: Sep 4, 2026, 23:28 UTC

Alchemy0.00 ms
QuickNode0.00 ms
Infura0.00 ms
dRPC0.00 ms

En la comparativa global actual de 24 horas en chains EVM, Alchemy tiene el menor tiempo de respuesta promedio con 16.02 ms.

Chains
Regiones

Average Latency

0.00ms

Alchemy

P50 Latency

0.00ms

Alchemy

P95 Latency

0.00ms

Alchemy

Success Rate

0.00%

Alchemy

Comparación de proveedores para todas las chains comparadas en todas las regiones

En esta vista de 24 horas, Alchemy tiene la menor latencia promedio con 16.02 ms. La tabla también muestra P50, P95 y tasa de éxito para cada proveedor.

Tabla comparativa de proveedores RPC con latencia promedio, latencia P50, latencia P95 y tasa de éxito para la chain y región seleccionadas.
ProveedorLatencia promedioLatencia P50Latencia P95Tasa de éxito
AlchemyMás rápido
16.02 ms
6.47 ms
43.82 ms
99.87%
QuickNode
56.10 ms
9.78 ms
232.25 ms
100%
Infura
112.07 ms
104.25 ms
277.96 ms
99.88%
dRPC
114.58 ms
24.40 ms
555.12 ms
99.96%

Latencia promedio por método: todas las chains comparadas, todas las regiones

Elige un método para ver qué tan rápido maneja cada proveedor ese tipo de solicitud.

9.48 ms
15.43 ms
20.45 ms
113.66 ms
  • Alchemy
  • QuickNode
  • dRPC
  • Infura

Solicitudes fallidas por método: todas las chains comparadas, todas las regiones

Elige un método para ver dónde se agrupan los errores y tiempos de espera por proveedor.

2
78
110
777
  • QuickNode
  • Alchemy
  • dRPC
  • Infura

Metodología

Pruebas RPC controladas, reglas transparentes

Estas son comparativas de lectura EVM a nivel de método. Enviamos las mismas cargas útiles configuradas desde las mismas regiones, separamos velocidad de confiabilidad y publicamos las reglas para que los números sean más fáciles de interpretar.

Lee la metodología completa
Payload icon

Mismas cargas útiles

Para cada método, todos los proveedores reciben la misma carga útil JSON-RPC configurada, la misma chain, región, tiempo de espera y criterio de éxito.

Regions icon

Regiones de ejecución compartidas

Las pruebas se ejecutan desde US East, US West, EU Central y AP Southeast, con cada proveedor probado desde la misma ubicación de ejecución.

Accounts icon

Cuentas pagas estándar

Cada proveedor se prueba en una cuenta de servicio RPC paga estándar, sin rutas especiales, planes, reintentos ni trato preferencial.

Latency icon

Latencia de respuestas exitosas

La latencia usa conexiones HTTP reutilizadas y ya activas, e incluye solo respuestas exitosas. Los fallos se registran por separado.

Failure rules icon

Reglas de fallo claras

Errores HTTP, errores JSON-RPC, fallos de parseo, errores de red, límites de tasa y tiempos de espera de 8 segundos cuentan como fallos.

Scope icon

Alcance a nivel de método

La comparativa mide solicitudes de lectura individuales, no flujos completos de aplicaciones, escrituras, WebSockets, arranques en frío ni combinaciones de tráfico personalizadas.

Comparativas para agentes

Abre cada vista de comparativa como tablas de texto con definiciones de campos y metadatos de origen, diseñadas para agentes, crawlers y desarrolladores que quieren los datos sin la interfaz.

Abrir datos en Markdown

Preguntas frecuentes

Preguntas frecuentes sobre las comparativas

Cómo funcionan las comparativas RPC en vivo, qué miden y dónde encontrar los datos sin procesar.

  • Rastrean la latencia de respuestas exitosas (promedio, P50 y P95), la tasa de éxito y el conteo de solicitudes fallidas para Alchemy, QuickNode, dRPC e Infura en métodos de lectura JSON-RPC EVM comunes.
  • Las solicitudes de la comparativa se ejecutan cada 10 segundos, todo el día. La página pública y la ruta de datos en Markdown se actualizan cada 5 minutos con la ventana de 24 horas más reciente.
  • La comparativa se ejecuta desde US East, US West, EU Central y AP Southeast. La vista Global agrega los resultados de esas cuatro regiones.
  • Comparan cuentas de servicio RPC pagas estándar. Cada proveedor recibe el mismo método, carga útil, chain, región, tiempo de espera y criterio de éxito configurados, sin trato especial.
  • Una solicitud falla si devuelve un estado HTTP que no es 2xx, devuelve un objeto de error JSON-RPC, agota el tiempo de espera después de 8 segundos, falla a nivel de red o no se puede parsear como JSON válido. Las respuestas de límite de tasa cuentan como fallos.
  • La latencia es el tiempo de solicitud y respuesta medido por el ejecutor para un POST HTTP JSON-RPC exitoso sobre una conexión reutilizada y ya activa. Los intentos fallidos y los tiempos de espera se excluyen de la latencia y se cuentan en la tasa de éxito.
  • No. Cada solicitud intentada tiene una sola oportunidad. Si falla, el fallo se cuenta en lugar de reintentarse, para que la tasa de éxito refleje los fallos que una aplicación tendría que manejar.
  • Las comparativas en vivo cubren Ethereum, Optimism, Arbitrum, Base y World Chain, además de una vista General que agrega las chains actualmente comparadas.

  • La comparativa cubre pruebas de lectura EVM configuradas para:

    • eth_getBalance: consulta de saldo de cuenta
    • eth_getBlockByNumber: bloque más antiguo, lectura de encabezado al inicio de la chain
    • eth_getBlockByNumber: bloque más reciente, lectura de encabezado en la cabeza de la chain
    • eth_getLogs: rango de 1 bloque
    • eth_getLogs: rango de 10 bloques
    • eth_getLogs: rango de 100 bloques
    • eth_getLogs: rango de 1,000 bloques en Ethereum
    • eth_getTransactionReceipt: consulta de recibo de una sola transacción
  • Sí. La página complementaria en Markdown publica los resultados como tablas de texto con definiciones de campos, metadatos de origen y el conjunto de datos completo por chain y región.
  • P95 muestra el extremo lento de las respuestas exitosas: el 95% de las solicitudes exitosas para ese método, chain, región y ventana de tiempo se completaron en esa latencia o por debajo de ella. Interprétalo junto con la tasa de éxito, porque las respuestas rápidas solo importan cuando las respuestas llegan.
  • Miden el rendimiento de lectura EVM de un solo método, en caliente, bajo condiciones controladas. No miden flujos completos de aplicaciones, transacciones de escritura, WebSockets, combinaciones de tráfico específicas de clientes, configuración de conexión en frío, ni todas las chains, proveedores, regiones, métodos y cargas útiles posibles.

La latencia es un costo para tus usuarios

Cada llamada RPC lenta se convierte en fricción visible para el usuario: lecturas retrasadas, pantallas congeladas y confirmaciones que parecen no funcionar. Construye sobre infraestructura que mantiene tu aplicación en movimiento.

Empieza a construirContáctanos