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 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.

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