The Four Origins a Cold Load Reaches, and the Two the Document Never Names

I work on OnePassApps, the team behind app.onepassapps.com. This is our own site, and every number below was measured on it today, 11 November 2026 - plain HTTPS from outside the browser for the document layer, and one real cold browser load with the cache disabled for the runtime layer.

Two earlier posts on this account are the canonical write-ups for the parts they already own: the preloaded chunk set (Two of Our Three Preloaded Chunks Rotated), the per-route script inventory (What Each Route Asks the Browser to Fetch) and the link-tag census (The Link Tags of 56 Pages). A fourth covers what a visitor pays to open a URL that does not exist (The Cost of a Wrong URL). This post is about the layer none of them covers: which hosts a page actually reaches, and what the document says about them before any of it runs.

What I measured

• All 56 URLs in our own sitemap.xml, fetched over plain HTTPS - signed out, no cookies, no JavaScript
• The link tags in each served document, and the response headers on every answer
• One cold load of an app page, /apps/focus-timer, and one of a guide page, /guides/focus-timer, in desktop Chrome with the cache disabled, with every request captured

A cold app page reaches four origins

The app page made 125 requests, to four different origins.

The guide page is a completely different shape. It boots no app bundle, so it made 10 requests to two origins: nine of ours and the same single Cloudflare beacon.

So the bundle is what pulls in the other two origins. The sign-in host and the API host are both reached because our JavaScript asks for them after the document has parsed, not because the document asked for them.

The link tags: 491 of them, and not one hint

Counted across all 56 served documents, there are 491 link tags: 112 stylesheet, 112 icon, 99 modulepreload, 56 apple-touch-icon, 56 manifest and 56 canonical. That census is the subject of the earlier post, so I am not repeating the arithmetic.

What is new is what is missing from it. There is no preconnect tag on any of the 56 pages. No dns-prefetch tag. No prefetch tag. And not one plain preload relation either - all 99 are modulepreload, and the three files they point at are the same three on every page that carries them.

And no Link header either

The HTTP-level version of the same hint is absent as well. Not one of the 56 responses carries a Link header, so nothing about the two origins we depend on is pushed by the server on the first answer either. The connection to them is set up purely by code that runs later.

The served documents never name either origin

This is the part I did not expect. I looked for both hostnames inside all 56 served documents: 0 pages name api.onepassapps.com, and 0 name clerk.onepassapps.com. The Cloudflare beacon is the opposite - all 56 pages carry it.

So the markup names one origin in advance, and that one belongs to Cloudflare, not to us. The two origins our app genuinely needs are found by running our JavaScript.

What the API host is asked for

Five requests, three routes, and the first two are asked for twice.

• /api/runtime - twice, 471 bytes each
• /api/config/feature-flags - twice, 1,771 bytes each
• /api/auth/config - once

The sign-in host answers a redirect first

Of the 10 requests to the sign-in host, two are for unpinned major-version paths. Each one answers HTTP 307 with a Location header pointing at the pinned version - 6.42.3 for the browser bundle, 1.42.4 for the UI bundle - and it is the pinned file that is actually served.

That pinned browser bundle is 327,846 bytes and carries public, max-age=31536000, s-maxage=31536000, immutable, so once the version is pinned it is cached for a year at the edge. The redirect itself is the cheap part: a 307 with no body.

Limits

One build, one day, one browser, one signed-out session, one app route and one guide route measured in the browser. The 125 and the 10 are for those two pages, not for every page in the fleet. The document layer was measured over plain HTTPS with the redirect handler disabled, so the 308 answers are counted as answers and not followed. The host counts come from the request URLs as the browser reported them, and the byte counts from a separate fetch of the same paths from this server. I did not measure a second browser, a second network, or a warm cache.

The tools themselves

the Focus Timer app and the app guides.