Introduction: a JavaScript bundle was reduced from 2.1 MB to 890 KB, delivering a Lighthouse score boost on mid-range Android and establishing a protocol to prevent regressions.

Step 1: provide machine-readable build data by generating a bundle-report.json and a bundling report to map bytes by package and module, enabling precise targeted analysis.

Lessons learned: measurement is essential; attribute impact to one-change-per-measurement, leverage agents for repetitive tasks, supply artifacts and data to the agent, and implement guardrails to sustain improvements against ratcheting.

What’s next: set per-route budgets and incorporate real user monitoring to align optimization with actual user experience rather than lab benchmarks.

Core failure mode: generic guidance without task-specific data produced wrong recommendations, underscoring the need for real build artifacts.

Baseline metrics: starting bundle 2,148 KB (612 KB gzipped), Time to Interactive 8.4 seconds on Moto G4, Lighthouse score 41, 214 direct dependencies, and 11% mobile bounce rate before first interaction.

Step 3 findings: four fixes drove 87% of savings—swap a date library for Intl.DateTimeFormat (−312 KB), replace barrel-file imports with individual imports (−418 KB), lazy-load a charting library with dynamic import (−284 KB), and drop polyfills for deprecated browsers (−156 KB).

Wrap-up: for bundles over 1 MB, emit precise build-output analytics and invite readers to share worst-case bundle-bloat discoveries.

Final results: 2,148 KB to 890 KB (612 KB gzipped), Time to Interactive from 8.4s to 3.1s, Lighthouse score from 41 to 88.

Step 2 expanded: enforce a one-change-one-measurement protocol with automatic re-measurement and a rollback path, plus CI/build-budget discipline.