เครื่องมือเพิ่มเติมที่จะช่วยคุณรักษาสมดุลระหว่างความรวดเร็วและความใหม่เมื่อแสดงเว็บแอป
มีอะไรบ้างที่จัดส่งแล้ว
stale-while-revalidate
ช่วยให้นักพัฒนาซอฟต์แวร์รักษาสมดุลระหว่างความรวดเร็วในการแสดงผล - การโหลดเนื้อหาที่แคชไว้ทันที และความใหม่ - การรับรองว่าระบบจะใช้การอัปเดตเนื้อหาที่แคชไว้ในอนาคต หากคุณดูแลรักษาเว็บเซอร์วิสหรือไลบรารีของบุคคลที่สามที่อัปเดตตามกำหนดการปกติ หรือชิ้นงานของบุคคลที่หนึ่งมีแนวโน้มที่จะมีอายุสั้น stale-while-revalidate
อาจมีประโยชน์เพิ่มเติมสำหรับนโยบายการแคชที่มีอยู่
การรองรับการตั้งค่า stale-while-revalidate
ควบคู่ไปกับ max-age
ในส่วนหัวCache-Control
การตอบกลับมีให้บริการใน Chrome 75 และ Firefox 68
เบราว์เซอร์ที่ไม่รองรับ stale-while-revalidate
จะละเว้นค่าการกําหนดค่านั้นโดยอัตโนมัติ และใช้ max-age
ตามที่เราจะอธิบายในอีกสักครู่
หมายความว่าอย่างไร
เรามาแยก stale-while-revalidate
ออกเป็น 2 ส่วนกัน นั่นคือ แนวคิดที่ว่าคำตอบที่แคชไว้อาจล้าสมัย และกระบวนการตรวจสอบอีกครั้ง
ประการแรก เบราว์เซอร์จะรู้ได้อย่างไรว่าการตอบกลับที่แคชไว้ "ล้าสมัย" หรือไม่ ส่วนหัวการตอบกลับ Cache-Control
ที่มี stale-while-revalidate
ควรมี max-age
ด้วย และจำนวนวินาทีที่ระบุผ่าน max-age
จะเป็นตัวกำหนดความล้าสมัย คำตอบที่แคชไว้ซึ่งใหม่กว่า max-age
จะถือว่าใหม่ ส่วนคำตอบที่แคชไว้ซึ่งเก่ากว่าจะถือว่าล้าสมัย
หากคำตอบที่แคชไว้ในพื้นที่ยังใหม่อยู่ ก็สามารถใช้คำตอบนั้นเพื่อตอบสนองคำขอของเบราว์เซอร์ได้ จากมุมมองของ stale-while-revalidate
ไม่มีอะไรต้องทำในสถานการณ์นี้
แต่หากคำตอบที่แคชไว้ล้าสมัย ระบบจะดำเนินการตรวจสอบตามอายุอีก 1 ครั้ง โดยดูว่าอายุของคำตอบที่แคชไว้อยู่ภายในกรอบเวลาเพิ่มเติมที่การตั้งค่าstale-while-revalidate
ระบุไว้หรือไม่
หากอายุของการตอบกลับที่ล้าสมัยอยู่ในช่วงนี้ ระบบจะใช้การตอบกลับดังกล่าวเพื่อตอบสนองคําขอของเบราว์เซอร์ ในขณะเดียวกัน ระบบจะส่งคําขอ "ตรวจสอบอีกครั้ง" ไปยังเครือข่ายในลักษณะที่ไม่ทำให้การตอบกลับที่แคชไว้ล่าช้า คำตอบที่แสดงอาจให้ข้อมูลเดียวกันกับคำตอบที่แคชไว้ก่อนหน้านี้ หรืออาจแตกต่างกัน ไม่ว่าจะด้วยวิธีใด ระบบจะจัดเก็บคําตอบของเครือข่ายไว้ในเครื่องแทนที่ข้อมูลที่แคชไว้ก่อนหน้านี้ และรีเซ็ตตัวจับเวลา "ความใหม่" ที่ใช้ในระหว่างการเปรียบเทียบ max-age
ในอนาคต
อย่างไรก็ตาม หากคำตอบที่แคชไว้เก่าเกินกว่าที่จะอยู่ในกรอบเวลาstale-while-revalidate
คำตอบดังกล่าวจะไม่ตอบสนองคำขอของเบราว์เซอร์ เบราว์เซอร์จะดึงข้อมูลการตอบกลับจากเครือข่ายแทน และใช้ข้อมูลดังกล่าวเพื่อดำเนินการตามคำขอเริ่มต้นและป้อนข้อมูลแคชในเครื่องด้วยคำตอบใหม่
ตัวอย่างการใช้งานจริง
ด้านล่างนี้คือตัวอย่างง่ายๆ ของ HTTP API สำหรับแสดงเวลาปัจจุบัน ซึ่งก็คือจำนวนนาทีที่ผ่านไปแล้วนับจากชั่วโมง
ในสถานการณ์นี้ เว็บเซิร์ฟเวอร์ใช้ส่วนหัว Cache-Control
นี้ในการตอบกลับ HTTP
Cache-Control: max-age=1, stale-while-revalidate=59
การตั้งค่านี้หมายความว่าหากมีการขอเวลาซ้ำภายใน 1 วินาทีข้างหน้า ค่าที่แคชไว้ก่อนหน้านี้จะยังคงเป็นค่าล่าสุดและจะใช้ตามที่เป็นอยู่โดยไม่ต้องมีการตรวจสอบอีกครั้ง
หากมีการส่งคำขอซ้ำภายใน 1-60 วินาทีต่อมา ค่าที่แคชไว้จะล้าสมัย แต่ระบบจะใช้เพื่อดำเนินการตามคำขอ API ในขณะเดียวกัน ระบบจะส่งคําขอตรวจสอบอีกครั้ง "ในเบื้องหลัง" เพื่อป้อนข้อมูลแคชด้วยค่าใหม่สําหรับใช้ในอนาคต
หากมีการส่งคำขอซ้ำหลังจากผ่านไปนานกว่า 60 วินาที ระบบจะไม่ใช้คำตอบที่ล้าสมัยเลย และทั้งการตอบสนองคำขอของเบราว์เซอร์และการทำให้แคชกลับมาใช้งานได้อีกครั้งจะขึ้นอยู่กับการได้รับการตอบกลับจากเครือข่าย
รายละเอียดของสถานะที่แตกต่างกัน 3 สถานะดังกล่าวพร้อมกรอบเวลาที่มีผลกับแต่ละสถานะสำหรับตัวอย่างของเรามีดังนี้
Use Case ที่พบบ่อยมีอะไรบ้าง
แม้ว่าตัวอย่างข้างต้นสำหรับบริการ API "นาทีหลังจากชั่วโมง" จะเป็นสิ่งที่สมมติขึ้น แต่ก็แสดงถึง Use Case ที่คาดไว้ ซึ่งก็คือบริการที่ให้ข้อมูลที่จำเป็นต้องรีเฟรช แต่ยอมรับความล้าสมัยได้ในระดับหนึ่ง
ตัวอย่างที่ไม่ค่อยซับซ้อนอาจเป็น API สําหรับสภาพอากาศปัจจุบัน หรือพาดหัวข่าวเด่นที่เขียนขึ้นในชั่วโมงที่ผ่านมา
โดยทั่วไปแล้ว คำตอบที่อัปเดตเป็นช่วงเวลาที่ทราบ มีแนวโน้มที่จะได้รับคำขอหลายครั้ง และคงที่ภายในช่วงเวลานั้น เหมาะที่จะแคชในระยะสั้นผ่าน max-age
การใช้ stale-while-revalidate
เพิ่มเติมจาก max-age
จะเพิ่มโอกาสที่คำขอในอนาคตจะได้รับการตอบสนองจากแคชที่มีเนื้อหาใหม่กว่า โดยไม่ต้องบล็อกการตอบสนองของเครือข่าย
มีการโต้ตอบกับ Service Worker อย่างไร
หากคุณเคยได้ยินคำว่า stale-while-revalidate
อาจเป็นเพราะอยู่ในบริบทของสูตรที่ใช้ภายใน Service Worker
การใช้ stale-while-revalidate ผ่านส่วนหัว Cache-Control
มีความคล้ายคลึงกับการใช้งานใน Service Worker และการพิจารณาหลายอย่างเกี่ยวกับข้อดีข้อเสียของข้อมูลล่าสุดและอายุการใช้งานสูงสุดก็ยังคงมีผลบังคับใช้ อย่างไรก็ตาม คุณควรพิจารณาสิ่งต่อไปนี้เมื่อตัดสินใจว่าจะใช้แนวทางแบบ Service Worker หรือจะใช้การกำหนดค่าส่วนหัว Cache-Control
เพียงอย่างเดียว
ใช้แนวทาง Service Worker ในกรณีต่อไปนี้
- คุณใช้ Service Worker ในเว็บแอปอยู่แล้ว
- คุณต้องการควบคุมเนื้อหาของแคชอย่างละเอียด และต้องการนํานโยบายการหมดอายุแบบ "ใช้ล่าสุดน้อยที่สุด" มาใช้ โมดูลการหมดอายุของแคชของ Workbox ช่วยแก้ปัญหานี้ได้
- คุณต้องการรับการแจ้งเตือนเมื่อคำตอบที่ล้าสมัยมีการเปลี่ยนแปลงในเบื้องหลังระหว่างขั้นตอนการตรวจสอบอีกครั้ง โมดูลการอัปเดตแคชการออกอากาศของ Workbox ช่วยแก้ปัญหานี้ได้
- คุณต้องมีลักษณะการทำงาน
stale-while-revalidate
นี้ในเบราว์เซอร์สมัยใหม่ทั้งหมด
ใช้แนวทางการควบคุมแคชในกรณีต่อไปนี้
- คุณไม่ต้องการจัดการกับค่าใช้จ่ายเพิ่มเติมในการติดตั้งใช้งานและการดูแลรักษา Service Worker สําหรับเว็บแอป
- คุณอนุญาตให้การจัดการแคชอัตโนมัติของเบราว์เซอร์ป้องกันไม่ให้แคชในเครื่องมีขนาดใหญ่เกินไป
- คุณใช้แนวทางที่ปัจจุบันเบราว์เซอร์สมัยใหม่บางรุ่นยังไม่รองรับได้ (ข้อมูล ณ เดือนกรกฎาคม 2019 อาจมีการสนับสนุนเพิ่มเติมในอนาคต)
หากคุณใช้ Service Worker และเปิดใช้ stale-while-revalidate
สำหรับการตอบกลับบางอย่างผ่านส่วนหัว Cache-Control
ด้วย โดยทั่วไปแล้ว Service Worker จะได้รับ "โอกาสแรก" ในการตอบกลับคำขอ หาก Service Worker ตัดสินใจไม่ตอบกลับ หรือหากในระหว่างการสร้างการตอบกลับมีการส่งคำขอเครือข่ายโดยใช้ fetch()
ลักษณะการทำงานที่กำหนดค่าผ่านส่วนหัว Cache-Control
ก็จะมีผล
ดูข้อมูลเพิ่มเติม
stale-while-revalidate
response ในข้อมูลจำเพาะของ Fetch API- RFC 5861 ซึ่งครอบคลุมข้อกำหนด
stale-while-revalidate
ฉบับแรก - แคช HTTP: ด่านป้องกันแรกของคุณ จากคู่มือ "ความน่าเชื่อถือของเครือข่าย" ในเว็บไซต์นี้
รูปภาพหลักโดย Samuel Zeller