กลับไปหน้าบทความ
#HTTP Caching#Web Performance#Cache-Control#Frontend#DevTools

เทคนิคตั้งค่า HTTP Caching ให้เว็บเร็วขึ้นแบบเห็นผลทันที

การทำให้เว็บเร็วขึ้นไม่จำเป็นต้องเริ่มจากการอัปเกรดเซิร์ฟเวอร์เสมอไป หากตั้งค่า HTTP Caching ได้ถูกต้อง เบราว์เซอร์จะลดการโหลดไฟล์ซ้ำและช่วยให้เว็บตอบสนองไวขึ้นอย่างชัดเจน

11 กุมภาพันธ์ 2569อ่านประมาณ 2 นาที

แชร์บทความ

เทคนิคตั้งค่า HTTP Caching ให้เว็บเร็วขึ้นแบบเห็นผลทันที

เทคนิคตั้งค่า HTTP Caching ให้เว็บเร็วขึ้นแบบเห็นผลทันที

การเพิ่มความเร็วให้เว็บไซต์ไม่จำเป็นต้องเริ่มจากการลงทุนกับเซิร์ฟเวอร์แรงขึ้นเสมอไป หนึ่งในวิธีที่คุ้มค่าและเห็นผลเร็วที่สุดคือการตั้งค่า HTTP Caching ให้เหมาะสม เพื่อให้เบราว์เซอร์จดจำไฟล์ที่เคยโหลดแล้ว และไม่ต้องดึงไฟล์เดิมซ้ำทุกครั้งที่ผู้ใช้เปิดหน้าใหม่

เว็บไซต์จำนวนมากช้าลงเพราะมีการโหลดไฟล์เดิมซ้ำๆ เช่น CSS, JavaScript, รูปภาพ หรือฟอนต์ ทั้งที่ไฟล์เหล่านี้ไม่ได้เปลี่ยนทุกครั้งที่ผู้ใช้คลิกไปยังหน้าอื่น หากจัดการแคชอย่างถูกต้อง จะช่วยลดทั้งเวลาโหลด หน้าเว็บลื่นขึ้น และลดการใช้แบนด์วิธได้พร้อมกัน

แนวคิดหลักของ HTTP Caching

HTTP Caching มีแนวคิดสำคัญอยู่ 2 ส่วนที่ทำงานร่วมกัน

1. Freshness

เป็นการกำหนดว่าไฟล์ยังถือว่า "ใหม่พอ" ที่จะใช้จากแคชได้หรือไม่ โดยอาศัย header เช่น

  • Cache-Control
  • Expires

ถ้ายังอยู่ในช่วงเวลาที่กำหนด เบราว์เซอร์จะใช้ไฟล์จากแคชได้ทันทีโดยไม่ต้องถามเซิร์ฟเวอร์อีก

2. Validation

ใช้ในกรณีที่เบราว์เซอร์ไม่แน่ใจว่าไฟล์ยังเป็นเวอร์ชันเดิมหรือไม่ จึงส่งคำขอไปตรวจสอบกับเซิร์ฟเวอร์ผ่าน header เช่น

  • ETag
  • Last-Modified

ถ้าไฟล์ยังไม่เปลี่ยน เซิร์ฟเวอร์จะตอบกลับเป็น 304 Not Modified ซึ่งมีขนาดเล็กและประหยัดกว่าโหลดไฟล์ใหม่ทั้งหมด

ค่าที่เหมาะกับไฟล์ Static

สำหรับไฟล์ static ของเว็บไซต์ส่วนใหญ่ เช่น JS, CSS, รูปภาพ และฟอนต์ มักนิยมตั้งค่าแบบนี้

Cache-Control: public, max-age=31536000, immutable

ความหมายของแต่ละส่วนคือ

  • public อนุญาตให้ทั้งเบราว์เซอร์และ CDN เก็บแคชได้
  • max-age=31536000 กำหนดอายุแคชนาน 1 ปี
  • immutable บอกว่าในช่วงเวลานี้ไม่ต้องตรวจสอบซ้ำ

แนวทางนี้ช่วยลดการร้องขอไฟล์ซ้ำได้มาก เพราะเบราว์เซอร์สามารถใช้ไฟล์ที่มีอยู่แล้วได้ทันที

วิธีแก้ปัญหาเมื่อไฟล์ถูกแก้ไข

หลายคนกังวลว่า หากตั้งแคชไฟล์ static ไว้นานมาก แล้ววันหนึ่งมีการแก้ไขไฟล์ ผู้ใช้จะยังเห็นไฟล์เก่าอยู่หรือไม่ คำตอบคือให้ใช้วิธี cache busting ด้วยชื่อไฟล์ที่มีเวอร์ชันหรือ hash ติดอยู่

ตัวอย่างเช่น

  • app.3f2a9c1.js
  • styles.91b7c0d.css

เมื่อมีการแก้ไขโค้ดและ build ใหม่ ค่า hash จะเปลี่ยน ชื่อไฟล์ก็เปลี่ยนตาม ทำให้เบราว์เซอร์มองว่าเป็นไฟล์ใหม่และโหลดทันที ขณะเดียวกันไฟล์เก่าก็ยังถูกแคชระยะยาวได้โดยไม่กระทบกัน

HTML ควรตั้งค่าไม่เหมือน Static Assets

จุดที่ต้องระวังมากคือไฟล์ HTML เพราะ HTML เป็นไฟล์ที่อ้างอิงไปยัง resource เวอร์ชันล่าสุด หากปล่อยให้ HTML ถูกแคชนานเกินไป อาจทำให้หน้าเว็บยังชี้ไปหาไฟล์เก่าจนเกิดปัญหาได้

ค่าที่นิยมใช้กับ HTML คือ

Cache-Control: no-cache

ค่าดังกล่าวไม่ได้หมายความว่า "ห้ามเก็บ" แต่หมายถึง เก็บได้ แต่ต้องตรวจสอบกับเซิร์ฟเวอร์ก่อนใช้งานทุกครั้ง วิธีนี้ทำให้ยังได้ประโยชน์จากการมีสำเนาในเครื่อง และยังมั่นใจว่าผู้ใช้จะเห็นหน้า HTML เวอร์ชันล่าสุดเสมอ

สิ่งที่มักสับสนคือ

  • no-cache = เก็บได้ แต่ต้อง revalidate ก่อนใช้
  • no-store = ห้ามเก็บเลย

สูตรที่นิยมใช้ในระบบจริง

แนวทางที่ทีมโปรดักชันจำนวนมากใช้งานคือ

  • HTML: Cache-Control: no-cache
  • Static assets เช่น JS/CSS/IMG/Font: Cache-Control: public, max-age=31536000, immutable
  • ใช้ชื่อไฟล์แบบมี hash ทุกครั้ง

สูตรนี้ช่วยให้ HTML อัปเดตได้ทันเสมอ ขณะที่ไฟล์ static ถูกใช้งานจากแคชได้นานที่สุด

Validation Headers ที่ควรเปิดใช้

ถึงแม้จะมีการตั้งค่า freshness แล้ว แต่ validation headers ก็ยังมีบทบาทสำคัญ โดยเฉพาะกับไฟล์หรือหน้าเว็บที่ต้องเช็กความเปลี่ยนแปลง

ETag

ETag ทำหน้าที่เสมือนลายนิ้วมือของไฟล์ เบราว์เซอร์สามารถส่งกลับไปถามเซิร์ฟเวอร์ได้ว่าไฟล์ที่มีอยู่ยังตรงกับเวอร์ชันปัจจุบันหรือไม่ หากยังเหมือนเดิม เซิร์ฟเวอร์จะตอบ 304 Not Modified

Last-Modified

เป็นอีกตัวช่วยที่มีประโยชน์ โดยเฉพาะกับไฟล์ที่อ้างอิงจากระบบไฟล์ เซิร์ฟเวอร์จะระบุเวลาที่แก้ไขล่าสุดไว้ให้เบราว์เซอร์ใช้ตรวจสอบ

ผลลัพธ์ของการใช้ validation ที่ถูกต้องคือ ลดขนาด response ประหยัดแบนด์วิธ และทำให้โหลดหน้าเว็บได้ไวขึ้น

ข้อผิดพลาดที่มือใหม่พลาดบ่อย

การเปิด compression อย่าง gzip หรือ brotli เป็นเรื่องดี แต่ถ้ายังไม่ได้ตั้งค่า caching ก็ยังอาจเกิดการโหลดไฟล์ซ้ำอยู่ดี นอกจากนี้ยังมีข้อผิดพลาดที่พบได้บ่อย เช่น

  1. เปิด gzip หรือ br แล้ว แต่ไม่ได้ตั้ง cache ทำให้ยังร้องขอไฟล์เดิมซ้ำ
  2. ตั้ง max-age ยาวเกินไปกับ HTML จนผู้ใช้ติดหน้าเวอร์ชันเก่า
  3. ใช้ ETag ในระบบหลายเครื่องหลัง load balancer โดยค่าไม่สอดคล้องกัน ทำให้ cache miss บ่อย
  4. มีการส่ง Cache-Control ซ้อนกันจาก CDN หรือ Proxy จนค่าที่ใช้งานจริงไม่ตรงกับที่คิด

วิธีตรวจสอบอย่างรวดเร็ว

สามารถเช็กผลได้ง่ายผ่านเบราว์เซอร์

  1. เปิด DevTools
  2. ไปที่แท็บ Network
  3. รีเฟรชครั้งแรกเพื่อดูการโหลดจริง
  4. รีเฟรชครั้งที่สองแล้วสังเกตผลลัพธ์

สิ่งที่ควรเห็นคือ

  • (disk cache)
  • (memory cache)
  • หรือสถานะ 304

ถ้าเห็นค่าเหล่านี้ แสดงว่าการตั้งค่า caching เริ่มทำงานแล้ว

แล้ว Service Worker จำเป็นไหม

Service Worker ก็สามารถจัดการ cache ได้เช่นกัน และมีความยืดหยุ่นสูงมาก แต่ในหลายกรณี หากตั้งค่า HTTP caching ที่ระดับ header ได้ดีอยู่แล้ว ก็ยังไม่จำเป็นต้องรีบเพิ่มความซับซ้อนด้วย Service Worker

แนวทางที่ดีคือเริ่มจากพื้นฐานให้ถูกก่อน เพราะเพียงแค่ตั้งค่า header ให้เหมาะสมก็มักเห็นผลลัพธ์ชัดเจนทันที

สรุป

การตั้งค่า HTTP Caching อย่างถูกต้องเป็นหนึ่งในวิธีเพิ่มความเร็วเว็บไซต์ที่คุ้มค่าและทำได้ไม่ยาก หลักจำง่ายคือ

  • HTML ควรตั้งให้ revalidate ทุกครั้ง
  • ไฟล์ static ควร cache ยาว 1 ปี และใช้ immutable
  • ทุกไฟล์ที่เปลี่ยนได้ควรใช้ ชื่อไฟล์แบบมี hash

เมื่อทำครบทั้งสามส่วนนี้ เว็บไซต์จะลดการโหลดซ้ำอย่างมีประสิทธิภาพ ผู้ใช้รู้สึกได้ถึงความเร็วที่ดีขึ้น และทีมพัฒนาก็เหมือนได้อัปเกรดประสิทธิภาพระบบแบบไม่ต้องลงทุนเพิ่มมากนัก