Gateways

HTTP Gateway Time To First Byte

This graphs shows daily aggregates of the Time to First Byte (TTFB) latency for all probed HTTP gateways. We collect the data with our Tiros measurement suite. The tooltip shows the number of samples that went into the calculation of each data point.

Tiros makes requests for the /ipfs/{cid} path endpoint as opposed to the corresponding subdomain (https://{cid}.{gateway_domain}). This means that the retrieval performance for some gateways includes round-trips to resolve redirects. Subdomain gateways are generally more secure because of improved origin isolation at the expense of additional round-trips to resolve to the subdomain.

The data is segmented along the dimensions: region, cache status, and CID source.

Region

We have deployed our Tiros measurement suite in different AWS regions around the world. They correspond to the following region identifiers:

• eu-central-1: Europe (Frankfurt)
• us-east-2: US East (Ohio)
• us-west-1: US West (N. California)
• ap-southeast-2: Asia Pacific (Sydney)

Cache Status

Each time Tiros probes an HTTP gateway, it sends two requests for the same CID one after another. With the first request we attempt to trigger an uncached response and with the second request we attempt to trigger a cached response. We determine whether a request was cached or not by parsing the response headers and evaluating the headers: cf-cache-status, x-filebase-edge-cache, and x-cache.

CID Source

We have two types of sources for CIDs that we request from the gateways: controlled and organic. The controlled CIDs correspond to random 1kB data blobs that we host on a controlled Kubo node in us-east-1. The idea is to use these blobs to measure a baseline performance of the gateways under controlled conditions.

The organic CIDs come from our Bitswap Sniffer tool that has picked them up by observing bitswap traffic. Measuring the retrieval performance for these CIDs can be used as a proxy to what users on average would perceive when interacting with IPFS gateways. It is useful to track long term trends.

Service Worker Gateway Time To First Byte

This graph shows daily aggregates of the Time to First Byte (TTFB) latency of the inbrowser.link Service Worker Gateway. We collect the data with our Tiros measurement suite. The tooltip shows the number of samples that went into the calculation of each data point as well as the fainted bars in the background.

Tiros makes requests for the https://inbrowser.link/ipfs/{cid} path endpoint in a headless Chromium instance and then measures the time until the first byte of the actual content was seen by the browser. This means that the TTFB performance includes the download and initialization of the service worker code and various redirects to configure the browser. The performance will likely be worse than the plain HTTP Gateways but you need to consider three things:

1. The service worker gateway verifies the downloaded bytes
2. The service worker gateway ensures proper subdomain origin isolation
3. Subsequent requests won't need to download the service worker code again and thus resolve much faster

In short, service worker gateways are generally more secure and once initialized subsequent retrievals don't exhibit the startup performance penalty.

The data is segmented along the dimensions: region, cache status, and CID source.

Region

We have deployed our Tiros measurement suite in different AWS regions around the world. They correspond to the following region identifiers:

• eu-central-1: Europe (Frankfurt)
• us-east-2: US East (Ohio)
• us-west-1: US West (N. California)
• ap-southeast-2: Asia Pacific (Sydney)

Cache Status

When the content for a CID is requested via a service worker gateway, it races two resolution paths:

1. a regular request to a trustless HTTP gateway (trustless-gateway.link in the case of inbrowser.link)
2. a delegated routing request plus direct retrieval from the actual peer

If the request was served internally served via a trustless gateway, we determine whether a request was cached or not by parsing the response headers and evaluating the headers: cf-cache-status, x-filebase-edge-cache, and x-cache.

The result can be a cache hit or miss. Thirdly, if the request was served directly by a peer, we mark that data as "direct".

CID Source

We have two types of sources for CIDs that we request from the gateways: controlled and organic. The controlled CIDs correspond to random 1kB data blobs that we host on a controlled Kubo node in us-east-1. The idea is to use these blobs to measure a baseline performance of the gateways under controlled conditions.

The organic CIDs come from our Bitswap Sniffer tool that has picked them up by observing bitswap traffic. Measuring the retrieval performance for these CIDs can be used as a proxy to what users on average would perceive when interacting with IPFS gateways. It is useful to track long term trends.

Service Worker Gateway Component Time Breakdown

This chart breaks down the time the inbrowser.link Service Worker Gateway spends in its internal subcomponents while resolving and retrieving content. The data is collected by our Tiros measurement suite, which records the Server-Timing metrics emitted by verified-fetch.

The stacked bars show the mean duration of each component per day. Means are used (instead of medians) because component means are mathematically additive (E[a + b] = E[a] + E[b]) which makes the stack visually meaningful. Note that the components are not strictly sequential: find providers and the connect/block phases of multiple block brokers (Bitswap and trustless gateway) run partly in parallel. The chart therefore reports per-component time spent rather than the strict end-to-end response time. The overlaid line shows the median of the actual per-request total time-to-first-byte (TTFB) for reference.

Components

• Path Resolve: time to parse and resolve the requested path to a CID (IPFS, DNSLink, IPNS).
• Find Providers: time spent in the routing query that discovers providers. The probe issues two routing queries in parallel (libp2p delegated routing and the HTTP-Gateway router that returns preconfigured trustless gateways). We use the fastest of the two as the per-request value.
• Connect (fastest): time of the fastest successful connection. For HTTP/trustless-gateway providers this measures window.fetch invocation up to the point response headers arrive. For libp2p/bitswap providers it measures actual transport-layer connection establishment.
• Block (fastest): time of the fastest block transfer. For HTTP this is the time to read the response body for a block. For Bitswap this is from sending the wantlist until the block is received.

Outlier handling

The "Fastest 90%" mode excludes each component's slowest 10% of samples per day before averaging. Cutoffs are computed per component, per day, so a probe excluded from the block mean may still contribute to the connect mean. This trims tail-latency outliers without dropping whole probes.

Filters

Only successful probes (HTTP 200, no error) are included. The data is segmented by region and CID source.

Region

We have deployed our Tiros measurement suite in different AWS regions:

• eu-central-1: Europe (Frankfurt)
• us-east-2: US East (Ohio)
• us-west-1: US West (N. California)
• ap-southeast-2: Asia Pacific (Sydney)

CID Source

• Controlled: random 1kB blobs hosted on a controlled Kubo node — baseline performance.
• Organic: CIDs picked up by our Bitswap Sniffer — closer to what users typically experience.