Cache-Control — คืออะไร คำสั่ง และการจัดการแคช

Cache-Control คืออะไร?

Cache-Control คือส่วนหัว HTTP ที่ได้มาตรฐานใน HTTP/1.1 (RFC 7234) ซึ่งช่วยให้เซิร์ฟเวอร์สามารถระบุได้ว่าไคลเอ็นต์ โพรกซี และ CDN สามารถแคชคำตอบได้อย่างไรรและนานเท่าใด ไม่เหมือนกับ Expires (HTTP/1.0), Cache-Control ใช้คำสั่ง — คำสั่งข้อความที่รวมกันด้วยจุลภาค: Cache-Control: public, max-age=3600, must-revalidate ส่วนหัวนี้ให้การควบคุมแบบละเอียดเหนือทุกจุดในโซ่อีแคชวิง

แคชวิงเป็นกลไกกลไกพื้นฐานของประสิทธิภาพแอปพลิเคชันเว็บและมือถือ หากไม่มีมัน ทุกคำขอของผู้ใช้จะไปที่เซิร์ฟเวอร์โดยตรง ทำให้เกิดภาระเกินไปและความห้วงช้า Cache-Control กำหนดสามระดับแคชวิง: เบราว์เซอร์/แอปพลิเคชัน (แคชส่วนตัว), เซิร์ฟเวอร์โพรกซี (แคชร่วมใช้), และ CDN (แคชกระจาย) แต่ละระดับแปลคำสั่งแตกต่างกัน

การกำหนดค่า Cache-Control ที่ไม่ถูกต้องเป็นสาเหตุที่พบบ่อยที่สุดของปัญหาด้านประสิทธิภาพ แคชวิงที่รุกรานเกินไปอาจทำให้ผู้ใช้เห็นข้อมูลที่ล้าสมัย แคชวิงที่อ่อนแอเกินไปอาจทำให้เกิดคำขอมากเกินไปถึงเซิร์ฟเวอร์และการโหลดช้า ตามข้อมูลจาก Akamai (2025), การเพิ่มประสิทธิภาพ Cache-Control สำหรับเนื้อหาคงที่ช่วยลดภาระเซิร์ฟเวอร์ได้ 70-90% และปรับปรุงเวลาโหลด 40-60% สำหรับผู้ใช้มือถือ

ประวัติของส่วนหัว

Cache-Control ปรากฏใน HTTP/1.1 (RFC 2616, 1999) เป็นตัวแทนของ Expires Expires มีปัญหาพื้นฐาน: ใช้วันที่แท้จริงซึ่งขึ้นอยู่กับโซนเวลาของเซิร์ฟเวอร์และไคลเอ็นต์ Cache-Control แก้ปัญหานี้โดยเปลี่ยนไปใช้เวลาสัมพัทธ์ (max-age เป็นวินาทีนับตั้งแต่ช่วงที่ได้รับคำตอบ) ต่อมาใน RFC 7234 (2014) ได้เพิ่ม คำสั่งใหม่: immutable สำหรับสินทรัพย์คงที่, stale-while-revalidate และ stale-if-error สำหรับการตรวจสอบที่เลื่อนเวลา

คำสั่ง Cache-Control

Cache-Control ประกอบด้วยคำสั่งมากกว่า 10 รายการแบ่งออกเป็นสามกลุ่ม: คำสั่งคำขอ (ไคลเอ็นต์ → เซิร์ฟเวอร์), คำสั่งคำตอบ (เซิร์ฟเวอร์ → ไคลเอ็นต์), และส่วนขยาย ในทางปฏิบัติ การพัฒนามือถือใช้คำสั่งคำตอบหลัก 6-7 รายการที่ครอบคลุม 95% ของสถานการณ์แคชวิง ลองดูแต่ละคำสั่งพร้อมตัวอย่างและคำแนะนำ

max-age เป็นคำสั่งที่สำคัญที่สุด มันห้ามไคลเอ็นต์ส่งคำขอไปยังเซิร์ฟเวอร์ตามระยะเวลาที่กำหนด สำหรับสินทรัพย์คงที่ (CSS, JS, รูปภาพ) max-age โดยทั่วไปกำหนดตั้งแต่ 1 วันถึง 1 ปี สำหรับคำตอบ API — ตั้งแต่ 0 วินาที (ข้อมูลใหม่เสมอ) ถึง 5-10 นาที (ข้อมูลอ้างอิง) s-maxage ช่วยให้กำหนดอายุที่แตกต่างกันสำหรับ CDN และเบราว์เซอร์: CDN เก็บสำเนาไว้ 1 วัน, เบราว์เซอร์เก็บไว้ 1 ชั่วโมง

no-cache vs no-store

คำสั่งสองนี้มักถูกสับสน no-cache ไม่ได้ห้ามแคช — มันต้องการ ตรวจสอบ สำเนาที่เก็บไว้ในแคชทุกครั้งที่ใช้ผ่านคำขอแบบมีเงื่อนไข (If-Modified-Since หรือ If-None-Match) หากเซิร์ฟเวอร์ตอบด้วย 304 — ไคลเอ็นต์ใช้แคช หาก 200 — มันอัปเดต no-store ในทางกลับกัน ห้ามไม่ให้เก็บคำตอบในแคชใดๆ รวมถึงแผ่นดิสก์และหน่วยความจำ ใช้ no-store เฉพาะสำหรับข้อมูลที่อ่อนไหว — โทเคน, ข้อมูลการชำระเงิน, เอกสารส่วนบุคคล

Cache-Control vs Expires

ส่วนหัว Expires (HTTP/1.0) ก็ระบุอายุของทรัพยากรแต่ใช้วันที่แท้จริง: Expires: Thu, 03 Jul 2026 12:00:00 GMT Cache-Control max-age ใช้เวลาสัมพัทธ์จากช่วงที่ได้รับคำตอบ ความแตกต่างนี้สำคัญสำหรับระบบกระจาย: หากเซิร์ฟเวอร์และไคลเอ็นต์อยู่ในโซนเวลากัน Expires อาจถูกแปลความหมายผิด Cache-Control ไม่มีปัญหานี้ — 3600 วินาทีคือ 3600 วินาทีเสมอ

เมื่อมีทั้งสองส่วนหัว Cache-Control มีลำดับความสำคัญกว่า Expires ที่กำหนดไว้ใน RFC 7234: "หากคำตอบมีช่อง Cache-Control กับคำสั่ง max-age ผู้รับต้องละเว้นช่อง Expires" ในทางปฏิบัติ แนะนำไม่ให้ส่งคืน Expires สำหรับไคลเอ็นต์สมัยใหม่ เพราะ Cache-Control ครอบคลุมทุกสถานการณ์ของ Expires อย่างไรก็ตาม เพื่อความเข้ากันได้กับโพรกซีและเบราว์เซอร์เก่า สามารถส่งคืนทั้งสองส่วนหัวได้

Expires ยังคงอยู่ส่วนใหญ่สำหรับเนื้อหาคงที่บน Nginx และ Apache — เซิร์ฟเวอร์เหล่านี้เพิ่มทั้งสองส่วนหัวโดยอัตโนมัติ หากโปรเจกต์ของคุณพบ Expires โดยไม่มี Cache-Control ให้แทนที่ด้วย Cache-Control ที่มี max-age: ความแม่นยำของการควบคุมแคชดีขึ้น และการพึ่งพา โซนเวลา หมดไป สำหรับการย้ายข้าม เพียงแค่กำหนดค่าเซิร์ฟเวอร์เพื่อเพิ่ม Cache-Control แทน Expires

# Nginx: คำสั่งควบคุมแคชสำหรับไฟล์คงที่
location ~* \.(jpg|jpeg|png|gif|ico|css|js)$ {
    expires 30d;
    add_header Cache-Control "public, immutable, max-age=2592000";
}

# นโยบายแตกต่างสำหรับเนื้อหาประเภทต่างๆ
location /api/config {
    expires -1;
    add_header Cache-Control "no-cache, must-revalidate";
}

location /api/static-data {
    expires 5m;
    add_header Cache-Control "public, max-age=300";
}

ในการกำหนดค่า Nginx ไฟล์คงที่ (CSS, JS, รูปภาพ) จะถูกตั้งค่าด้วย Cache-Control เป็นเวลา 30 วันโดยมีแอตทริบิวต์ immutable — แอตทริบิวต์นี้บอกเบราว์เซอร์ว่าทรัพยากรจะไม่เปลี่ยนแปลงที่ URL นี้ (การกำหนดเวอร์ชันผ่านแฮชในชื่อไฟล์) จุดสิ้นสุด API ใช้ no-cache สำหรับข้อมูลไฮนามิกและ public ที่มี max-age สั้นสำหรับข้อมูลอ้างอิง — รายการที่ถูกขอบ่อยแต่เปลี่ยนไม่บ่อย

แคชวิงในแอปพลิเคชันมือถือ

ในแอปพลิเคชันมือถือ Cache-Control มีบทบาทพิเศษเนื่องจากข้อจำกัดของเครือข่ายมือถือ: ความห้วงช้าสูง, การเชื่อมต่อที่ไม่มั่นคง, ข้อจำกัดด้านปริมาณข้อมูล แคชวิงที่เหมาะสมช่วยให้แสดงข้อมูลแก่ผู้ใช้ได้ทันที แม้แต่ขณะไม่ได้เชื่อมต่อ และอัปเดตในพื้นหลัง OkHttp บน Android และ URLSession บน iOS มีระบบแคชวิงในตัวที่เคารพ Cache-Control

OkHttp ใช้ CacheInterceptor ซึ่งอ่าน Cache-Control จากคำตอบและจัดการแคชวิงโดยอัตโนมัติ หากเซิร์ฟเวอร์ส่งคืน Cache-Control: max-age=3600 OkHttp จะไม่ส่งคำขอไปยังเซิร์ฟเวอร์เป็นเวลาหนึ่งชั่วโมง หลังจาก max-age หมดอายุ OkHttp จะส่งคำขอแบบมีเงื่อนไขพร้อม If-Modified-Since และ If-None-Match การกำหนดค่าแคชใน OkHttp: OkHttpClient.Builder().cache(Cache(directory, maxSize))

fun createCachedClient(cacheDir: File): OkHttpClient {
    return OkHttpClient.Builder()
        .cache(Cache(cacheDir, 10L * 1024 * 1024))
        .addNetworkInterceptor { chain ->
            val response = chain.proceed(chain.request())
            response.newBuilder()
                .header("Cache-Control",
                    "public, max-age=300")
                .removeHeader("Pragma")
                .build()
        }
        .build()
}

โค้ดสร้าง OkHttpClient ที่มีแคชขนาด 10 MB และแทนที่ Cache-Control ผ่าน NetworkInterceptor หากเซิร์ฟเวอร์ไม่ส่งคืน Cache-Control หรือใช้ Expires ตัวสกัดจะเพิ่ม public, max-age=300 (5 นาที) ตัวสกัดจะลบส่วนหัว Pragma (HTTP/1.0) ที่ล้าสมัยเพื่อความเข้ากันได้ แคชวิงบน iOS ทำงานคล้ายคลึงผ่าน URLCache.shared กับการตั้งค่า memoryCapacity และ diskCapacity

โหมดออฟไลน์และ stale-while-revalidate

คำสั่ง stale-while-revalidate ช่วยให้แสดงแคชที่ล้าสมัยแก่ผู้ใช้ในขณะที่แอปพลิเคชันดึงข้อมูลใหม่ในพื้นหลัง ทำให้เกิดผลการตอบสนองทันที: ผู้ใช้เห็นเนื้อหาทันที และหลังจากหนึ่งวินาทีมันจะอัปเดตเป็นเวอร์ชันล่าสุด รองรับโดย OkHttp ตั้งแต่เวอร์ชัน 3.10 และ URLCache บน iOS 14+ ตัวอย่าง: Cache-Control: max-age=3600, stale-while-revalidate=300 — 1 ชั่วโมงแคชใหม่ จากนั้น 5 นาทีแสดงข้อมูลที่ล้าสมัยพร้อมรีเฟรชในพื้นหลัง

ตัวอย่างการกำหนดค่า Cache-Control

ทรัพยากรแต่ละประเภทต้องการกลยุทธ์การแคชวิงที่แตกต่างกัน ลองดูการกำหนดค่าที่เหมาะสมสำหรับสถานการณ์ทั่วไปในการพัฒนามือถือ สำหรับเนื้อหาคงที่ที่มีแฮชในชื่อไฟล์ (bundle.abc123.js) คุณสามารถตั้ง max-age ได้สูงถึง 1 ปีโดยมี immutable สำหรับรายการ API ที่ไม่ค่อยอัปเดต (ไดเรกทอรี, หมวดหมู่) — max-age ตั้งแต่ 5 นาทีถึง 1 ชั่วโมงโดยมี stale-while-revalidate

สิ่งสำคัญที่ต้องจำคือ ความปลอดภัย: สำหรับคำตอบที่มีข้อมูลส่วนบุคคลของผู้ใช้ ให้ตั้ง private เสมอ หากไม่มีคำสั่งนี้ โพรกซีสาธารณะ (ตัวอย่าง องค์กร) สามารถแคชคำตอบและส่งต่อให้ผู้ใช้รายอื่น สำหรับโทเคนการตรวจสอบและข้อมูลการชำระเงิน ให้ใช้ no-store — แม้แต่แคชส่วนตัวก็ไม่ควรเก็บข้อมูลนี้ไว้บนแผ่นดิสก์

การแก้ไขปัญหาแคช

เพื่อตรวจสอบความถูกต้องของ Cache-Control ให้ใช้ส่วนหัว Age (แคชถูกเก็บไว้กี่วินาทีแล้ว) และ X-Cache (hit/miss บน CDN) ในเบราว์เซอร์ — แท็บ Network, คอลัมน์ Size แสดง "from disk cache" หรือ "304 Not Modified" หากทรัพยากรควรถูกแคชแต่โหลดทุกครั้ง ให้ตรวจสอบว่าเซิร์ฟเวอร์กำลังเพิ่ม Cache-Control: no-cache หรือ Pragma: no-cache ร่วมกับคำสั่งของคุณหรือไม่