เผยแพร่: 21 ตุลาคม 2024, อัปเดตล่าสุด: 9 กันยายน 2025
Chrome กำลังจะเปลี่ยนแปลงเพื่อให้หน้าเว็บที่ใช้ Cache-Control: no-store สามารถใช้ Back-Forward Cache (bfcache) ได้เมื่อปลอดภัยที่จะทำเช่นนั้น ดูว่าการเปลี่ยนแปลงนี้มีผลต่อนักพัฒนาซอฟต์แวร์อย่างไร
ฉากหลัง
การตั้งค่า Cache-Control: no-store เป็นส่วนหัว HTTP เป็นสัญญาณว่าไม่ควรจัดเก็บหน้าเว็บในแคช HTTP ควรใช้สำหรับหน้าที่มีข้อมูลที่ละเอียดอ่อน เช่น หน้าที่ผู้ใช้เข้าสู่ระบบ แต่โดยทั่วไปมักใช้คำสั่ง no-store ในหน้าเว็บที่ไม่มีข้อมูลที่ละเอียดอ่อน
เมื่อใช้ bfcache เราจะเลื่อนการทำลายหน้าเว็บและหยุดการดำเนินการ JS ชั่วคราวแทนที่จะทำลายหน้าเว็บเมื่อผู้ใช้ออกจากหน้าเว็บ หากผู้ใช้กลับมาในเร็วๆ นี้ เราจะทำให้หน้าเว็บแสดงอีกครั้งและยกเลิกการหยุดการดำเนินการ JS ชั่วคราว ซึ่งจะทําให้ผู้ใช้ไปยังส่วนต่างๆ ของหน้าเว็บได้แทบจะทันที
แม้ว่าข้อกำหนด HTML จะไม่ได้กำหนดไว้ แต่โดยปกติแล้วเบราว์เซอร์จะถือว่า Cache-Control: no-store เป็นสัญญาณเพื่อหลีกเลี่ยงการวางหน้าเว็บไว้ใน bfcache นี่เป็นสาเหตุที่ใหญ่ที่สุดที่ไม่ได้ใช้ bfcache สำหรับการไปยังส่วนต่างๆ ในประวัติประมาณ 17% บนอุปกรณ์เคลื่อนที่ และ 7% บนเดสก์ท็อป ซึ่งหมายความว่าหน้าเว็บเหล่านี้จะไม่ได้รับประโยชน์จากการกู้คืนอย่างรวดเร็วและต้องโหลดหน้าเว็บซ้ำทั้งหมด รวมถึงการเรียกเครือข่าย การเรียกใช้ JavaScript และการแสดงผล
โดยทั่วไปแล้ว Cache-Control: no-store จะตั้งค่าเพื่อหลีกเลี่ยงปัญหาการแคชเมื่อเว็บไซต์มีการเปลี่ยนแปลง แต่เหตุผลนี้จะมีความเกี่ยวข้องน้อยลงเมื่อใช้ bfcache เนื่องจากระบบจะคืนค่าทั้งหน้าแทบจะเหมือนกับว่ามีการเปิดหน้าไว้ตลอด
วิธีที่ Chrome เปลี่ยนพฤติกรรมนี้
Chrome ได้ประกาศความตั้งใจที่จะเปลี่ยนลักษณะการทำงานนี้ แต่จะใช้แนวทางที่รอบคอบในการเปลี่ยนแปลงนี้ เราได้ทำการทดลองมาตั้งแต่ Chrome 116 โดยค่อยๆ เพิ่มเปอร์เซ็นต์การโหลดหน้าเว็บ และคาดว่าจะเพิ่มเป็น 100% ในเดือนมีนาคมและเมษายน 2025
ข้อมูลที่ละเอียดอ่อน
แม้ว่าการวิเคราะห์ของเราจะแสดงให้เห็นว่าการไปยังหน้าก่อนหน้าหรือหน้าถัดไปส่วนใหญ่ไม่มีข้อมูลที่ละเอียดอ่อนและควรมีสิทธิ์ใช้ bfcache แต่ก็มีบางกรณีที่ระบบไม่ควรวางหน้าเว็บไว้ใน bfcache เช่น เมื่อออกจากระบบ ผู้ใช้ไม่ควรดึงหน้าเว็บที่เข้าสู่ระบบแล้วกลับมาได้โดยการไปยังหน้าก่อนหน้าหรือหน้าถัดไป
Chrome จะนำหน้าเว็บออกจาก bfcache เมื่อมีการเปลี่ยนแปลงคุกกี้หรือวิธีการให้สิทธิ์อื่นๆ เพื่อหลีกเลี่ยงปัญหานี้
นอกจากนี้ การใช้ API ต่อไปนี้สำหรับหน้าเว็บที่ใช้ Cache-Control: no-store จะยังคงทำให้หน้าเว็บเหล่านั้นไม่มีสิทธิ์ใช้ bfcache
โปรดทราบว่านี่ไม่ใช่รายการ API ทั้งหมดที่ป้องกันการใช้งาน bfcache แต่เป็น API ที่บล็อก bfcache ในหน้า Cache-Control: no-store แม้ว่าจะไม่ได้ใช้งานในขณะที่ออกจากหน้าก็ตาม
นอกจากนี้ เรายังลดระยะหมดเวลาของ bfcache สำหรับหน้า Cache-Control: no-store เหลือ 3 นาที (จาก 10 นาทีที่ใช้สำหรับหน้าเว็บที่ไม่ได้ใช้ Cache-Control: no-store) เพื่อลดความเสี่ยงเพิ่มเติม
การเลือกไม่ใช้สำหรับองค์กร
โดยทั่วไปแล้ว องค์กรมักจะมีซอฟต์แวร์ที่อัปเดตได้ยากและอุปกรณ์ที่ใช้ร่วมกัน คุณปิดใช้นโยบาย AllowBackForwardCacheForCacheControlNoStorePageEnabled เพื่อป้องกันไม่ให้ใช้ bfcache สำหรับหน้า Cache-Control: no-store ต่อไปได้
การทดสอบการเปลี่ยนแปลง
นักพัฒนาแอปทดสอบการเปลี่ยนแปลงนี้ได้โดยใช้การตั้งค่าสถานะต่อไปนี้
--enable-features=CacheControlNoStoreEnterBackForwardCache:level/restore-unless-cookie-change
หากมีข้อยกเว้นก่อนหน้านี้ เช่น การเปลี่ยนแปลงคุกกี้ จะทำให้หน้าเว็บใช้ bfcache ไม่ได้ โดยมีเหตุผลว่า "หน้าเว็บที่มีทรัพยากรหลักเป็น Cache-Control: no-store จะเข้าสู่ Back/Forward Cache ไม่ได้" ซึ่งจะแสดงในเครื่องมือทดสอบ bfcache ของ Chrome DevTools
คุณใช้หน้าทดสอบ bfcache นี้เพื่อทดสอบโดยมีและไม่มี Flag นี้ได้
สิ่งที่นักพัฒนาแอปควรรู้
แม้ว่านักพัฒนาแอปไม่จำเป็นต้องทำการเปลี่ยนแปลงใดๆ เพื่อให้ผู้ใช้ได้รับประโยชน์จากการใช้งาน bfcache ที่มากขึ้นนี้ แต่ก็มีบางสิ่งที่นักพัฒนาแอปอาจต้องพิจารณาอันเป็นผลมาจากการเปลี่ยนแปลงนี้ ซึ่งเป็นข้อควรพิจารณาที่คล้ายกันกับที่เว็บไซต์อื่นๆ อาจพบในการเปิดตัว bfcache ครั้งแรกในเดือนธันวาคม 2021
นักพัฒนาแอปยังควรตั้งเป้าที่จะลดการใช้งาน Cache-Control: no-store ไหม
ระบบจะเปิดใช้ bfcache สำหรับ Cache-Control: no-store ภายใต้สถานการณ์ที่จำกัดที่กล่าวถึงก่อนหน้านี้และสำหรับ Chrome เท่านั้น เบราว์เซอร์อื่นๆ อาจยังบล็อกการใช้งาน bfcache เมื่อมีการใช้ Cache-Control: no-store
แนวทางปฏิบัติแนะนำยังคงเป็นการลดการใช้ Cache-Control: no-store แทนการพึ่งพาฮิวริสติกเหล่านี้
ผลกระทบต่อประสิทธิภาพ
สาเหตุที่เราทำการเปลี่ยนแปลงนี้ก็เพื่อปรับปรุงประสบการณ์การใช้งานหน้าเว็บสำหรับผู้ใช้บนเว็บ เราเห็นการปรับปรุงที่เห็นได้ชัดใน Core Web Vitals เมื่อเปิดตัว bfcache เป็นครั้งแรก และตอนนี้เราต้องการนำการปรับปรุงเดียวกันนี้มาใช้กับเว็บไซต์อื่นๆ เพิ่มเติม
เจ้าของเว็บไซต์อาจเห็นการปรับปรุง Core Web Vitals เมื่อมีการเปิดตัวฟีเจอร์นี้ และสามารถวัดการใช้งาน bfcache ใน CrUX รวมถึงใน CrUX Vis
ข้อมูลวิเคราะห์ผลกระทบ
หน้าเว็บที่กู้คืนจาก bfcache จะ "กู้คืน" หน้าเว็บเก่า (รวมถึงฮีป JavaScript) แทนที่จะโหลดหน้าเว็บซ้ำ ผู้ให้บริการวิเคราะห์ยอดนิยมหลายรายไม่ได้วัดการคืนค่า bfcache เป็นการดูหน้าเว็บใหม่ เนื่องจากจะทริกเกอร์การดูหน้าเว็บเมื่อโหลดครั้งแรกเท่านั้น
ดังนั้นเว็บไซต์อาจเห็นว่าการโหลดหน้าเว็บในข้อมูลวิเคราะห์ลดลงเมื่อเริ่มใช้ bfcache เป็นครั้งแรก เราขอแนะนำให้พิจารณาเหตุการณ์เหล่านี้เป็นการดูหน้าเว็บโดยการตั้งค่า Listener สำหรับเหตุการณ์ pageshow และตรวจสอบพร็อพเพอร์ตี้ persisted
// Send a pageview when the page is first loaded.
gtag('event', 'page_view');
// Send another pageview if the page is restored from bfcache.
window.addEventListener('pageshow', (event) => {
if (event.persisted) {
// Page was restored from bfcache, sent another page view.
gtag('event', 'page_view');
}
});
จัดการการอัปเดตเมื่อมีการกู้คืนหน้าเว็บ
เนื่องจากตอนนี้เว็บไซต์อาจเห็นการใช้งาน bfcache ในกรณีที่ก่อนหน้านี้ไม่เห็น และเมื่อหน้าเว็บจะโหลดซ้ำทั้งหมดพร้อมข้อมูลล่าสุด นักพัฒนาซอฟต์แวร์อาจต้องพิจารณารีเฟรชข้อมูลเมื่อมีการกู้คืน bfcache
คุณสามารถทริกเกอร์การอัปเดตได้ในลักษณะเดียวกับการบันทึกการดูหน้าเว็บเพิ่มเติมสําหรับข้อมูลวิเคราะห์โดยใช้เหตุการณ์ pageshow และตรวจสอบพร็อพเพอร์ตี้ persisted
โปรดทราบว่าเนื้อหาบางรายการไม่จำเป็นต้องอัปเดต และผู้ใช้อาจต้องการ "ย้อนกลับ" ไปยังเนื้อหาที่เคยดู เช่น การรีเฟรชรายการบทความอาจหมายความว่าผู้ใช้จะไม่เห็นบทความที่กำลังจะกลับไปดูอีกต่อไป
ผลกระทบต่อโฆษณา
เช่นเดียวกับผลกระทบจากการวิเคราะห์ เว็บไซต์อาจเห็นการแสดงโฆษณาลดลงหากโฆษณาโหลดเมื่อโหลดหน้าเว็บเท่านั้น โฆษณาสามารถรีเฟรชแบบเป็นโปรแกรมเมื่อมีการคืนค่า bfcache เพื่อให้แน่ใจว่าโฆษณาจะทำงานเหมือนกับการโหลดหน้าเว็บแบบเต็ม โดยใช้เหตุการณ์ pageshow และตรวจสอบพร็อพเพอร์ตี้ persisted อีกครั้ง แต่อาจไม่ใช่สิ่งที่ควรทำเสมอไป โปรดดูเอกสารประกอบของผู้ให้บริการโฆษณาเกี่ยวกับวิธีเรียกใช้การโหลดโฆษณาซ้ำ
ข้อมูลเพิ่มเติมเกี่ยวกับ bfcache
ดูข้อมูลเพิ่มเติมเกี่ยวกับ bfcache ได้ที่คำแนะนำทางเทคนิคแบบครอบคลุมเกี่ยวกับ bfcache
ความคิดเห็น
เรายินดีรับฟังความคิดเห็นเกี่ยวกับการเปลี่ยนแปลงนี้ ซึ่งคุณสามารถแสดงความคิดเห็นได้ในเครื่องมือติดตามปัญหาของ Chrome โดยใช้คอมโพเนนต์ bfcache
บทสรุป
เรายินดีที่จะนำประโยชน์ของ bfcache มาใช้กับหน้าเว็บจำนวนมากขึ้นเพื่อปรับปรุงประสบการณ์การใช้งานหน้าเว็บสำหรับผู้ใช้ เราได้พิจารณาการเปลี่ยนแปลงนี้อย่างรอบคอบแล้ว และแนวทางของเรามุ่งที่จะเปิดตัวการเปลี่ยนแปลงนี้ในลักษณะที่ปลอดภัยที่สุดเท่าที่จะเป็นไปได้ เราหวังว่าข้อมูลที่ระบุไว้ที่นี่จะช่วยให้นักพัฒนาแอปเข้าใจการเปลี่ยนแปลงนี้และทำการเปลี่ยนแปลงที่จำเป็นเพื่อหลีกเลี่ยงปัญหาเมื่อเกิดกรณีนี้ขึ้น