CH9 · 應用層・效能與工程化 詳細 ROADMAP
計畫文件，不會被 Quartz 渲染。
回主 roadmap → frontend/ROADMAP.md
章節目標
這是 CH8 應用層的第二半——從 data flow 走到「讓產品能上線、能維護、能被真實使用者享用」的工程化層。涵蓋效能（Core Web Vitals / 圖片 / Bundle）、建置（Bundler 選型 / npm / Monorepo / Package 發布）、部署（環境變數 / 預覽 / Edge / CI/CD）、DX（開發者體驗）。
🌱 基本介紹
| # | 主題 | Slug | Stage | 大綱 |
|---|
| 01 | 前端工程化是什麼 | 01-what-is-frontend-engineering | 🌱 | 從「能跑」到「能上線」、從「能上線」到「能持續維護」的進化、工程化的三大塊（效能、建置、部署） |
❓ 為什麼需要
| # | 主題 | Slug | Stage | 大綱 |
|---|
| 02 | 為什麼需要效能優化（瀏覽器夠快吧） | 02-why-performance | 🌱 | CWV 直接影響 SEO 排名 / 轉換率、Bundle size 對行動網路的代價、RUM 告訴你的是實況不是 DevTools、為什麼效能是生產問題 |
| 03 | 為什麼需要 Monorepo（多 repo 不行嗎） | 03-why-monorepo | 🌱 | 共用套件版本管理、原子 commit、跨 repo 重構噩夢、為什麼 Turborepo / Nx / pnpm workspaces 興起 |
| 04 | 為什麼需要獨立部署平台（自架 server 不行嗎） | 04-why-deployment-platform | 🌱 | Preview URL、Edge 分發、自動 HTTPS、CI/CD 內建、為什麼 Vercel / Netlify / Cloudflare Pages 讓前端開發者愛不釋手 |
| 05 | 為什麼需要自己打包一次 npm | 05-why-publish-npm | 🌱 | 面對「為什麼 Bundle 裡有 1MB 沒用到的東西」、理解 lockfile、理解 package.json 各欄位，最好的方式就是自己發一次 |
🕰️ 演進
| # | 主題 | Slug | Stage | 大綱 |
|---|
| 06 | 效能優化演進 | 06-performance-evolution | 🌱 | jQuery 時代 optimizations → SPA 時代 bundle 危機 → Code splitting → Web Vitals → Core Web Vitals（SEO 信號）→ INP（2024）→ RUM |
| 07 | 部署與 DX 演進 | 07-deployment-evolution | 🌱 | FTP → SCP → Capistrano → Docker → Heroku → Netlify/Vercel → Edge/Preview-first → AI-native platform（v0 deploy） |
| 08 | Bundler 演進（pointer） | → CH3 #12 | 🌿 | 跨章 |
🧠 知識型
F11 前端效能
| # | 主題 | Slug | Stage | 大綱 |
|---|
| 09 | Core Web Vitals 與 Lighthouse | ⛔️ micro-service/15-f2e-lighthouse-ranking / seo/10-performance-cwv | 🌿 | 跨系列 |
| 10 | Code Splitting / Lazy Loading | 10-code-splitting | 🌱 | dynamic import、route-based、component-based、預取策略 |
| 11 | Memo / 虛擬列表（virtualization） | 11-memo-virtualization | 🌱 | React.memo / useMemo 何時有效、TanStack Virtual / react-window |
| 12 | 圖片優化 | 12-image-optimization | 🌱 | srcset / WebP / AVIF / lazy / fetchpriority、Next.js Image / unpic |
| 13 | RUM 與 Web Vitals 回傳 | 13-rum-web-vitals | 🌱 | Performance Observer + beacon、sentry / datadog 整合、跟 CH15 觀測連動 |
| 14 | SEO 分數如何影響前端架構 | 14-seo-drives-frontend | 🌱 | CWV 直接影響 SEO 排名、為什麼 RSC / SSR / SSG 興起、為什麼圖片優化不是 nice-to-have |
| 15 | Bundle 分析與瘦身 | 15-bundle-analysis | 🌱 | webpack-bundle-analyzer / rollup-plugin-visualizer / Source Map Explorer、tree-shake 診斷、dependency 替代 |
F12 建置工具與工程化
| # | 主題 | Slug | Stage | 大綱 |
|---|
| 16 | 為什麼需要 Bundler | ⛔️ frontend/js/05-why-bundler | 🌱 | CH3 已處理，這裡是 pointer |
| 17 | npm / yarn / pnpm / bun 比較 | 17-package-managers | 🌱 | 速度、lockfile、workspace 支援、hard link、為什麼 pnpm 在 2026 流行 |
| 18 | Webpack / Vite / Turbopack / Rspack | 18-bundler-comparison | 🌱 | 生態 / 速度 / 設定複雜度 / HMR / SSR 支援 |
| 19 | Monorepo vs Multi-repo | ⛔️ process/06-monorepo-vs-multirepo | 🌿 | 跨系列 |
| 20 | Monorepo 前端專用工具 | 20-monorepo-frontend | 🌱 | Turborepo / Nx / pnpm workspaces / Bun workspaces、cache / 平行化 / 任務編排 |
| 21 | Package 發布到 npm | 21-publish-to-npm | 🌱 | 從 0 到 published、package.json 關鍵欄位、dual package（CJS + ESM）、types 檔、semver、prepublish、release-please |
| 22 | 公司內 npm 管理工具 | 22-internal-npm | 🌱 | 什麼時候值得建 Verdaccio / Nexus / GitHub Packages、私有 scope、版本管控、安全掃描 |
| 23 | 何時該建 UI Library | 23-when-ui-library | 🌱 | 2 個專案共用不夠、5 個要考慮、多團隊必做；建 UI library 前的 checklist（DS token、a11y、測試、版本） |
F13 部署與 DX
| # | 主題 | Slug | Stage | 大綱 |
|---|
| 24 | 環境變數分層 | 24-env-variables | 🌱 | build-time vs runtime、.env 管理、secrets、public vs private vars |
| 25 | 部署平台比較 | 25-deployment-platforms | 🌱 | Vercel / Netlify / Cloudflare Pages / GitHub Pages / AWS Amplify、feature / pricing / lock-in |
| 26 | Preview deployment 工作流 | 26-preview-deployment | 🌱 | PR preview、跟 designer / PM 協作、branch-based URL |
| 27 | CDN 與 Edge 運算 | 27-cdn-edge | 🌱 | 靜態 CDN vs Edge Function、cache headers、stale-while-revalidate |
| 28 | 版本號、Cache Busting、Source Map | 28-versioning-cache-sourcemap | 🌱 | chunk hash、source map 上傳 sentry、versioning 策略 |
| 29 | 前端 CI/CD | ⛔️ standards/06-good-cicd-pipeline | 🌿 | 跨系列 |
🔧 小實作注意事項
| # | 主題 | Slug | Stage | 大綱 |
|---|
| 30 | 大型列表效能實戰 | 30-large-list-performance | 🌱 | 1 萬筆資料的渲染、virtualization 選型、搜尋 / 篩選 / 排序優化 |
| 31 | Bundle 瘦身實戰 | 31-bundle-slim-practice | 🌱 | 實際把 1.2MB → 500KB 的案例、替代套件選擇 |
| 32 | 發布一個真正的 npm package | 32-publish-real-package | 🌱 | 從想法到 npm install 走一次、含 CI 自動發佈 |
| 33 | Preview deployment 工作流搭建 | 33-preview-deployment-setup | 🌱 | GitHub Actions / Vercel / Cloudflare Pages 任一完整配置 |
| 34 | Monorepo 從 0 搭建（Turborepo） | 34-monorepo-setup | 🌱 | apps + packages 結構、共享 tsconfig / eslint、CI pipeline |
| 35 | Lighthouse CI 導入 | 35-lighthouse-ci | 🌱 | PR 上自動 audit、budget 設定、fail-on-regression |
💣 Anti-pattern
| # | 主題 | Slug | Stage | 大綱 |
|---|
| 36 | 效能與工程化 Anti-patterns | 36-engineering-anti-patterns | 🌱 | 過早 memo、Bundle 裡塞 lodash 全部、.env 漏到 client、沒 source map、不看 bundle analyzer、Monorepo 但沒 cache（每次 build 全跑）、npm install 在 production 時才執行 |
🧰 對應檢查工具
| # | 主題 | Slug | Stage | 大綱 |
|---|
| 37 | 工程化工具生態 | 37-engineering-tooling | 🌱 | Bundle Analyzer、Lighthouse CI、Sentry、Renovate、Dependabot、Turborepo、Changeset、依賴審計（npm audit / Snyk） |
📎 補充
| # | 主題 | Slug | Stage | 大綱 |
|---|
| S01 | Analytics 整合 | s01-analytics | 🌱 | GA4 / Plausible / PostHog、privacy-first 選項 |
| S02 | 支付整合 | s02-payment-integration | 🌱 | Stripe / TapPay / 綠界、跨 CH11 資安 |
| S03 | Preview → Staging → Production 三環境設計 | s03-three-env-design | 🌱 | 環境 promotion 流程、環境差異管理、database seed 策略 |
章節進度統計
- 知識主題：37 + 3 補充 = 40 項
- 🌿 growing：3（跨系列）
- 🌱 seed：37
跨系列連結
- →
frontend/application/ CH8（資料流、API、版型）
- →
frontend/browser/ CH4（Performance Observer、Service Worker）
- →
frontend/architecture/ CH7（Edge / SSG / ISR / RSC 選型）
- →
frontend/observability/ CH15（RUM、Sentry、Web Vitals）
- →
seo/10-performance-cwv（效能 ↔ SEO）
- →
process/ 系列（CI/CD、release、monorepo）
- →
standards/ 系列（好的 CI/CD）
- → W04 walkthroughs（API 5 種）
- → W05 CMS capstone（完整部署 pipeline）