Service Worker Gateway Component Time Breakdown

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 dashed Total TTFB (P50) line shows the median time to first byte (TTFB) of the final request, the one that the service worker answers, for reference. It does not include the redirects and the service worker start-up before that request. The thin line shows the number of samples per day (right axis).

The data starts on 2026-04-24, when Tiros started to record these metrics. The gray area marks the inbrowser.link outage from 2026-07-10 to 2026-09-22.

Components

  • Path Resolve: time to resolve the requested CID and path to the target CID.
  • Find Providers (fastest): time spent in the routing query that discovers providers. The service worker sends 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 Exclude outliers (Fastest 90%) mode (the default) 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. Select All samples to include every sample.

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 that peers recently announced in the Amino DHT, picked up by our Bitswap Sniffer — closer to what users typically experience.

Daily mean time spent per service worker subcomponent on the inbrowser.link Service Worker Gateway.