Bundle Monitoring

21.4.1. Bundle Size Criteria

Build output sizes must not exceed the following thresholds.

Item	Maximum Size	Measurement Basis	TQS Requirement
Initial JavaScript	300KB	After gzip compression	Mandatory
Single Chunk Maximum	500KB	After gzip compression	Mandatory
Total CSS	100KB	After gzip compression	Mandatory
Single Image Asset	500KB	Original size	Mandatory

• Initial JavaScript is measured as the combined size of all JS files loaded at the entry point.
• If a single chunk exceeds 500KB, code splitting must be applied to separate it.
• Third-party libraries must be separated into a vendor chunk to improve caching efficiency.
• CSS must be minimized by removing unused styles (PurgeCSS, etc.).

---

21.4.2. Analysis Tools

The following tools must be used to visually analyze bundle composition.

Tool	Purpose	Application Timing
rollup-plugin-visualizer	Vite/Rollup bundle visualization	Post-build analysis
source-map-explorer	Source map-based bundle analysis	Post-build analysis
bundlephobia	Pre-check package size	Before package adoption

• Bundle analysis must be performed at minimum on a per-release basis (sprint end or version release).
• Using rollup-plugin-visualizer to generate bundle composition reports (HTML files) is recommended.

// vite.config.ts
import { visualizer } from 'rollup-plugin-visualizer'

export default defineConfig({
  plugins: [
    visualizer({
      filename: 'dist/bundle-report.html',
      gzipSize: true,
    }),
  ],
})

• Before adopting a new package, bundlephobia must be used to verify the package size and tree-shaking support.
• Retaining analysis reports as build artifacts to track size change trends is recommended.

---

21.4.3. CI Size Verification

Build output sizes must be automatically verified in the CI pipeline.

• After the build completes, output sizes must be measured and compared against the criteria defined in Section 21.4.1.
• Builds exceeding the thresholds must be failed.
• Integrating bundlesize or size-limit tools into CI for automated verification is recommended.

// package.json - size-limit configuration example
{
  "size-limit": [
    { "path": "dist/assets/*.js", "limit": "300 KB", "gzip": true },
    { "path": "dist/assets/*.css", "limit": "100 KB", "gzip": true }
  ]
}

• Automatically commenting bundle size changes on PRs (Pull Requests) is recommended.
• When size increases by 10% or more, the root cause must be analyzed during code review.

---

21.4.4. Performance Budget

A performance budget must be established and managed for each project.

Budget Item	Threshold	Measurement Method
Initial JS Size	300KB (gzip)	Build output measurement
Total CSS Size	100KB (gzip)	Build output measurement
LCP	2.5 seconds or less	Lighthouse CI
INP	200ms or less	Chrome UX Report
CLS	0.1 or less	Lighthouse CI
Lighthouse Performance Score	90 or above	Lighthouse CI

• The performance budget must be established at the beginning of the project and shared with the entire team.
• When the budget is exceeded, the following procedure must be followed.
  1. Identify the code or resource causing the issue.
  2. Apply improvement measures such as code splitting, lazy loading, and resource optimization.
  3. Verify that the values have returned to within the defined thresholds after improvement.
• Performance budget criteria must be reviewed on a 6-month cycle and adjusted to reflect changes in the technology landscape.
• During review, the appropriateness of threshold values must be evaluated based on real user data (RUM).