Rspeedy Bundle Optimization

A measure-first workflow for shrinking the bundle of a rspeedy/Lynx app. The central discipline: don't guess where the bytes are — measure, then attack the biggest lever first. Most "optimize the bundle" requests fail by starting with micro-tree-shaking when the real weight is media assets or main-thread leakage.

Verify against source — do not guess

The rspeedy / ReactLynx build behaves in non-obvious ways, and guessing is how you end up confidently wrong. When you're unsure how the build, the layers, the ES targets, or stats/rsdoctor output actually behave, read the source — don't infer from naming or memory. The whole toolchain is open source; clone or browse it and grep for the relevant plugin/util:

The toolchain layers as Rspack → Rsbuild → Rspeedy (each builds on the one before), so a behavior may live in any layer — follow it down:

• rspeedy + ReactLynx plugins (the lynx-stack monorepo): https://github.com/lynx-family/lynx-stack
• rsbuild (the Rsbuild layer rspeedy is built on): https://github.com/web-infra-dev/rsbuild
• rspack (the underlying bundler; stats/module types, layers, output.environment): https://github.com/web-infra-dev/rspack
• rsdoctor: https://github.com/web-infra-dev/rsdoctor

(Exact file paths aren't pinned here — they move between versions. Search by symbol, e.g. the ES-target util, the stats-json plugin, the entry/layer setup.) Several facts in this skill — main=ES2019 / background=ES2015, stats.json carrying layer, the entry→two-layer split — were each confirmed by reading the source or running a real build, not assumed. Hold new claims to the same bar.

NO GUESS — trace the real module graph, never narrate an import chain