I work on OnePassApps, the team behind app.onepassapps.com, so this is our own site. Everything below was measured on 8 November 2026 with plain HTTPS from outside the browser - one GET per URL, no session, no cookies, no JavaScript - and every number is what the server sent in that window.

We have written about the head, the images, the scripts, the element ids and the raw bytes of our pages. This one is about the <link> elements themselves: the 491 of them, the two shapes they take, and the one line on them that surprised us.

491 link elements, and only two shapes

Our sitemap names 56 URLs, and all 56 answer 200. Across those 56 documents there are 491 <link> elements.

They are not scattered. The 56 pages fall into exactly two shapes, and every page inside a shape carries the same links in the same order.

  • 33 pages carry 10 links each, which is 330.
  • 23 pages carry 7 links each, which is 161.

The 23 are the guide fleet: the guides index plus the 22 guide pages. The 33 are the pages that boot the app bundle. The gap between the two shapes is exactly three tags - the three modulepreload links. Count the tags by relation and the arithmetic closes: 112 stylesheet, 112 icon, 99 modulepreload, 56 apple-touch-icon, 56 manifest, 56 canonical.

There is one canonical on every page, and it points at itself. All 56 canonical URLs are byte-identical to the URL they sit on - no trailing-slash variants, no query strings, no mismatches. The only slash in the set is the home page, which is https://app.onepassapps.com/ with the slash; the other 55 carry none.

One preload set, thirty-three times

All 99 modulepreload elements point at the same three files, in the same order, on every one of the 33 pages:

  1. /assets/rolldown-runtime-QTnfLwEv.js - 694 bytes
  2. /assets/app-shell-shared-DCrZF6q_.js - 369,609 bytes
  3. /assets/react-vendor-DY6N_LXH.js - 178,924 bytes

That is 549,227 bytes of JavaScript the browser is told to fetch before it has parsed the entry module. All three are served with Cache-Control: public, max-age=31536000, immutable, a strong ETag and Access-Control-Allow-Origin: *.

The stylesheet that arrives with no JavaScript to run it

All 56 pages link the app bundle's stylesheet: /assets/index-B_evf03w.css, 242,648 bytes, cached for a year and immutable.

On the 23 guide pages that stylesheet is the seventh and last link tag - and those pages ship no module script of ours at all. Their only script tags are the JSON-LD block and two Cloudflare ones. So the guide fleet fetches 5,580,904 bytes of app CSS across its 23 pages, for a bundle that never runs there.

The two stylesheets also arrive in a fixed order on every page: the 3,054-byte fallback sheet first, the 242,648-byte bundle sheet last, after the canonical and after the preloads. The app's main stylesheet is the final link tag in the head of all 56 documents.

The preload set matches the import graph exactly

The entry module /assets/index-LNYK_bk0.js - 324,591 bytes - statically imports exactly three JavaScript modules, and they are the three the pages preload. One to one: nothing extra, nothing missing.

What the preload set does not include is the entry module itself. Those 324,591 bytes are fetched by a plain script tag, not preloaded. Add them to the 549,227 preloaded bytes and an app page pulls 873,818 bytes of JavaScript, plus 245,702 bytes of CSS.

The icon block, and the size the tag does not name

Four of the seven links on a guide page are the icon block, and all four are the same on all 56 pages:

  • rel="icon" with type="image/svg+xml" pointing at /favicon.svg - 531 bytes
  • rel="icon" with sizes="48x48" pointing at /favicon.ico - 3,556 bytes
  • rel="apple-touch-icon" pointing at /apple-touch-icon.png - 3,492 bytes, a 180 by 180 PNG
  • rel="manifest" pointing at /site.webmanifest - 876 bytes, served as application/manifest+json

The ICO is the interesting one. The tag tells a crawler the file is 48x48. The file is an ICO container holding three images: 16 by 16, 32 by 32 and 48 by 48, all 32 bits per pixel. So one link tag advertises one of the three sizes the file actually holds, and the other two stay invisible to anything that trusts the attribute.

What I did not do

One build, one day, one network, plain HTTPS, signed out, one GET per URL. I counted the served HTML only - nothing was rendered in a browser, so this is what the server sends before any script runs. The ICO header was parsed by hand: no image was decoded and no pixels were inspected. The import graph was read out of the served bundle text, not out of a build manifest. I make no claim about how any browser prioritises these requests.

If you want to see it for yourself, the OnePassApps home page is the app-bundle shape, and the guides page is the seven-link shape. They differ by three tags and nothing else.