Deferring one 7.8 MB GLB behind a tap dropped a 3D homepage payload to 370 KB

Component-level lazy loading is where this kind of work usually fails, and the author names the failure directly: code-splitting the React component is not enough if another import pulls the viewer runtime into the initial route ^[12]. A static import is resolved when the bundle is built, not when the component renders, so one sibling module importing the viewer package puts the runtime in the initial chunk no matter how carefully the stage is deferred ^[12]. The fix was deletion. Direct `@google/model-viewer` imports came out of the homepage and generation-output components ^[13], and a shared loader now injects a self-hosted `/vendor/model-viewer.min.js` as a module script only when a 3D component mounts ^[14].

That loader is the best-engineered part of the writeup. It returns early if `customElements.get("model-viewer")` is already defined, caches its promise in a module-level variable, reuses an existing script element rather than appending a second one, and resolves through `customElements.whenDefined` so callers wait for the element definition and not merely for the network ^[15]. The stage import uses the same trick, a module-level `stagePromise` assigned once, so repeated taps and re-renders reuse one in-flight import ^[9]. Two dedupe layers, and one loading contract for every 3D surface ^[16].

The first screen is a load-path decision rather than an asset decision. The mobile cover is a 19 KB AVIF served at 768 by 576 with `fetchPriority="high"` and `loading="eager"` ^[10], sharing the interactive stage's 4:3 geometry so the swap does not move surrounding content ^[8]. That is a deliberate election of the LCP candidate: the cheapest element on the page gets priority, and the slot that used to cost 7,833,440 bytes now costs roughly 410 times less ^[24].

The headline result travels less well than the method. It rests on three mobile Lighthouse runs, labelled by the author as lab-tested rather than field data, with INP unavailable because Chrome UX Report did not hold enough real-user data for the site ^[17][18]. He also says the final LCP missed his stricter target of under 2 seconds, and calls the work a large improvement rather than finished ^[19]. So the part that transfers is the share arithmetic, not the 370 KB, and it transfers where one asset dominates and the hero is genuinely optional. At 40 percent share the same audit produces a different decision, and nobody has ever tuned 30 KB of CSS into a 7.8 MB win ^[7].

One gap remains in the account. By the stated totals, deferring the GLB still leaves about 1.27 MB of initial resources, so reaching 370 KB means roughly another 900 KB left the initial path ^[26]. The author says the walkable Three.js world was heavier still than the GLB ^[20], and the published account breaks off before showing how that one was handled. The reusable output here is the measurement order: get the byte share per URL first, then decide whether you are tuning assets or redesigning the load path ^[21].