code splitting และ tree shaking คืออะไร?

Question

IT Interview Practice · Accepted Answer

ทั้งสองอย่างลด JavaScript ที่ผู้ใช้ต้องดาวน์โหลด **Code splitting** แบ่ง bundle ออกเป็น chunk ที่โหลดตามความต้องการ; **tree shaking** ลบโค้ดที่คุณไม่เคยใช้ออก ทั้งคู่เสริมกัน: split ว่า *อะไร* ที่โหลด, shake โค้ด *ที่ตายแล้ว* ออกจากแต่ละ chunk

## Code splitting

แทนที่จะเป็น bundle ก้อนใหญ่ก้อนเดียว แอปถูกแบ่งเพื่อให้แต่ละ route หรือฟีเจอร์ที่หนักเป็น chunk แยกที่ fetch เฉพาะเมื่อจำเป็น:

```js
// Route-based split: the dashboard code isn't downloaded until you visit it
const Dashboard = lazy(() => import("./routes/Dashboard")); // its own chunk

// Component-based split: heavy editor loaded on interaction
button.onclick = async () => {
  const { openEditor } = await import("./editor"); // fetched on click
  openEditor();
};
```

`import()` แบบ dynamic คือสัญญาณ — bundler จะออกไฟล์แยกที่ขอบเขตนั้น

## Tree shaking

bundler วิเคราะห์ `import`/`export` ของ ES module แบบ static แล้วตัด export ที่ไม่มีอะไรอ้างถึงทิ้ง มันทำงานได้เฉพาะกับ **ESM** (static, วิเคราะห์ได้) — ไม่ใช่ `require` ของ CommonJS:

```js
import { debounce } from "utils"; // only debounce is kept; throttle, etc. are shaken out
```

มันพึ่งพา `"sideEffects": false` ใน `package.json` และการ import ราย function; barrel file หรือ module ที่มี side effect อาจทำให้มันใช้ไม่ได้

## ข้อดีข้อเสีย

- Split มากเกินไป → มี request เล็ก ๆ จำนวนมากและ waterfall; จัดกลุ่มโค้ดที่เกี่ยวข้องกัน
- Tree shaking เปราะบาง — side effect ที่ทำเครื่องหมายผิดจะทำให้โค้ดที่ตายแล้วยังคงอยู่

## ทำไมจึงสำคัญ

ทั้งสองเป็นคันโยกที่อยู่เบื้องหลัง "ส่ง JS ให้น้อยลง" ผู้สัมภาษณ์อยากให้คุณรู้ว่า code splitting ตัดสิน *ว่าอะไรโหลดเมื่อไร*, tree shaking ตัดสิน *ว่ามีอะไรอยู่ในนั้นบ้าง* และ tree shaking พึ่งพา ESM แบบ static — รายละเอียดที่แยกคนที่เคยจูน bundle จริง ๆ ออกจากคนที่แค่อ่านผ่านมา

Code splitting

Tree shaking

ข้อดีข้อเสีย

ทำไมจึงสำคัญ

คำถามที่เกี่ยวข้อง