The docs charts render their SVG at build time, but the measurement data they render from is still shipped to every client, on every page.
Current Behaviour
docs/.vitepress/theme/chart/data.ts pulls the data files in with an eager raw glob:
const RAW = import.meta.glob<string>([...], { query: "?raw", import: "default", eager: true });eager: true makes this a static import edge, so Vite inlines every matched file into the module as a template literal. data.ts is a static dependency of the chart components, and those are registered globally in enhanceApp (docs/.vitepress/theme/index.ts) so that a chart's src stays depth-independent. The result is that all chart data lands in the shared theme chunk, which 85 of 86 built pages load — including every page that contains no chart at all.
Pre-rendering does not avoid this: VitePress is an SSG plus a client-side SPA, and hydration re-runs the components' setup() in the browser to reproduce the pre-rendered DOM. The data has to be present for that, so it cannot simply be dropped.
Measured on a current build:
|
raw |
gzipped |
| theme chunk |
129,310 B |
29,088 B |
| all inlined chart data (18 files) |
43,405 B (34% of chunk) |
— |
of which the three disk-perf JSONs |
31,331 B (24% of chunk) |
1,393 B marginal |
Proposal
Move data loading into VitePress build-time data loaders (*.data.ts with defineLoader). A loader runs only during the build and is excluded from the client bundle; only its return value is serialized, and into the page chunk rather than the shared theme chunk. Pages would then ship the parsed values they actually plot — for disk-perf roughly twenty numbers per system instead of 10 KB of JSON — and only on the pages that use them.
This touches all four chart components (BarChart, LineChart, DiskPerfChart, DiskPerfStats), data.ts, disk-perf.ts, and the src-prop convention, so it is a restructure of the whole chart system rather than a change to one chart type.
Notes
- This is pre-existing behaviour of the chart system introduced when it replaced the gnuplot PNGs, not a regression.
data.ts's header comment about keeping the globs narrow shows the constraint was already known.
- Compacting the committed JSON is not the fix: it saves about 16 KB raw but almost nothing gzipped, and it costs the "taken as they came out of the server" property those files are committed for.
- The win is bundle hygiene and not shipping chart data to unrelated pages. The absolute numbers are small — the
disk-perf share is 1.4 KB gzipped — so this is cleanup, not urgent.
Found while reviewing #3983.
The docs charts render their SVG at build time, but the measurement data they render from is still shipped to every client, on every page.
Current Behaviour
docs/.vitepress/theme/chart/data.tspulls the data files in with an eager raw glob:eager: truemakes this a static import edge, so Vite inlines every matched file into the module as a template literal.data.tsis a static dependency of the chart components, and those are registered globally inenhanceApp(docs/.vitepress/theme/index.ts) so that a chart'ssrcstays depth-independent. The result is that all chart data lands in the shared theme chunk, which 85 of 86 built pages load — including every page that contains no chart at all.Pre-rendering does not avoid this: VitePress is an SSG plus a client-side SPA, and hydration re-runs the components'
setup()in the browser to reproduce the pre-rendered DOM. The data has to be present for that, so it cannot simply be dropped.Measured on a current build:
disk-perfJSONsProposal
Move data loading into VitePress build-time data loaders (
*.data.tswithdefineLoader). A loader runs only during the build and is excluded from the client bundle; only its return value is serialized, and into the page chunk rather than the shared theme chunk. Pages would then ship the parsed values they actually plot — fordisk-perfroughly twenty numbers per system instead of 10 KB of JSON — and only on the pages that use them.This touches all four chart components (
BarChart,LineChart,DiskPerfChart,DiskPerfStats),data.ts,disk-perf.ts, and thesrc-prop convention, so it is a restructure of the whole chart system rather than a change to one chart type.Notes
data.ts's header comment about keeping the globs narrow shows the constraint was already known.disk-perfshare is 1.4 KB gzipped — so this is cleanup, not urgent.Found while reviewing #3983.