pool.html: three.js is 257 KB from a third-party CDN on the default tab

[defenwycke]

What

The Quasar tab is the default view on pool.html (<button class="active" data-viz="quasar">), and it renders through three.js, which is fetched from unpkg at page load:

<script type="importmap">
{ "imports": {
    "three": "https://unpkg.com/three@0.160.0/build/three.module.js",
    "three/addons/": "https://unpkg.com/three@0.160.0/examples/jsm/"
} }
</script>

Measured 2026-08-18:

three.module.js, gzipped	256,690 bytes
three.module.js, raw	1,272,972 bytes
plus	three/addons/controls/OrbitControls.js
pool.html itself, gzipped	26,181 bytes

So every visitor downloads ~257 KB from a third party — roughly 10x the page — before the default view can render, whether or not they care about the visualisation.

Why it matters beyond page weight

• It is a third-party runtime dependency on a public page. If unpkg is slow, rate-limited, or unreachable from a visitor's network, the default tab does not render.
• It is unpinned against tampering — no SRI hash, and importmap does not support integrity.

What has already been done

preconnect + modulepreload hints were added in 1e7235b6c, so the browser opens the connection and starts the download immediately instead of waiting until it has parsed the importmap and reached the module script near the end of the body. That only stops it starting late — it does not make it smaller, and it does not remove the third-party dependency.

Options

1. Self-host it. Vendor three.module.js + OrbitControls.js under /var/www/bitcoinghost/vendor/ and point the importmap at same-origin paths. Removes the third-party dependency, reuses the already-warm TLS connection. Cost: ~1.3 MB of vendored library in the repo.
2. Lazy-load behind the tab switch. Only import three when the Quasar tab is actually selected, and default to a cheaper tab. Biggest win for first paint, but changes what a visitor sees first — a product call.
3. Both.

Not a server problem

Worth stating so nobody chases it there: the share-stream endpoint the Quasar polls costs 29 ms, and at 6s x 8 VMs = 80 req/min that is negligible server-side. This issue is purely client page-weight.

Context: the pool page's server-side slowness was a different cause entirely — see the records?window=month issue.