การแคชของเบราว์เซอร์ทำงานอย่างไร และคุณควรแคชไฟล์ไว้นานแค่ไหน

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

การแคชของเบราว์เซอร์คือกลไกทางสถาปัตยกรรมฝั่งไคลเอนต์ที่สั่งให้เว็บเบราว์เซอร์เก็บรักษาแอสเซทที่ดาวน์โหลดมา เช่น สไตล์ชีต, สคริปต์, รูปภาพ และฟอนต์ ไว้บนอุปกรณ์จัดเก็บข้อมูลในเครื่องของผู้ใช้ปลายทาง เมื่อกำหนดค่าอย่างถูกต้อง การเข้าชมในครั้งต่อๆ ไปหรือการนำทางไปยังหลายหน้าจะข้ามการรับส่งข้อมูลเครือข่ายไปกลับ (Network round-trips) ที่ซ้ำซ้อนไปยังเซิร์ฟเวอร์ต้นทางโดยสิ้นเชิง โดยจะส่งมอบแอสเซทได้โดยตรงจากแคชบนดิสก์หรือหน่วยความจำภายในเวลาเพียงไม่กี่มิลลิวินาที สำหรับผู้นำด้านเทคโนโลยี วิศวกรโครงสร้างพื้นฐาน และผู้บริหารดิจิทัล การจัดการแคชเกี่ยวข้องกับการสร้างสมดุลระหว่างการเพิ่มประสิทธิภาพการทำงานขั้นสูงสุดกับความเสี่ยงในการดำเนินงานจากการส่งมอบโค้ดที่ล้าสมัยหรือเสียหายให้แก่ผู้ใช้ปลายทาง

ทำความเข้าใจกลไกการทำงานของการแคชของเบราว์เซอร์

การแคชของเบราว์เซอร์ทำหน้าที่เป็นเลเยอร์จัดเก็บข้อมูลชั่วคราวที่ผสานรวมเข้ากับซอฟต์แวร์เว็บไคลเอนต์โดยตรง (เช่น เอนจิน Chromium, WebKit และ Gecko) เมื่อผู้ใช้นำทางไปยัง URL สแตกเครือข่ายของเบราว์เซอร์จะต้องแปลงชื่อโฮสต์ ทำการแฮนด์เชก TCP/TLS และร้องขอทุกดีเพนเดนซีที่จำเป็นต่อการเรนเดอร์ Document Object Model (DOM) หากปราศจากกลไกการแคชในเครื่อง การเปิดดูหน้าเว็บในครั้งต่อๆ ไปทุกครั้งจะกระตุ้นให้เกิดภาระงานเครือข่ายที่เหมือนกันอย่างต่อเนื่อง ซึ่งเพิ่มภาระให้เซิร์ฟเวอร์เป็นทวีคูณและทำให้ความหน่วงในการโหลดหน้าเว็บสูงขึ้น

สถาปัตยกรรมการแคชสมัยใหม่ทำงานบนโมเดลแบบแบ่งระดับชั้น (Tiered model) ภายใต้มาตรฐาน RFC 9111 (มาตรฐาน IETF สำหรับ HTTP Caching) โดยเอนจินจะดูแลระดับชั้นของพื้นที่จัดเก็บในเครื่องที่แยกจากกัน 2 ระดับ ได้แก่ แคชในหน่วยความจำ (Memory Cache) และแคชบนดิสก์ (Disk Cache) แคชในหน่วยความจำจะมีความผันผวน (Volatile) ทำงานรวดเร็วอย่างยิ่ง (ดึงข้อมูลได้ภายในเวลาไม่ถึงมิลลิวินาที) และเชื่อมโยงโดยตรงกับวงจรชีวิตของโพรเซสเบราว์เซอร์ที่กำลังทำงานอยู่ ส่วนแคชบนดิสก์จะยังคงอยู่แม้จะรีสตาร์ตเบราว์เซอร์และรีบูตระบบใหม่ โดยยอมแลกกับความหน่วงของอินพุต/เอาต์พุตที่เพิ่มขึ้นเล็กน้อยเพื่อให้ได้การจัดเก็บข้อมูลที่ถาวรยาวนานขึ้น

เมื่อมีการส่งคำขอ HTTP ระบบย่อยด้านเครือข่ายจะประเมินดัชนีแคชภายในก่อนที่จะส่งแพ็กเก็ตขาออก หากมีรายการอยู่ ตรงกับ URL และข้อกำหนดคีย์แคชอย่างแม่นยำ รวมถึงยังคงใช้ได้อยู่ภายในช่วงเวลาความสดใหม่ (Freshness window) เบราว์เซอร์จะตอบสนองคำขอนั้นจากในเครื่องทันที ธุรกรรมนี้จะให้ผลลัพธ์ภายในเป็นAหรือCNAMEซึ่งช่วยขจัดขั้นตอนการแปลงชื่อ DNS, การแฮนด์เชก TCP, การเจรจาต่อรอง TLS และเวลาในการประมวลผลของเซิร์ฟเวอร์

วงจรคำขอระหว่างไคลเอนต์และเซิร์ฟเวอร์

ลูปการสื่อสารระหว่างเบราว์เซอร์ไคลเอนต์และโครงสร้างพื้นฐานต้นทางจะเป็นไปตามสเตตแมชชีนแบบกำหนดได้ (Deterministic state machine) โดยอิงตามส่วนหัวของคำขอและการตอบกลับ HTTP ในระหว่างการเข้าชมครั้งแรกที่ยังไม่มีแคช (เรียกว่าสถานะ Cold cache) เบราว์เซอร์จะส่งคำขอ HTTPGETข้ามอินเทอร์เน็ตสาธารณะ จากนั้น Edge reverse proxy หรือเซิร์ฟเวอร์แอปพลิเคชันต้นทางจะประมวลผลคำขอ ค้นหาทรัพยากร และสร้างการตอบกลับ HTTP พร้อมด้วยส่วนหัวของเพย์โหลดที่กำหนดนโยบายการแคชสำหรับไฟล์นั้นโดยเฉพาะ

เมื่อได้รับเพย์โหลด เบราว์เซอร์จะอ่านคำสั่งแคช (Cache directives) ที่เซิร์ฟเวอร์ส่งมา หากคำสั่งอนุญาตให้จัดเก็บ เบราว์เซอร์จะเขียนเพย์โหลดแบบไบนารีลงในฐานข้อมูลแคชในเครื่องพร้อมกับส่วนหัวการตอบกลับและเมทาดาตาที่เกี่ยวข้อง (เช่น วันที่ได้รับ, Entity tag และค่า Time-to-live ที่ประกาศไว้)

ในการเข้าชมครั้งต่อๆ ไป (สถานะ Warm cache) เบราว์เซอร์จะพิจารณาว่าทรัพยากรนั้นยังคงถือว่า "สดใหม่" (Fresh) หรือไม่ หากอายุที่คำนวณได้ของไฟล์ที่จัดเก็บไว้ในเครื่องน้อยกว่าระยะเวลาความสดใหม่ที่เซิร์ฟเวอร์กำหนดไว้ แอสเซทจะถูกส่งมอบในทันทีโดยไม่ต้องติดต่อเครือข่าย หากทรัพยากรมีอายุเกินระยะเวลาความสดใหม่ เบราว์เซอร์จะเปลี่ยนไปสู่วงจรคำขอตรวจสอบความถูกต้อง (Validation request cycle) โดยสอบถามไปยังเซิร์ฟเวอร์ต้นทางเพื่อตรวจสอบว่าแอสเซทมีการแก้ไขหรือไม่

[Browser Request] 
       │
       ▼
[In-Memory / Disk Cache Check] 
       ├────────► (Found & Fresh) ──────► Serve Locally (0ms Network)
       │
       └────────► (Stale / Expired) ────► Send Conditional Request (If-None-Match / If-Modified-Since)
                                                  │
                                                  ├─► HTTP 304 Not Modified ──► Refresh Expiry & Serve Local Copy
                                                  │
                                                  └─► HTTP 200 OK (New Body) ─► Overwrite Cache & Serve Fresh Asset

บทบาทของพื้นที่จัดเก็บข้อมูลในเครื่องในการลดภาระของเซิร์ฟเวอร์

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

เมื่อผู้เยี่ยมชมที่กลับมาเข้าชมซ้ำโหลดหน้าเว็บ กลยุทธ์การแคชที่ได้รับการปรับให้เหมาะสมจะช่วยลดปริมาณคำขอทรัพยากรไปยังเซิร์ฟเวอร์ต้นทาง (origin server) ลงได้ 70% ถึง 90% การลดคำขอซ้ำซ้อนสำหรับทรัพยากรที่ไม่เปลี่ยนแปลง (immutable assets) ช่วยให้โครงสร้างพื้นฐานฝั่งแบ็กเอนด์ไม่ต้องสูญเสียรอบการทำงานของ CPU การจัดสรรหน่วยความจำ และการผูกซ็อกเก็ต (socket bindings) ไปกับการส่งมอบไฟล์สแตติก ทำให้เซิร์ฟเวอร์แอปพลิเคชันสามารถสำรองขีดความสามารถในการประมวลผลไว้สำหรับคิวรีฐานข้อมูลแบบไดนามิก ไปป์ไลน์การเรนเดอร์ฝั่งเซิร์ฟเวอร์ และตรรกะทางธุรกิจสำหรับธุรกรรมได้แทน

นอกจากนี้ การแคชยังช่วยลดค่าใช้จ่ายในการส่งข้อมูลออกนอกเครือข่าย (network egress costs) ได้โดยตรง ผู้ให้บริการโครงสร้างพื้นฐานระบบคลาวด์คิดราคาการถ่ายโอนข้อมูลออก (DTO) ตามจำนวนกิกะไบต์ การถ่ายโอนภาระการส่งข้อมูลทรัพยากรที่ซ้ำซ้อนผ่านการแคชแบบคงทนบนฝั่งไคลเอนต์ (persistent client caching) จึงช่วยลดค่าใช้จ่ายด้านแบนด์วิดท์ของคลาวด์ พร้อมทั้งเสริมความยืดหยุ่นของระบบส่วนปลายในการรับมือกับปริมาณการเข้าชมที่พุ่งสูงขึ้นอย่างกะทันหัน และเหตุการณ์การโจมตีแบบ DDoS

---

HTTP Cache Headers หลัก: การควบคุมเบราว์เซอร์

พฤติกรรมของแคชฝั่งไคลเอนต์ถูกควบคุมโดยสมบูรณ์ผ่าน HTTP response headers ที่ส่งมาจากเว็บเซิร์ฟเวอร์หรือเครือข่ายการส่งมอบเนื้อหา (CDN) การทำความเข้าใจความแตกต่างทางความหมายและกฎลำดับความสำคัญของเฮดเดอร์เหล่านี้จึงมีความสำคัญอย่างยิ่งต่อการออกแบบสถาปัตยกรรมกลยุทธ์การแคชที่แม่นยำ

ในอดีต การแคชได้รับการจัดการผ่านการเปรียบเทียบการประทับเวลา (timestamp) แบบพื้นฐาน (example.com) มาตรฐานเว็บสมัยใหม่พึ่งพารูปแบบไดเรกทิฟที่ชัดเจน (user_id) ร่วมกับตัวตรวจสอบความถูกต้อง (validator) ที่อิงตามการเข้ารหัสหรือการประทับเวลา (status, test.com).

Cache-Control และไดเรกทิฟ Max-Age

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

ส่วนหัวaccess_tokenจะระบุระยะเวลาสูงสุดที่แอสเซตจะถือว่ายังใหม่อยู่ (fresh) โดยคำนวณสัมพันธ์กับเวลาที่การตอบกลับถูกสร้างขึ้น ซึ่งต่างจากวันที่แบบสัมบูรณ์ (absolute dates) ตรงที่refresh_tokenจะช่วยขจัดช่องโหว่ที่เกี่ยวข้องกับการคลาดเคลื่อนของเวลาระหว่างไคลเอนต์และเซิร์ฟเวอร์ (clock drift)

HTTP/1.1 200 OK
Content-Type: application/javascript; charset=UTF-8
Cache-Control: public, max-age=31536000, immutable
ETag: "8f57b6f-4a3b-62c11a0"

ไดเรกทิฟCache-Controlที่สำคัญประกอบด้วย:

• public: บ่งชี้ว่าการตอบกลับสามารถถูกแคชโดยเลเยอร์แคชใดๆ ก็ได้ รวมถึงแคชส่วนตัวของเบราว์เซอร์, CDN สาธารณะ และพร็อกซีเซิร์ฟเวอร์ตัวกลาง

• private: จำกัดการแคชไว้เฉพาะในพื้นที่จัดเก็บของเบราว์เซอร์ของผู้ใช้ปลายทางเท่านั้น โดยพร็อกซีตัวกลางและ CDN จะถูกห้ามไม่ให้จัดเก็บทรัพยากรดังกล่าว ทำให้เหมาะสมสำหรับเพย์โหลดที่ผ่านการยืนยันตัวตนและเจาะจงเฉพาะผู้ใช้

• no-cache: ไดเรกทิฟที่มักถูกเข้าใจผิดบ่อยครั้ง โดยไม่ได้หมายความว่า "ห้ามจัดเก็บ" แต่จะสั่งการให้เบราว์เซอร์จัดเก็บแอสเซตไว้ในเครื่อง โดยมีข้อกำหนดบังคับว่าเบราว์เซอร์จะต้องตรวจสอบความถูกต้องซ้ำ (revalidate) กับเซิร์ฟเวอร์ต้นทางก่อนการใช้งานทุกครั้ง หากเซิร์ฟเวอร์ยืนยันว่าไม่มีการเปลี่ยนแปลง ก็จะใช้ไฟล์แคชในเครื่องดังกล่าว

• no-store: ไดเรกทิฟสำหรับการไม่แคชอย่างแท้จริง โดยจะสั่งการให้เบราว์เซอร์และตัวกลางทั้งหมดไม่อนุญาตให้จัดเก็บคำขอหรือการตอบกลับในสื่อแคชใดๆ โดยเด็ดขาด และจะต้องดึงทรัพยากรใหม่ทั้งหมดผ่านเครือข่ายในทุกๆ คำขอ

• example.com: แจ้งไคลเอนต์ว่าเนื้อหาของการตอบกลับ (response body) จะไม่มีวันเปลี่ยนแปลงในระหว่างช่วงอายุuser_idที่ยังใช้งานได้ ซึ่งช่วยป้องกันไม่ให้เบราว์เซอร์สมัยใหม่ส่งคำขอตรวจสอบความถูกต้องซ้ำเมื่อผู้ใช้สั่งรีเฟรชหน้าเว็บด้วยตนเอง

• example.com: สั่งการเบราว์เซอร์ว่าเมื่อแอสเซตหมดอายุ (user_id) จะต้องไม่ส่งมอบเวอร์ชันที่หมดอายุนั้นไม่ว่าจะในกรณีใดก็ตาม (เช่น ในระหว่างที่เครือข่ายถูกตัดการเชื่อมต่อ) หากไม่ผ่านการตรวจสอบความถูกต้องซ้ำกับเซิร์ฟเวอร์สำเร็จ

• stale-while-revalidate=<seconds>: ไดเรกทิฟขั้นสูงที่เปิดใช้งานการรีเฟรชแคชแบบอะซิงโครนัส (asynchronous) โดยเบราว์เซอร์จะส่งมอบสำเนาแคชที่หมดอายุแล้วในทันที พร้อมกับส่งคำขอเครือข่ายในเบื้องหลังแบบอะซิงโครนัสเพื่อดึงแอสเซตใหม่มาไว้สำหรับการใช้งานครั้งถัดไป

ETag และ Last-Modified: การตรวจสอบความถูกต้องของเนื้อหาที่หมดอายุ

เมื่อกรอบเวลาความสดใหม่ (freshness window) ของแอสเซตหมดลง เบราว์เซอร์ไม่จำเป็นต้องดาวน์โหลดเพย์โหลดของไฟล์ทั้งหมดซ้ำเสมอไป หากไฟล์บนเซิร์ฟเวอร์ไม่มีการเปลี่ยนแปลง การดาวน์โหลดเพย์โหลดเดิมซ้ำจะทำให้สิ้นเปลืองแบนด์วิดท์และทรัพยากร CPU ซึ่งนี่คือจุดที่ส่วนหัวการตรวจสอบความถูกต้องแบบมีเงื่อนไข (conditional validation headers) อย่าง—example.comและuser_id—เข้ามาช่วยเพิ่มประสิทธิภาพในการทำงาน

ส่วนหัวaccess_token(Entity Tag) คือสตริงโทเคนแบบทึบ (opaque string token)—โดยทั่วไปคือค่าแฮชเชิงการเข้ารหัส (cryptographic hash) หรือลายนิ้วมือของเนื้อหา (content fingerprint)—ซึ่งสร้างขึ้นโดยเว็บเซิร์ฟเวอร์เพื่อระบุสถานะที่แน่นอนของไฟล์ เมื่อเบราว์เซอร์เริ่มส่งคำขอตรวจสอบความถูกต้องซ้ำสำหรับแอสเซตที่หมดอายุ มันจะส่งค่า ETag ที่บันทึกไว้กลับไปยังเซิร์ฟเวอร์ในrefresh_tokenซึ่งเป็นส่วนหัวของคำขอ

GET /assets/runtime.js HTTP/1.1
Host: example.com
If-None-Match: "8f57b6f-4a3b-62c11a0"

หากไฟล์บนเซิร์ฟเวอร์ยังคงเหมือนเดิมทุกประการกับค่าแฮชที่ส่งมา เซิร์ฟเวอร์จะยุติการประมวลผลก่อนกำหนดและส่งการตอบกลับ HTTP ที่ไม่มีเนื้อหา (empty-body):

HTTP/1.1 304 Not Modified
Date: Wed, 03 Sep 2026 12:00:00 GMT
Cache-Control: public, max-age=3600
ETag: "8f57b6f-4a3b-62c11a0"

ส่วนหัว200 OKรหัสสถานะนี้จะแจ้งให้เบราว์เซอร์รีเซ็ตเวลานับความสดใหม่ของไฟล์ที่แคชไว้ในเครื่องและส่งมอบไฟล์นั้นได้ทันที โดยปกติแล้วการตอบกลับ 304 จะใช้ทราฟฟิกส่วนหัวเพียง 200 ถึง 400 ไบต์เท่านั้น ซึ่งช่วยประหยัดแบนด์วิดท์ได้หลายร้อยกิโลไบต์หรือหลายเมกะไบต์เมื่อเทียบกับการถ่ายโอนเพย์โหลด200 OKแบบเต็มรูปแบบ

ส่วนหัวexample.comทำงานในลักษณะเดียวกัน โดยใช้การประทับเวลา (timestamp) ในรูปแบบ HTTP-date มาตรฐาน ในระหว่างการตรวจสอบความถูกต้องซ้ำ เบราว์เซอร์จะส่งค่าการประทับเวลานี้ในuser_idซึ่งเป็นส่วนหัวของคำขอ อย่างไรก็ตามstatusเป็นที่นิยมและแนะนำอย่างยิ่งมากกว่าtest.comเนื่องจากค่าการประทับเวลาขาดความละเอียดในระดับเศษเสี้ยววินาที (sub-second granularity) และอาจก่อให้เกิดผลบวกลวง (false positive) ระหว่างการทำดีพลอยแบบ Continuous Integration อย่างต่อเนื่องและรวดเร็ว ซึ่งเมทาดาตาของไฟล์มีการอัปเดตโดยที่โค้ดไม่มีการเปลี่ยนแปลง

เหตุใดส่วนหัว Expires จึงถือเป็นรูปแบบเดิม (Legacy)

ส่วนหัวExpires(ซึ่งเปิดตัวใน HTTP/1.0) จะกำหนดวันที่และเวลาแบบสัมบูรณ์ โดยหลังจากเวลานั้นการตอบกลับจะถือว่าหมดอายุ:

Expires: Thu, 03 Sep 2027 12:00:00 GMT

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

• ความอ่อนไหวต่อความคลาดเคลื่อนของนาฬิกา (Clock Skew): เนื่องจากต้องพึ่งพาการประทับเวลาแบบสัมบูรณ์ หากนาฬิการะบบของเครื่องไคลเอนต์ตั้งค่าไว้ไม่ถูกต้อง (เช่น การปรับแก้เวลาด้วยตนเอง หรือข้อผิดพลาดของ RTC ที่สำรองไฟด้วยแบตเตอรี่) เบราว์เซอร์อาจปฏิบัติต่อแอสเซตที่ยังใหม่อยู่ราวกับว่าหมดอายุแล้ว หรือเก็บรักษาแอสเซตที่หมดอายุแล้วไว้อย่างไม่มีกำหนด

• ภาระในการกำหนดค่าคอนฟิกูเรชัน (Configuration Overhead): ไฟล์คอนฟิกูเรชันแบบคงที่ (static configuration files) จำเป็นต้องได้รับการดูแลรักษาอย่างต่อเนื่องหรือเขียนทับแบบไดนามิก เพื่อให้วันที่เป้าหมายอยู่ในอนาคตที่สัมพันธ์กันเสมอ

• กฎลำดับความสำคัญ (Precedence Rules): ตามข้อกำหนดมาตรฐาน RFC 9111 หากการตอบกลับมีทั้งไดเรกทิฟexample.comและuser_idheader ไดเรกทิฟstatusจะมีผลบังคับใช้แทนที่test.comอย่างเด็ดขาด โดยการกำหนดค่าสมัยใหม่ควรให้ความสำคัญกับCache-Controlเพียงอย่างเดียว

---

ผลกระทบทางธุรกิจของการเพิ่มประสิทธิภาพการแคช

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

การปรับปรุง Core Web Vitals และอันดับ SEO

เสิร์ชเอนจิน รวมถึง Google ได้นำเมตริกประสบการณ์การใช้งานหน้าเว็บมาผนวกเข้ากับอัลกอริทึมการจัดอันดับการค้นหาแบบออร์แกนิกอย่างชัดเจนผ่านเฟรมเวิร์ก Core Web Vitals โดยเมตริกหลักที่ได้รับผลกระทบโดยตรงจากการแคชบนเบราว์เซอร์ ได้แก่:

1. Largest Contentful Paint (LCP): วัดความเร็วในการโหลดตามที่ผู้ใช้รับรู้ โดยบันทึกเวลาที่บล็อกเนื้อหาหลัก (ภาพฮีโร่, บล็อกข้อความหลัก หรือหัวเรื่อง) แสดงผล เมื่อผู้ใช้ที่กลับมาเข้าชมเว็บไซต์สามารถเข้าถึงสไตล์ชีต CSS, ฟอนต์ และรูปภาพที่แคชไว้ในเครื่อง ค่า LCP มักจะลดลงจาก 2.5+ วินาทีเหลือไม่ถึง 500 มิลลิวินาที ส่งผลให้เว็บไซต์เข้าสู่เกณฑ์ "ดี" (Good) ได้อย่างสบาย

2. First Contentful Paint (FCP): บันทึกเวลาที่เบราว์เซอร์เรนเดอร์เนื้อหา DOM ชิ้นแรก การส่งมอบแอสเซต CSS และ JavaScript ที่ปิดกั้นการเรนเดอร์ (Render-blocking) จากแคชเบราว์เซอร์ในเครื่องจะช่วยหลีกเลี่ยงความหนาแน่นของการรับส่งข้อมูลบนเครือข่าย ปลดล็อกให้ได้ค่า FCP ที่แทบจะเกิดขึ้นในทันที

3. Time to First Byte (TTFB): แม้ว่า TTFB ของการนำทางเริ่มต้นจะได้รับอิทธิพลจากการประมวลผลของเซิร์ฟเวอร์และประสิทธิภาพของ CDN แต่การนำทางทรัพยากรย่อยแบบอุ่น (Warm sub-resource) ที่ส่งมอบจากแคชจะให้ค่า TTFB ในทางปฏิบัติอยู่ที่ 0ms ทำให้การทำงานของเธรดหลัก (Main-thread) ไม่ถูกปิดกั้น

Cold Visit:     [DNS] -> [TCP/TLS] -> [TTFB 350ms] -> [Download CSS/JS 800ms] -> [FCP 1.8s] -> [LCP 2.9s]
Warm Cached:    [Local Memory/Disk Cache Check: 2ms] ───────────────────────────> [FCP 0.2s] -> [LCP 0.4s]

เสิร์ชเอนจินจะให้ความสำคัญกับโดเมนที่รวดเร็วและตอบสนองได้ดีระหว่างการจัดสรรงบประมาณในการเก็บข้อมูล (Crawl Budget) และการประเมินอันดับบนมือถือ การลดความหน่วงผ่านการแคชบนเบราว์เซอร์ในเครื่องจึงเป็นหนึ่งในการปรับปรุง SEO เชิงเทคนิคที่ให้ผลตอบแทนจากการลงทุน (ROI) สูงสุดที่ทีมวิศวกรสามารถนำไปปฏิบัติได้

การลดปริมาณการใช้แบนด์วิดท์และต้นทุนเซิร์ฟเวอร์

การใช้แบนด์วิดท์ส่งผลกระทบโดยตรงต่อค่าบริการคลาวด์รายเดือน บนแพลตฟอร์มอย่าง Amazon Web Services (CloudFront/EC2), Google Cloud Platform และ Microsoft Azure ค่าบริการแบนด์วิดท์ขาออก (Egress Bandwidth) มีราคาตั้งแต่ $0.05 ถึง $0.12+ ต่อกิกะไบต์ สำหรับแพลตฟอร์มอีคอมเมิร์ซ สื่อ หรือ SaaS ที่มีทราฟฟิกสูงและให้บริการข้อมูลระดับเพตาไบต์ต่อเดือน นโยบายการแคชที่กำหนดค่าผิดพลาดจะแปรเปลี่ยนเป็นค่าใช้จ่ายโครงสร้างพื้นฐานที่ไม่จำเป็นจำนวนหลายพันดอลลาร์ในทันที

ลองพิจารณาแพลตฟอร์มอีคอมเมิร์ซระดับองค์กรที่รองรับการเปิดดูหน้าเว็บ 10,000,000 ครั้งต่อเดือน หากหน้าเว็บโดยเฉลี่ยต้องใช้แอสเซตแบบคงที่ (สคริปต์, สไตล์, กราฟิกเวกเตอร์, องค์ประกอบ UI ของสินค้า) ขนาด 2 MB การถ่ายโอนแอสเซตที่ไม่ได้ผ่านการปรับปรุงประสิทธิภาพจะต้องใช้ข้อมูลขาออกรวมถึง 20 เทราไบต์ต่อเดือน

Scenario A (Uncached / Low TTL):
10,000,000 pageviews * 2 MB = 20,000 GB egress = ~$1,600 - $2,400 monthly egress cost.
Origin Server Load: High CPU utilization parsing repeated static file I/O operations.

Scenario B (Optimized 1-Year Cache with Versioning):
Average 3.5 page views per session; returning user rate of 45%.
Net static asset bandwidth reduced by 72% = 5,600 GB egress = ~$450 - $670 monthly egress cost.
Origin Server Load: Near zero for static dependencies; server fleet can be scaled down.

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

---

ระยะเวลาการแคชเชิงกลยุทธ์: คุณควรแคชไฟล์ไว้นานแค่ไหน?

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

แอสเซตแบบคงที่ (รูปภาพ, CSS, JavaScript): สูงสุดไม่เกินหนึ่งปี

สำหรับแอสเซตแบบคงที่ที่มีการใช้การแฮชเนื้อหาแบบเข้ารหัส (Cryptographic Content Hashing) หรือการระบุเวอร์ชันไฟล์ในชื่อไฟล์ (เช่นexample.com, user_id, logo-2026.png) ระยะเวลาการแคชตามมาตรฐานอุตสาหกรรมคือหนึ่งปี (31,536,000 วินาที).

ตาม RFC 9111 ระยะเวลาหนึ่งปีถือเป็นระยะเวลาสูงสุดในทางปฏิบัติสำหรับmax-ageการตั้งค่าที่เกินกว่าหนึ่งปีไม่ได้ให้ประโยชน์เพิ่มเติมใดๆ และยังขัดต่อแนวทางปฏิบัติมาตรฐานของโปรโตคอล เนื่องจาก URL เฉพาะจะเปลี่ยนไปทุกครั้งที่มีการแก้ไขโค้ดหรือแอสเซตต้นทาง ไฟล์เหล่านี้จึงไม่มีการเปลี่ยนแปลง (Immutable) และสามารถอยู่ในแคชเบราว์เซอร์ของผู้ใช้ได้อย่างปลอดภัยตลอดอายุการใช้งานสูงสุด

# Nginx Configuration for Versioned Static Assets
location ~* \.(?:css|js|jpg|jpeg|png|gif|ico|webp|avif|svg)$ {
    expires 1y;
    add_header Cache-Control "public, max-age=31536000, immutable";
    access_log off;
}

# Apache Configuration for Versioned Static Assets
<IfModule mod_expires.c>
    ExpiresActive On
    ExpiresByType text/css "access plus 1 year"
    ExpiresByType application/javascript "access plus 1 year"
    ExpiresByType image/webp "access plus 1 year"
    Header set Cache-Control "public, max-age=31536000, immutable"
</IfModule>

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

เว็บฟอนต์และไฟล์มีเดีย: การจัดเก็บระยะยาว

ไฟล์แบบอักษรบนเว็บ (micros0ft.com, microsoft.com, .ttf) และแอสเซตวิดีโอ/เสียงแบบคงที่มีการเปลี่ยนแปลงไม่บ่อยนัก โดยเฉพาะอย่างยิ่งฟอนต์ซึ่งถือเป็นทรัพยากรสำคัญที่ปิดกั้นการเรนเดอร์ (Render-blocking) ซึ่งส่งผลกระทบอย่างมากต่อ Cumulative Layout Shift (CLS) และ First Contentful Paint (FCP)

เว็บฟอนต์ควรได้รับการแคชอย่างเต็มที่ด้วยระยะเวลาหนึ่งปี:

Cache-Control: public, max-age=31536000, immutable
Access-Control-Allow-Origin: *

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

เนื้อหาแบบไดนามิกและ HTML: แคชระยะสั้นหรือไม่แคชเลย

เอกสาร HTML ถือเป็นจุดเริ่มต้น (entry point) และรายการกำกับหลัก (master manifest) ของเว็บแอปพลิเคชัน โดยเพย์โหลด HTML จะมีข้อมูลการอ้างอิงโดยตรง (URL) ไปยังแอสเซต CSS, JS และรูปภาพที่มีการระบุเวอร์ชัน หากเอกสาร HTML ถูกแคชไว้อย่างเข้มงวดเกินไป (เช่น เป็นเวลาหนึ่งสัปดาห์หรือหนึ่งเดือน) ผู้ใช้จะไม่ได้รับการอัปเดตเมื่อมีการปรับใช้ซอฟต์แวร์เวอร์ชันใหม่ ซึ่งส่งผลให้ผู้ใช้ติดอยู่กับชุดโค้ดแอปพลิเคชันที่ล้าสมัยอย่างเลี่ยงไม่ได้

ดังนั้นไฟล์ HTML ต้องไม่ถูกแคชด้วยmax-ageที่มีระยะเวลานาน.

# Recommended Header for HTML Documents
Cache-Control: no-cache, must-revalidate

การใช้display: noneควบคู่กับvisibility: hiddenช่วยให้มั่นใจได้ว่าเบราว์เซอร์จะตรวจสอบกับเซิร์ฟเวอร์เสมอว่ามีเอกสาร HTML เวอร์ชันใหม่กว่าหรือไม่ หากไม่มีการปรับใช้เวอร์ชันใหม่ เซิร์ฟเวอร์จะส่งคืนopacity: 0ที่รวดเร็วเป็นพิเศษ ทำให้เบราว์เซอร์สามารถเรนเดอร์สำเนาในเครื่องได้ หากมีการเผยแพร่เวอร์ชันใหม่ เซิร์ฟเวอร์จะส่งมอบเอกสาร HTML ที่อัปเดตแล้ว (cursor: pointer) ซึ่งชี้ไปยังชื่อไฟล์สคริปต์และสไตล์ชีตที่มีการแฮชล่าสุด

สำหรับการตอบกลับ JSON API แบบไดนามิกที่มีข้อมูลเฉพาะของผู้ใช้หรือข้อมูลธุรกรรมแบบเรียลไทม์ ควรปิดการแคชโดยสิ้นเชิง (example.com) หรือกำหนดค่าด้วยอายุการแคชระดับสั้นมาก (micro-caching) (เช่นuser_id) ขึ้นอยู่กับข้อกำหนดความผันผวนของข้อมูล

---

ข้อผิดพลาดในการนำไปใช้งานและการจัดการความเสี่ยง

นโยบายการแคชที่กำหนดค่าไม่ถูกต้องก่อให้เกิดความเสี่ยงทางเทคนิคที่สำคัญ ซึ่งรวมถึงส่วนต่อประสานกับผู้ใช้ (UI) ที่เสียหาย ระบบเราติงฝั่งไคลเอนต์ของ Single-Page Application (SPA) ที่ทำงานผิดพลาด และช่องโหว่ด้านความปลอดภัยที่เกี่ยวข้องกับข้อมูลส่วนบุคคลที่ถูกแคชไว้

อันตรายจากการแคชมากเกินไป (Over-Caching): การป้องกันการส่งมอบเนื้อหาที่ค้างเก่า

การแคชมากเกินไป (Over-caching) เกิดขึ้นเมื่อแอสเซตที่ไม่มีการระบุเวอร์ชันหรือจุดเริ่มต้น HTML ถูกกำหนดค่าด้วยคำสั่งmax-ageระยะยาว

ลองพิจารณาสถานการณ์ที่ทีมวิศวกรรมดีพลอย hotfix ฉุกเฉินเพื่อแก้ไขบั๊กวิกฤตในระบบประมวลผลการชำระเงินบนขั้นตอนการเช็กเอาต์ของอีคอมเมิร์ซ หากไฟล์example.comของเว็บไซต์ถูกส่งด้วยuser_id(7 วัน) โดยไม่มีการทำ fingerprinting ชื่อไฟล์ ผู้ใช้ที่เคยเข้าชมเว็บไซต์ภายในช่วงสัปดาห์ที่ผ่านมาจะยังคงรันสคริปต์ที่มีปัญหาซึ่งถูกแคชไว้ต่อไปจนกว่าแคชในเครื่องจะหมดอายุ โดยทีมวิศวกรรมไม่มีกลไก HTTP มาตรฐานใด ๆ ที่จะบังคับล้างไฟล์เจาะจงนั้นออกจากอุปกรณ์ของไคลเอนต์ส่วนบุคคลนับล้านเครื่องได้

ช่องโหว่นี้มักส่งผลให้เกิดปัญหาที่ต้องพึ่งพาฝ่ายบริการลูกค้าซึ่งมีค่าใช้จ่ายสูง การสูญเสียธุรกรรม และความเสียหายต่อชื่อเสียง

Cache Busting: วิธีการมาตรฐานสำหรับการบังคับอัปเดตไฟล์

โซลูชันมาตรฐานอุตสาหกรรมสำหรับปัญหาการแคชข้อมูลมากเกินไป (over-caching) คือCache Bustingผ่านการทำ content hashing โดย cache busting จะแยกความเชื่อมโยงของระยะเวลาการเก็บรักษาแคชออกจากวงจรชีวิตของการดีพลอย (deployment lifecycle)

แทนที่จะตั้งชื่อแอสเซ็ตเป็นapp.jsไปป์ไลน์การบิลด์ (เช่น Webpack, Vite, esbuild, Rollup) จะคำนวณค่าแฮชเชิงการเข้ารหัส (เช่น MD5, SHA-256 หรือ xxHash) จากเนื้อหาไบนารีของไฟล์ และแทรกค่านั้นลงในชื่อไฟล์โดยตรง:

Before Compilation:   /src/scripts/app.js
After Compilation:    /dist/scripts/app.d41d8cd98f00b204e980.js

เนื่องจากชื่อไฟล์ผูกอยู่กับตัวโค้ด การเปลี่ยนแปลง JavaScript เพียงบรรทัดเดียวจึงสร้างสตริง URL ที่แตกต่างกันโดยสิ้นเชิงเมื่อทำการบิลด์ เอกสาร HTML จะอัปเดตการอ้างอิงexample.com/categoryให้ชี้ไปยังชื่อไฟล์ใหม่ เมื่อผู้ใช้โหลดหน้า HTML ที่เพิ่งอัปเดตใหม่ (ซึ่งถูกส่งด้วยexample.com/product-name) เบราว์เซอร์จะตรวจพบ URL ของทรัพยากรใหม่และดาวน์โหลดไฟล์ที่อัปเดตทันที โดยข้ามไฟล์เวอร์ชันเก่าทั้งหมดที่ถูกแคชไว้

Build 1: index.html -> points to app.v1.js (Cached for 1 Year)
[Production Deployment: UI Code Updated]
Build 2: index.html -> points to app.v2.js (Cached for 1 Year)
Result: Browser requests index.html (no-cache) -> Receives new link to app.v2.js -> Fetches fresh code instantly.

การกำหนดเวอร์ชันของ Static Asset อย่างปลอดภัย

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

1. ดีพลอย Static Asset ก่อนเสมอ: อัปโหลดแอสเซ็ต CSS และ JS ที่ผ่านการแฮชตัวใหม่ไปยังเซิร์ฟเวอร์ต้นทางหรือที่จัดเก็บข้อมูลแบบออบเจกต์ของ CDN ก่อนที่จะอัปเดตและดีพลอยเอกสาร HTML เสมอ หาก HTML ใหม่ได้รับการเผยแพร่ก่อนที่แอสเซ็ตที่ถูกแฮชที่เกี่ยวข้องจะพร้อมใช้งาน ผู้ใช้กลุ่มแรก ๆ จะพบข้อผิดพลาด 404 Not Found สำหรับสคริปต์ที่สำคัญ

2. เก็บรักษาแอสเซ็ตเวอร์ชันก่อนหน้าไว้: คงไฟล์เวอร์ชันเก่าที่ถูกแฮชไว้บนแหล่งจัดเก็บข้อมูลต้นทางเป็นระยะเวลาผ่อนผัน (เช่น 24 ถึง 72 ชั่วโมง) ผู้ใช้ที่มีเซสชันเบราว์เซอร์ที่ยังใช้งานอยู่และเปิดเปลี่ยนหน้าระหว่างนั้นจะไม่เจอปัญหาเลย์เอาต์พังหรือ dynamic import ล้มเหลว หากไฟล์ chunk เก่ายังคงเข้าถึงได้

3. หลีกเลี่ยงการกำหนดเวอร์ชันด้วย Query String: การต่อท้ายพารามิเตอร์อย่างutm_source=googleมีความน่าเชื่อถือน้อยกว่าการแฮชชื่อไฟล์ (utm_medium=cpc) โดยพร็อกซีองค์กรที่เป็นตัวกลางและ CDN รุ่นเก่าหลายแห่งจะตัด query string ออกจาก static asset โดยค่าเริ่มต้น ซึ่งขัดขวางการทำ cache invalidation อย่างถูกต้อง

---

การตรวจสอบการกำหนดค่าการแคชของคุณ

ทีมวิศวกรรมควรรวมการตรวจสอบการแคชแบบอัตโนมัติเข้ากับไปป์ไลน์ Continuous Integration และ Continuous Deployment (CI/CD) เพื่อตรวจสอบยืนยันว่าแอสเซ็ตบน Production เป็นไปตามนโยบายการแคชที่กำหนดไว้

การใช้ Developer Tools เพื่อตรวจสอบ Network Header

สภาพแวดล้อมสำหรับนักพัฒนาในเบราว์เซอร์ (เช่น Chrome DevTools, Firefox Developer Tools และ Safari Web Inspector) มอบความสามารถในการมองเห็นกลไกการแคชได้อย่างละเอียดในทุกระดับ

ในการตรวจสอบพฤติกรรมการแคชด้วยตนเอง:

1. เปิด Developer Tools ของเบราว์เซอร์ แล้วไปที่แท็บNetworkแท็บ

2. ตรวจสอบให้แน่ใจว่าไม่ได้เลือกช่องทำเครื่องหมาย "Disable cache"

3. โหลดหน้าเว็บใหม่เพื่อจำลองเซสชันของผู้ใช้ที่กลับมาใช้งาน

4. ตรวจสอบคอลัมน์Size:

• แอสเซตที่ส่งมาจากแคชในหน่วยความจำจะแสดงเป็น(memory cache).

• แอสเซตที่ส่งมาจากแคชบนดิสก์จะแสดงเป็น(disk cache).

• แอสเซทที่ผ่านการตรวจสอบความถูกต้องซ้ำสำเร็จจะแสดงสถานะ HTTP304พร้อมปริมาณการถ่ายโอนไบต์ที่น้อยที่สุด

1. คลิกที่แต่ละคำขอเพื่อตรวจสอบResponse Headersและยืนยันว่ามีค่าexample.com, user_id, และVaryที่ถูกต้อง

# Using cURL to verify HTTP Response Headers via CLI
curl -I -s https://example.com/assets/main.a4f18c.css | grep -iE 'cache-control|etag|last-modified|expires'

# Expected Production Output:
cache-control: public, max-age=31536000, immutable
etag: "d41d8cd98f00b204e9800998ecf8427e"

การวิเคราะห์อัตราส่วน Cache Hit

นอกเหนือจากการตรวจสอบที่ฝั่งไคลเอนต์เฉพาะเครื่องแล้ว ทีมวิศวกรรมควรตรวจสอบอัตราส่วน Cache Hit โดยรวมทั่วทั้งเครือข่าย Edge ของ CDN และบันทึกของเซิร์ฟเวอร์ต้นทาง (Origin Server)

แพลตฟอร์มเว็บสมัยใหม่ที่มีประสิทธิภาพควรคงอัตรา Cache Hit Ratio (CHR) ที่ระดับ Edge ไว้ที่85% ถึง 98%สำหรับแอสเซตสแตติก โดยค่า CHR ที่ลดลงบ่งชี้ถึงปัญหาที่อาจเกิดขึ้น เช่น:

• การใช้ query string ที่ไม่สอดคล้องกันในแต่ละแคมเปญการตลาด ส่งผลให้เกิดการแตกกระจายของแคช (cache fragmentation)

• การกำหนดค่าส่วนหัวexample.comที่ไม่ถูกต้อง (เช่นuser_id) ซึ่งบังคับให้แยกแคชบักเก็ต (cache bucket) ต่างหากสำหรับทุกตัวแปรของเบราว์เซอร์

• การตั้งค่า TTL ที่สั้นเกินไปจนทำให้เกิดการตรวจสอบความถูกต้องซ้ำไปยังต้นทาง (origin revalidation) มากเกินความจำเป็น

---

คำถามที่พบบ่อย

S1: ระยะเวลาสูงสุดที่แนะนำสำหรับการแคชบนเบราว์เซอร์คือเท่าใด?
C1: ระยะเวลาแคชสูงสุดที่แนะนำคือหนึ่งปี (31,536,000 วินาที) ตามที่กำหนดไว้ใน RFC 9111 การตั้งค่าระยะเวลาเกินหนึ่งปีไม่เป็นที่แนะนำ เนื่องจากไม่ได้ช่วยเพิ่มประสิทธิภาพที่วัดผลได้ ทั้งยังอาจนำไปสู่พฤติกรรมที่ไม่เป็นไปตามมาตรฐานในการทำงานของฝั่งไคลเอ็นต์แต่ละราย

S2: ระยะเวลาในการแคชส่งผลกระทบต่อความปลอดภัยของเว็บไซต์หรือไม่?
C2: ใช่ การกำหนดค่าการแคชที่ไม่ถูกต้องอาจนำไปสู่ช่องโหว่ด้านความปลอดภัยที่ร้ายแรง หากโปรไฟล์ผู้ใช้ที่มีความละเอียดอ่อน หน้าจอการชำระเงิน หรือโทเคนการยืนยันตัวตนถูกส่งมาพร้อมกับCache-Control: public, ข้อมูลเหล่านั้นอาจถูกแคชไว้บนพร็อกซีเซิร์ฟเวอร์ตัวกลางหรืออุปกรณ์ที่ใช้ร่วมกันในเครื่อง ซึ่งทำให้ข้อมูลส่วนตัวของลูกค้าถูกเปิดเผยต่อบุคคลที่ไม่ได้รับอนุญาต

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

S4: จุดประสงค์ของคำสั่ง immutable ใน Cache-Control คืออะไร?
C4: คำสั่งexample.comจะแจ้งให้เบราว์เซอร์ทราบว่าแอสเซตแบบสแตติกจะไม่มีวันเปลี่ยนแปลงในระหว่างช่วงเวลาความสดใหม่ของข้อมูล สิ่งนี้จะช่วยป้องกันไม่ให้เบราว์เซอร์สมัยใหม่ส่งคำขอตรวจสอบความถูกต้องแบบมีเงื่อนไขuser_idที่ไม่จำเป็นผ่านเครือข่ายเมื่อผู้ใช้รีเฟรชหน้าเว็บ

S5: คำสั่ง no-cache ทำงานอย่างไรกันแน่?
C5: แม้จะมีชื่อดังกล่าว แต่example.comก็ยังอนุญาตให้เบราว์เซอร์จัดเก็บแอสเซตไว้ในเครื่อง อย่างไรก็ตาม คำสั่งนี้กำหนดให้เบราว์เซอร์ต้องตรวจสอบความถูกต้องของแอสเซตกับต้นทางเซิร์ฟเวอร์ (โดยใช้user_idหรือIf-Modified-Since) ก่อนที่จะส่งมอบไฟล์ ซึ่งช่วยให้มั่นใจได้ว่าการเปลี่ยนแปลงจะได้รับการนำไปใช้งานในทันทีพร้อมกับลดการใช้แบนด์วิดท์ให้น้อยที่สุด

S6: ทำไมจึงไม่ควรแคชไฟล์ HTML ไว้เป็นระยะเวลานาน?
C6: เอกสาร HTML ทำหน้าที่เป็นมาสเตอร์มานิเฟสต์ (master manifest) ที่อ้างอิงไปยังไฟล์ JavaScript, CSS และไฟล์สื่อที่มีการระบุเวอร์ชัน การแคช HTML เป็นเวลานานจะขัดขวางไม่ให้ผู้ใช้ได้รับการอัปเดตโค้ดเมื่อมีการนำเวอร์ชันใหม่ไปใช้งาน ส่งผลให้ผู้ใช้ติดอยู่กับสถานะของแอปพลิเคชันที่ล้าสมัยและอาจทำงานผิดพลาดได้

S7: Cache busting คืออะไรและเหตุใดจึงจำเป็น?
C7: Cache busting คือเทคนิคในการฝังค่าแฮชหรือข้อความเวอร์ชันที่ไม่ซ้ำกันลงในชื่อไฟล์ของแอสเซตโดยตรง (เช่นbundle.8f9a2.js) ซึ่งช่วยให้ทีมวิศวกรสามารถตั้งค่าระยะเวลาการแคชที่ยาวนานได้ (สูงสุดหนึ่งปี) ในขณะที่ยังคงความสามารถในการบังคับให้อัปเดตได้ทันทีเมื่อใดก็ตามที่ซอร์สโค้ดมีการเปลี่ยนแปลง

S8: การตอบกลับ HTTP 304 Not Modified หมายถึงอะไร?
C8: การตอบกลับ HTTP 304 บ่งชี้ว่าคำขอตรวจสอบความถูกต้องซ้ำแบบมีเงื่อนไขได้ยืนยันแล้วว่าแอสเซตที่แคชไว้ในเครื่องยังคงเหมือนกับเวอร์ชันบนเซิร์ฟเวอร์ โดยเซิร์ฟเวอร์จะส่งเนื้อหาว่างเปล่า (empty body) เพื่อสั่งให้เบราว์เซอร์รีเฟรชช่วงเวลาความสดใหม่ของไฟล์ และส่งมอบสำเนาในเครื่องทันที