perf(vue-mri): cut the eager bundle 77% in the portal and 40% in Atlas

[khairul-syazwan]

Twelfth and last in the Data Exploration redesign stack. Based on khairul-syazwan/atlas-native-mount (#3318), not develop — review that one first.

No ticket. This finishes #3116 by making the redesign cheap to load.

Why this is last, and not first

It was going to land before the native Atlas mount, because Atlas3 imports every plugin eagerly at boot with a 30 second timeout, so a large entry is a real risk there. The order was reversed on purpose: the ticket owner wants Atlas load benchmarks taken before and after this change, and that needs the mount landed first. The two compose cleanly, so this is sequencing, not dependency.

What it does

Four performance commits, each one independently measured, plus three from review. Read the commit messages — they carry the reasoning and the numbers, and are the better record than this summary.

Commit	Change
perf(vue-mri): keep only the woff2 source in each @font-face	Vite library mode ignores assetsInlineLimit and inlines every asset as base64. @mdi/font uses bulletproof @font-face syntax, so 4.69 MiB of icon binary became 6.25 MiB of the entry, for a font where browsers only read the 403 KiB woff2
perf(vue-mri): load the chart libraries on demand	Four static paths reached plotly.js, echarts and d3. All four broken, so Rollup can split them
fix(atlas): stop registering the Atlas researcher plugin	Removes a manifest entry that produced two 404s on every portal load and never worked
perf(portal): preload the active plugin first, queue the rest	Six plugin bundles went on the wire together and starved the one the user opened

Measured

A/B on identical bases: this branch against its own parent, same machine, same build commands. Gzipped, kB as Vite reports them.

Entry	Without	With	Change
portal, resources/mri/lifecycles.js	4,075 kB	938 kB	−77%
native Atlas, dist-atlas-native/index.system.js	6,701 kB	4,047 kB	−40%

Chunk count 47 → 54. plotly.js becomes its own 1,430 kB gzipped chunk that the Cohorts page never requests.

The Atlas number is the one that matters most. The host fetches only the entry, eagerly, for every installed plugin at boot.

The absolute byte counts in the commit messages were measured against develop before the rebase and drift slightly from the table above; the percentages hold.

Three defects found in review, fixed here

The four performance commits were written in an earlier session and had never been reviewed. Review found three, all of them created by this diff rather than pre-existing.

• A chart that failed to load showed nothing at all, and said nothing. This is the significant one. Making the four chart components lazy turned static imports into runtime network dependencies — a static import cannot fail once the entry has run, a chunk fetch can. And the app sets app.config.errorHandler = () => null in every non-debug build, in both main.ts and lifecycles.ts, so the rejection was discarded: an empty pane, nothing in the console, and no reason for the user to try a reload. A stale document asking for a chunk hash that a new deployment has replaced produces exactly that, and is the most likely cause. There is now a lazyComponent helper that retries once, then renders an error with a reload and logs through console.error, which the suppressed handler cannot swallow.
• A queued preload was never cancelled when its plugin unregistered, so a plugin the user had navigated away from was still downloaded, competing with whatever they opened instead. A dataset switch remounts the whole researcher container, so this is ordinary, not an edge case. Worse, generateAppId derives the id from the path alone, so a re-register reused the id and left two entries queued for one plugin — two background downloads, which is the exact thing the scheduler was written to prevent.
• foregroundInFlight was a boolean. Two plugins can both match the current location when their base paths nest; the first to settle resumed background draining while the second was still on the wire. Latent today, since no two current manifests overlap. It is a counter now.

Review also confirmed, by tracing: no static path to plotly, echarts or d3 survives; the now-async drilldown action is safe at its one non-awaited call site, because every synchronous dispatch runs before the first await; the hand-resolved PatientAnalytics.vue rebase conflict is correct; and the postcss plugin no-ops correctly on a rule with no woff2 source.

The chart split only works if every static path is broken

One surviving static import pins the chunk back into the entry, and nothing in the build fails when that happens — the bundle just gets big again quietly. The four paths were:

• store/modules/query.ts — imported plotly for a single update() call in drilldown. This one was the load-bearing case: the store is built by lifecycles.ts, so it alone pinned the chunk to the entry. The action is now async, and its callers were checked.
• PatientAnalytics.vue, CohortComparisonDialog.vue, ChartToolbar.vue, query-filter/components/ExecuteSidePanel.vue — now declare their chart-bearing children with defineAsyncComponent.

The chart components themselves are untouched.

Section 4.4 of the project roadmap carries a follow-up: add a build-time check that keeps plotly off the entry. Nothing today prevents a future static import from silently undoing this.

Blast radius

perf(portal): preload the active plugin first touches the React portal's single-spa registry — plugins/ui/apps/portal/src/singleSpa/. That is wider than vue-mri, and it changes the load behaviour of every plugin the portal hosts, not just this one.

Deferring a preload is only an optimisation: if a plugin is opened before its queued preload runs, single-spa calls its load function on activation and the module cache dedupes the two callers. The plugin whose route is already active still preloads immediately, which is what closes the LOADING_SOURCE_CODE race the eager preload was added for.

Validation

Reported honestly; this is not a claim of full end-to-end coverage.

Check	Result
Unit tests, Node 20, the command CI runs	1083 passed, 3 skipped. 15 new
vite build (portal)	pass
vite build --config vite.config.atlas.ts	pass
vite build --config vite.config.atlas-app.ts	pass
vite build --config vite.config.atlas-native.ts	pass
prettier --check on the files this branch adds	pass
eslint	not run. plugins/ui hoists eslint 7.32, which cannot read the app's flat config
Bundle A/B measurement	done, table above
no-mistakes gate	not run. It does not follow a treehouse worktree and targets develop, not this stack's parent — the same path every pull request in this stack has taken

Portal tests run separately, through react-scripts test: 8 passed in preloadScheduler.test.ts, 3 new.

Every new test was checked against the previous behaviour before being trusted: the two lazy-load tests fail with RETRY_LIMIT at 0 and no errorComponent, and the three scheduler tests fail with the cancel, the dedupe and the counter reverted.

Three files this branch touches — CohortComparisonDialog.vue, store/modules/query.ts and lib/i18n.ts — already fail prettier --check on the parent branch. Left alone rather than reformatted, to keep the diff readable. The two files the branch adds were formatted.