HTTP caching ทำงานอย่างไรกับ immutable asset และ CDN?

Question

IT Interview Practice · Accepted Answer

HTTP caching ช่วยให้เบราว์เซอร์และ CDN นำ response กลับมาใช้ซ้ำได้แทนที่จะ fetch ใหม่ ควบคุมด้วย header **`Cache-Control`** รูปแบบที่ชนะสำหรับเว็บแอป: **ใส่ hash ในชื่อไฟล์ asset แล้ว cache มันตลอดกาล; ส่วน HTML ให้ cache ไม่ได้**

## กลยุทธ์สองชั้น

```http
# Hashed, versioned assets — content never changes for a given URL
Cache-Control: public, max-age=31536000, immutable
# e.g.  /static/app.9f2c1a.js   (the hash changes when content changes)

# HTML — must always be fresh so it can point at new asset hashes
Cache-Control: no-cache
```

- **`immutable`** บอกเบราว์เซอร์ว่าไม่ต้อง revalidate เลย — ไม่มี conditional request ใด ๆ แม้แต่ตอน reload ปลอดภัยเพราะ hash ในชื่อไฟล์ *คือ* เวอร์ชัน; เนื้อหาใหม่ = URL ใหม่
- **`no-cache`** บน HTML เป็นชื่อที่ชวนเข้าใจผิด: มันหมายถึง "เก็บไว้ แต่ revalidate ก่อนใช้" (ได้ 304 ถ้าไม่เปลี่ยน) ดังนั้นผู้ใช้จะได้ HTML ที่อ้างถึง asset hash ปัจจุบันเสมอ

## Revalidation และ CDN

- **`ETag`** / `Last-Modified` เปิดให้มี response `304 Not Modified` ที่ราคาถูกเมื่อ `max-age` หมดอายุ
- **CDN** cache ที่ edge node ใกล้ผู้ใช้ ใช้ `s-maxage` สำหรับ cache ที่แชร์กันของ CDN และ `stale-while-revalidate` เพื่อเสิร์ฟเนื้อหาเก่าทันทีขณะรีเฟรชในเบื้องหลัง:

```http
Cache-Control: public, s-maxage=600, stale-while-revalidate=86400
```

## ข้อควรระวัง

- Cache HTML ด้วย `max-age` ที่ยาว → ผู้ใช้ติดอยู่กับเวอร์ชันเก่าโดยไม่มีทางล้างมัน
- `immutable` บน URL ที่ไม่มี hash → คุณจะส่ง fix ออกไปไม่ได้

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

Caching คือการชนะด้านประสิทธิภาพที่ถูกที่สุด — มันเปลี่ยนการเข้าชมซ้ำให้ไม่มีต้นทุน network เลยและลดภาระ origin รูปแบบ asset-immutable-ที่มี hash + HTML-ที่-revalidate คือมาตรฐานของวงการ; การอธิบายได้ว่า *ทำไม* `no-cache` ≠ "อย่า cache" บ่งบอกถึงความเข้าใจที่ลึกจริง

กลยุทธ์สองชั้น

Revalidation และ CDN

ข้อควรระวัง

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

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