เครื่องมือเพิ่มเติมที่จะช่วยคุณรักษาสมดุลระหว่างความรวดเร็วและความใหม่เมื่อแสดงเว็บแอป
สิ่งที่จัดส่ง
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
ไม่มีอะไรต้องทำในสถานการณ์นี้
แต่หากการตอบกลับที่แคชไว้ไม่มีอัปเดต ระบบจะทำการตรวจสอบตามอายุอีกครั้ง ซึ่งก็คืออายุของการตอบกลับที่แคชไว้ภายในกรอบเวลาเพิ่มเติมซึ่งระบุไว้ในการตั้งค่า stale-while-revalidate
ใช่ไหม
หากอายุของการตอบกลับที่ไม่มีการอัปเดตอยู่ในหน้าต่างนี้ ระบบจะใช้ข้อมูลดังกล่าวเพื่อตอบสนองคำขอของเบราว์เซอร์ ในขณะเดียวกัน ระบบจะส่งคําขอ "ตรวจสอบอีกครั้ง" ไปยังเครือข่ายในลักษณะที่ไม่ทำให้การตอบกลับที่แคชไว้ล่าช้า คำตอบที่แสดงอาจให้ข้อมูลเดียวกันกับคำตอบที่แคชไว้ก่อนหน้านี้ หรืออาจแตกต่างกัน ไม่ว่าจะด้วยวิธีใด ระบบจะจัดเก็บคําตอบของเครือข่ายไว้ในเครื่องแทนที่ข้อมูลที่แคชไว้ก่อนหน้านี้ และรีเซ็ตตัวจับเวลา "ความใหม่" ที่ใช้ในระหว่างการเปรียบเทียบ max-age
ในอนาคต
อย่างไรก็ตาม หากคำตอบที่แคชไว้เก่าเกินกว่าที่จะอยู่ในกรอบเวลาstale-while-revalidate
คำตอบดังกล่าวจะไม่ตอบสนองคำขอของเบราว์เซอร์ เบราว์เซอร์จะเรียกการตอบสนองจากเครือข่ายและใช้การตอบสนองดังกล่าวทั้งสำหรับการดำเนินการตามคำขอเริ่มต้นและการเติมข้อมูลแคชในเครื่องที่มีการตอบกลับใหม่
ตัวอย่างที่เผยแพร่อยู่
ด้านล่างเป็นตัวอย่างง่ายๆ ของ HTTP API สำหรับแสดงผลเวลาปัจจุบัน โดยเฉพาะจำนวนนาทีปัจจุบันเลย 1 ชั่วโมง
ในสถานการณ์นี้ เว็บเซิร์ฟเวอร์จะใช้ส่วนหัว 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
มีโอกาสที่ข้อมูลดังกล่าวเป็นในบริบทของสูตรอาหารที่ใช้ภายในโปรแกรมทำงานของบริการ
การใช้ stale-while-revalidate ผ่านส่วนหัว Cache-Control
มีความคล้ายคลึงกับการใช้งานใน Service Worker และการพิจารณาหลายอย่างเกี่ยวกับข้อดีข้อเสียของข้อมูลล่าสุดและอายุการใช้งานสูงสุดก็ยังคงมีผลบังคับใช้ อย่างไรก็ตาม คุณควรพิจารณาสิ่งต่อไปนี้เมื่อตัดสินใจว่าจะเลือกใช้แนวทางแบบ Service Worker หรือจะใช้การกำหนดค่าส่วนหัว Cache-Control
เพียงอย่างเดียว
ใช้แนวทาง Service Worker ในกรณีต่อไปนี้
- คุณใช้ Service Worker ในเว็บแอปอยู่แล้ว
- คุณต้องการควบคุมเนื้อหาแคชอย่างละเอียด และต้องการนํานโยบายการหมดอายุแบบ "ใช้ล่าสุดน้อยที่สุด" มาใช้ โมดูลการหมดอายุของแคชของ Workbox อาจช่วยในเรื่องนี้ได้
- คุณต้องการรับการแจ้งเตือนเมื่อคำตอบที่ไม่มีการอัปเดตมีการเปลี่ยนแปลงในพื้นหลังระหว่างขั้นตอนการตรวจสอบอีกครั้ง โมดูลการอัปเดตแคชการออกอากาศของ Workbox ช่วยแก้ปัญหานี้ได้
- คุณต้องมีลักษณะการทำงาน
stale-while-revalidate
นี้ในเบราว์เซอร์สมัยใหม่ทั้งหมด
ใช้แนวทางการควบคุมแคชในกรณีต่อไปนี้
- คุณไม่ต้องการจัดการกับค่าใช้จ่ายเพิ่มเติมในการติดตั้งใช้งานและการดูแลรักษา Service Worker สําหรับเว็บแอป
- คุณอนุญาตให้การจัดการแคชอัตโนมัติของเบราว์เซอร์ป้องกันไม่ให้แคชในเครื่องมีขนาดใหญ่เกินไป
- คุณใช้แนวทางที่ปัจจุบันเบราว์เซอร์สมัยใหม่บางรุ่นยังไม่รองรับได้ (ข้อมูล ณ เดือนกรกฎาคม 2019 อาจมีการสนับสนุนเพิ่มเติมในอนาคต)
หากคุณใช้โปรแกรมทำงานของบริการและเปิดใช้ stale-while-revalidate
สำหรับการตอบกลับบางรายการผ่านส่วนหัว Cache-Control
อยู่ โดยทั่วไปโปรแกรมทำงานของบริการจะมี "แคร็กครั้งแรก" ในการตอบกลับคำขอ หาก Service Worker ตัดสินใจไม่ตอบกลับ หรือหากในระหว่างการสร้างการตอบกลับมีการส่งคำขอเครือข่ายโดยใช้ fetch()
ลักษณะการทำงานที่กำหนดค่าผ่านส่วนหัว Cache-Control
ก็จะมีผล
ดูข้อมูลเพิ่มเติม
- การตอบสนองของ
stale-while-revalidate
ในข้อมูลจำเพาะของ Fetch API - RFC 5861 ซึ่งครอบคลุมข้อกำหนด
stale-while-revalidate
ฉบับแรก - แคช HTTP: ด่านป้องกันแรกของคุณ จากคู่มือ "ความน่าเชื่อถือของเครือข่าย" ในเว็บไซต์นี้
รูปภาพหลักโดย Samuel Zeller