Chrome กำลังทำการเปลี่ยนแปลงเพื่ออนุญาตให้ใช้แคชย้อนกลับ/ไปข้างหน้า (bfcache) สำหรับหน้าเว็บที่ใช้ Cache-Control: no-store เมื่อทำได้อย่างปลอดภัย ดูว่าการเปลี่ยนแปลงนี้ส่งผลต่อนักพัฒนาซอฟต์แวร์อย่างไร
ข้อมูลเบื้องต้น
การตั้งค่า 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 และจนกระทั่งเมื่อเร็วๆ นี้ การทดสอบเหล่านี้ทำงานในการโหลดหน้าเว็บ 5%
เราได้เพิ่มจำนวนนี้เป็น 10% ของการโหลดหน้าเว็บในวันที่ 2 ตุลาคม และตั้งใจที่จะเพิ่มเป็น 20% ของการโหลดหน้าเว็บในเดือนพฤศจิกายน และ 50% ในช่วงต้นปีหน้า จากนั้นจึงเปิดตัวฟีเจอร์นี้อย่างเต็มรูปแบบในไม่ช้า โดยจะมีการกล่าวถึงการเลือกใช้บางอย่างในลำดับถัดไป
ข้อมูลที่ละเอียดอ่อน
แม้ว่าการวิเคราะห์ของเราแสดงให้เห็นว่าการไปยังหน้าก่อนหน้าหรือหน้าถัดไปส่วนใหญ่ไม่มีข้อมูลที่ละเอียดอ่อน จึงควรมีสิทธิ์ใช้ 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 ไม่สามารถเข้าสู่แคชย้อนหลัง" ซึ่งแสดงในเครื่องมือทดสอบ bfcache ของ Chrome DevTools
คุณสามารถใช้หน้าทดสอบ bfcache นี้เพื่อทดสอบโดยใช้และไม่ได้ใช้ Flag นี้
สิ่งที่นักพัฒนาแอปควรทราบ
แม้ว่านักพัฒนาแอปจะไม่จำเป็นต้องทำการเปลี่ยนแปลงใดๆ เพื่อให้ผู้ใช้ได้รับประโยชน์จากการใช้งาน bfcache ที่มากขึ้นนี้ แต่ก็มีบางสิ่งที่นักพัฒนาแอปอาจต้องพิจารณา ข้อมูลเหล่านี้เป็นข้อควรพิจารณาที่คล้ายกับที่เว็บไซต์อื่นๆ อาจพบในการเปิดตัว bfcache ครั้งแรกเมื่อเดือนธันวาคม 2021
ผลกระทบต่อประสิทธิภาพ
เหตุผลที่เราทำการเปลี่ยนแปลงนี้เพื่อปรับปรุงประสบการณ์การใช้งานหน้าเว็บสำหรับผู้ใช้บนเว็บ เราเห็นการปรับปรุง Core Web Vitals ที่เห็นได้ชัดเจนเมื่อเปิดตัว bfcache เป็นครั้งแรก และตอนนี้เราต้องการนําการปรับปรุงเดียวกันนี้ไปใช้กับเว็บไซต์อื่นๆ เพิ่มเติม
เจ้าของเว็บไซต์อาจเห็นว่า Core Web Vitals ดีขึ้นเมื่อมีการเปิดตัวฟีเจอร์นี้ และสามารถวัดการใช้งาน bfcache ใน CrUX รวมถึงในแดชบอร์ด CrUX
ข้อมูลวิเคราะห์ผลกระทบ
หน้าที่กู้คืนจาก 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 ไปใช้ในหน้าอื่นๆ อีกมากมายเพื่อปรับปรุงประสบการณ์การใช้งานหน้าเว็บสำหรับผู้ใช้ เราได้พิจารณาการเปลี่ยนแปลงนี้อย่างรอบคอบและแนวทางของเรามุ่งที่จะเปิดตัวการเปลี่ยนแปลงนี้อย่างปลอดภัยที่สุด เราหวังว่าข้อมูลที่เราให้ไว้ที่นี่จะช่วยให้นักพัฒนาแอปเข้าใจการเปลี่ยนแปลงนี้และทำการเปลี่ยนแปลงที่จำเป็นเพื่อหลีกเลี่ยงปัญหาที่อาจเกิดขึ้น