Service Worker Gateway Time To First Byte

Service Worker Gateway Time To First Byte

Shows the daily P50 (median) and P90 (90th percentile) Time to First Byte (TTFB) latency, in seconds, of the inbrowser.link Service Worker Gateway. We collect the data with our Tiros measurement suite. Only requests that return status code 200 count. The faint bars in the background show the number of samples per day (right axis), and the tooltip shows this number too.

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 a request to a trustless gateway succeeded, we determine whether it 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 is Cache Hit or Cache Miss. If no request to a trustless gateway succeeded, the content came directly from a peer, and we mark the probe as Direct.

For Direct, days without data show as zero. The gray area marks the inbrowser.link outage from 2026-07-10 to 2026-09-22.

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 are CIDs that peers recently announced in the Amino DHT (provider records). Our Bitswap Sniffer tool picks them up. 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.