Caching Strategies: ภาพรวม

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

network request ล้มเหลวได้จากหลายสาเหตุ — ผู้ใช้อยู่ออฟไลน์ อยู่บนการเชื่อมต่อที่ช้า หรือ server ใช้งานไม่ได้ชั่วคราว หากไม่มี cache สถานการณ์เหล่านี้ล้วนทำให้ประสบการณ์ใช้งานพังลง แต่ด้วย caching strategy ที่เลือกมาอย่างดี browser สามารถเสิร์ฟ asset จาก local storage ได้ทันทีและซิงค์กับ server ในเบื้องหลัง

caching ยังช่วยตัด round trip ที่ไม่จำเป็นออกไปด้วย ไฟล์ CSS ที่ไม่ได้เปลี่ยนแปลงไม่จำเป็นต้องวิ่งผ่าน network ทุกครั้งที่มีคนโหลดหน้าเพจของคุณ การเสิร์ฟจาก local cache ลดเวลาโหลดจากหลายร้อยมิลลิวินาทีให้เหลือเกือบเป็นศูนย์

Precache กับ runtime cache

Precaching เกิดขึ้นตอน service worker install คุณระบุ URL ที่ต้องการแคชอย่างชัดเจน แล้ว browser จะดึงและเก็บไฟล์เหล่านั้นก่อนที่ SW จะ activate วิธีนี้เหมาะที่สุดสำหรับ app shell ของคุณ — ไฟล์ HTML, CSS, และ JS ที่ประกอบเป็นโครงสร้างหลักของ UI

Runtime caching เกิดขึ้นแบบ on demand ในครั้งแรกที่ผู้ใช้ร้องขอ resource (รูปภาพ, การตอบกลับจาก API, ฟอนต์) service worker จะดักจับ fetch เก็บ response นั้นไว้ และเสิร์ฟ request ครั้งถัดไปจาก cache แนวทางนี้เหมาะกับเนื้อหาแบบไดนามิกหรือเฉพาะผู้ใช้ที่คุณไม่สามารถระบุล่วงหน้าตอน build ได้

ภาพรวมของ strategy

Strategy	เหมาะกับ	ข้อแลกเปลี่ยน
Cache-first	Static asset (CSS, JS, รูปภาพ)	อาจเสิร์ฟ asset ที่เก่าได้
Network-first	ข้อมูล API, HTML	ช้ากว่า; ต้องมี cache fallback
Stale-while-revalidate	avatar, feed, config	consistent ในที่สุด
Cache-only	app shell ที่ pre-cache ไว้	ไม่มี fallback ไป network
Network-only	การชำระเงิน, analytics	ไม่รองรับออฟไลน์

การเลือก strategy

flowchart TD
  A[Start: incoming request] --> B{Is the asset static?}
  B -->|Yes| C[Cache-first]
  B -->|No| D{Does freshness matter?}
  D -->|Yes, always fresh| E[Network-first]
  D -->|Mostly fresh is fine| F[Stale-while-revalidate]
  D -->|No network needed| G[Cache-only]
  E --> H{Network failed?}
  H -->|Yes| I[Serve from cache fallback]
  H -->|No| J[Return fresh response and update cache]

การเลือก caching strategy