หมั่นอัปเดตสิ่งใหม่ให้เป็นปัจจุบันเสมอพร้อมตรวจสอบความถูกต้องอีกครั้ง

เครื่องมือเพิ่มเติมที่จะช่วยคุณรักษาสมดุลระหว่างความรวดเร็วและความใหม่เมื่อแสดงเว็บแอป

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 ก็จะมีผล

ดูข้อมูลเพิ่มเติม

รูปภาพหลักโดย Samuel Zeller