The Same URL Never Returns the Same Bytes: 56 Pages of app.onepassapps.com and One Per-Request Key

I work on OnePassApps, so this is our own site and our own build, and every number below was measured on it today, signed out, over plain HTTPS.

Fetch one of our pages twice. The two copies are the same length. They are not the same bytes.

I fetched all 56 URLs in our sitemap twice, a moment apart. 56 of 56 came back with exactly the same byte length on the second fetch. 0 of 56 came back byte-identical. Between the two copies of each page, 5,040 bytes differ, spread over 325 separate runs. That count is itself a sample: an earlier double-fetch of the same 56 pages on the same build today gave 4,893 bytes in 424 runs, because the keys move on every response.

That reads like a page being rebuilt under you. It is not.

The only thing that changes is one encoded string

Every difference between the two copies sits inside a run of 32 or more hexadecimal characters. Replace each of those runs with a placeholder and the two copies become byte-identical again - 56 of 56. The context check agrees: 325 of the 325 differing runs sit inside or beside Cloudflare's email-protection markup, and 0 sit outside it.

Across the 56 pages there are 125 such runs of hex, and 74 of them sit in a data-cfemail attribute. That is Cloudflare's email protection: the contact address in our served HTML is not plain text, it is hex-encoded, and the key is chosen per response. Two fetches, two keys, two encodings of the same address, and decoding both lands on [email protected].

Nothing else moves. The Content-Security-Policy header was byte-for-byte identical on both fetches of every page. The copy, the structure and the markup are the same document.

Why this matters if you measure a site

The compressed size of a page is not a fixed number. Eight fetches of /terms returned 18,514 to 18,575 bytes of gzip - a spread of 61 bytes on a page whose uncompressed length never moved. The home page returned 6,632 to 6,635 bytes over the same eight fetches, and /voting 4,572 to 4,579.

So if you record a page size once and quote it later, you are quoting one sample from a range, not a property of the page. The uncompressed length is stable - 24,644 bytes on the home page every time - because the string it replaces is the same length every time. The compressed length is not, because the bytes it compresses are not.

Three fetches of the home page gave 3 different SHA-256 digests and one length.

What this is not

It is not a rebuild, not a rotating build id and not a cache problem. These pages send no ETag and no Vary - 0 of 56 carry an ETag, 0 of 56 carry a Vary header - so nothing is being revalidated, and the bytes still change. Cloudflare's per-response encoding key is the whole story, and the proof is that masking it makes the difference disappear completely.

Limits

One build, one day - 10 November 2026 - one network, signed out, one GET per fetch, no browser, no JavaScript, no cookies, plain HTTPS. These are the 56 URLs in our sitemap. I did not test from a second network, did not test a signed-in request, and I am not claiming what any browser cache does with this.

The 9 November post on the anchor layer of our own 56 pages - https://dev.to/onepassapps/the-anchor-layer-of-apponepassappscom-1058-links-162-link-texts-and-one-footer-on-all-56-pages-8i6 - is the canonical read on the rewrite itself. This one is about the part that repeats on every request.

You can see the site at https://app.onepassapps.com/?utm_source=dev.to&utm_medium=community&utm_campaign=per-request-variance&utm_content=home-link

And the guides are at https://app.onepassapps.com/guides?utm_source=dev.to&utm_medium=community&utm_campaign=per-request-variance&utm_content=guides-link