Chrome 108 เปิดตัว 2 โหมดใหม่ ได้แก่ โหมดประหยัดหน่วยความจำและโหมดประหยัดพลังงาน เพื่อให้ผู้ใช้ควบคุมวิธีที่ Chrome ใช้ทรัพยากรระบบของตนได้มากขึ้น
แม้ว่าโหมดใหม่เหล่านี้จะแสดงต่อผู้ใช้เป็นหลัก แต่ก็มีนัยสำคัญที่นักพัฒนาเว็บควรทราบ เนื่องจากอาจส่งผลต่อประสบการณ์ของผู้ใช้ในเว็บไซต์ได้
โพสต์นี้จะครอบคลุมผลกระทบที่อาจมีจากโหมดใหม่เหล่านี้และสิ่งที่นักพัฒนาเว็บทำเพื่อมอบประสบการณ์ที่ดีที่สุดได้
โหมดประหยัดหน่วยความจำ
เมื่อเปิดใช้โหมดการประหยัดหน่วยความจำ Chrome จะทิ้งแท็บที่ไม่ได้ใช้งานในพื้นหลังมาระยะหนึ่งแล้ว ซึ่งจะช่วยเพิ่มหน่วยความจำสำหรับแท็บที่ใช้งานอยู่ รวมถึงแอปพลิเคชันอื่นๆ ที่อาจทำงานอยู่ ผู้ใช้สามารถสั่ง Chrome ไม่ให้ทิ้งแท็บของบางเว็บไซต์ได้ อย่างไรก็ตาม วิธีนี้เป็นค่ากำหนดของผู้ใช้ ไม่ใช่สิ่งที่คุณสามารถควบคุมในฐานะนักพัฒนาซอฟต์แวร์ได้
เมื่อยกเลิกแท็บแล้ว ชื่อและไอคอน Fav จะยังคงปรากฏในแนวแท็บ แต่หน้าเว็บจะหายไปเอง เหมือนกับว่าแท็บปิดอยู่ตามปกติ หากผู้ใช้ไปที่แท็บนั้นอีกครั้ง หน้าเว็บจะโหลดซ้ำโดยอัตโนมัติ
สำหรับหน้าเนื้อหาเพียงอย่างเดียว การทิ้งและการโหลดแท็บซ้ำมักไม่ส่งผลกระทบต่อประสบการณ์ของผู้ใช้ แต่สำหรับเว็บไซต์แบบอินเทอร์แอกทีฟที่มีขั้นตอนการใช้งานที่ซับซ้อน การโหลดซ้ำระหว่างขั้นตอนดังกล่าวอาจทำให้รู้สึกหงุดหงิดอย่างมากหากเว็บไซต์คืนค่าหน้าเว็บในจุดที่ผู้ใช้ค้างไว้ไม่ได้
การยกเลิกแท็บเพื่อประหยัดหน่วยความจำเป็นการดำเนินการที่ Chrome ได้ทำมาหลายปีแล้ว แต่การทำเช่นนี้จะเกิดขึ้นเฉพาะในกรณีที่ระบบมีหน่วยความจำไม่พอ เนื่องจากเหตุการณ์ดังกล่าวเกิดขึ้นค่อนข้างน้อย นักพัฒนาเว็บจึงอาจไม่ทราบว่าเกิดอะไรขึ้น
ตั้งแต่ Chrome 108 เป็นต้นไป การลบแท็บจะเริ่มเป็นที่นิยมมากขึ้น เว็บไซต์ต่างๆ จึงจำเป็นต้องจัดการกับเหตุการณ์เหล่านี้ได้อย่างลงตัว
แนวทางปฏิบัติแนะนำในการจัดการกับการทิ้งแท็บ
การยกเลิกแท็บไม่ใช่เรื่องใหม่สําหรับนักพัฒนาเว็บ เป็นไปได้เสมอที่ผู้ใช้จะสามารถโหลดหน้าเว็บซ้ำได้ ไม่ว่าจะตั้งใจหรือไม่ได้ตั้งใจก่อนที่จะทำงานนั้นเสร็จ เว็บไซต์จึงควรเก็บสถานะผู้ใช้ไว้เพื่อให้กู้คืนได้หากผู้ใช้ออกและกลับเข้ามาใหม่
ข้อควรพิจารณาที่สำคัญที่สุดคือไม่ใช่จะจัดเก็บสถานะผู้ใช้ แต่ควรเก็บไว้เมื่อใด และนี่เป็นกุญแจสำคัญเนื่องจากไม่มีเหตุการณ์ที่เริ่มทำงานเมื่อทิ้งแท็บไป นักพัฒนาซอฟต์แวร์จึงไม่สามารถตอบสนองต่อข้อเท็จจริงที่เกิดขึ้นได้ แต่นักพัฒนาแอปต้องคาดการณ์ถึงความเป็นไปได้นี้และเตรียมตัวล่วงหน้า
เวลาที่ดีที่สุดในการจัดเก็บสถานะผู้ใช้คือ
- การเปลี่ยนแปลงสถานะเป็นระยะๆ
- เมื่อใดก็ตามที่แท็บอยู่ในเบื้องหลัง (เหตุการณ์
visibilitychange
)
เวลาที่แย่ที่สุดในการจัดเก็บสถานะคือ
- ในโค้ดเรียกกลับของเหตุการณ์
beforeunload
- ในโค้ดเรียกกลับของเหตุการณ์
unload
นี่คือช่วงเวลาที่เลวร้ายที่สุดในการจัดเก็บสถานะ เนื่องจากเหตุการณ์เหล่านี้ไม่น่าเชื่อถือเลย และไม่สามารถเริ่มทำงานได้ในหลายๆ สถานการณ์ รวมถึงเมื่อมีการทิ้งแท็บ
คุณสามารถดูแผนภาพเหตุการณ์ตลอดอายุการใช้งานหน้าเว็บได้เพื่อดูว่าเหตุการณ์ใดที่คาดว่าจะเริ่มทำงานเมื่อมีการทิ้งหน้าเว็บ คุณจะเห็นจากแผนภาพดังกล่าว แท็บอาจเปลี่ยนจากสถานะ "ซ่อน" เป็น "ยกเลิกแล้ว" โดยไม่มีเหตุการณ์เริ่มทํางาน
ที่จริงแล้ว เมื่อใดก็ตามที่หน้าเว็บอยู่ในสถานะ "ซ่อน" ไม่มีการรับประกันว่าเหตุการณ์อื่นๆ จะเริ่มทำงานก่อนที่เบราว์เซอร์จะถูกลบทิ้ง หรือผู้ใช้จะสิ้นสุดการทำงาน ด้วยเหตุนี้คุณจึงต้องจัดเก็บสถานะผู้ใช้ที่ไม่ได้บันทึกไว้ในเหตุการณ์ visibilitychange
เสมอ เนื่องจากคุณอาจไม่ได้รับโอกาสอีก
โค้ดต่อไปนี้จะสรุปตัวอย่างตรรกะของคิวที่คงสถานะผู้ใช้ปัจจุบันไว้ทุกครั้งที่มีการเปลี่ยนแปลง หรือทันทีหากผู้ใช้ออกจากแท็บหรือออกไป
let state = {};
let hasUnstoredState = false;
function storeState() {
if (hasUnstoredState) {
// Store `state` to localStorage or IndexedDB...
}
hasUnstoredState = false;
}
export function updateState(newState) {
state = newState;
hasUnstoredState = true;
requestIdleCallback(storeState);
}
document.addEventListener('visibilitychange', () => {
if (document.visibilityState === 'hidden') {
storeState();
}
});
ตรวจพบว่ามีการทิ้งแท็บ
ดังที่กล่าวไว้ก่อนหน้านี้ จะไม่สามารถตรวจพบได้ว่าแท็บกำลังจะถูกทิ้งไป แต่สามารถตรวจพบได้ว่าแท็บถูกยกเลิกหลังจากผู้ใช้กลับมาที่แท็บนั้นและโหลดหน้าเว็บซ้ำแล้ว ในสถานการณ์เหล่านี้ พร็อพเพอร์ตี้ document.wasDiscarded
จะเป็นจริง
if (document.wasDiscarded) {
// The page was reloaded after a discard.
} else {
// The page was not reloaded after a discard.
}
หากคุณต้องการทราบว่าผู้ใช้พบกับสถานการณ์เช่นนี้บ่อยเพียงใด คุณสามารถกำหนดค่าเครื่องมือวิเคราะห์ให้บันทึกข้อมูลได้
ตัวอย่างเช่น ใน Google Analytics คุณสามารถกำหนดค่าพารามิเตอร์เหตุการณ์ที่กำหนดเองซึ่งจะช่วยให้คุณกำหนดเปอร์เซ็นต์ของการดูหน้าเว็บที่มาจากแท็บที่ถูกทิ้งได้ ดังนี้
gtag('config', 'G-XXXXXXXXXX', {
was_discarded: document.wasDiscarded,
});
หากคุณเป็นผู้ให้บริการวิเคราะห์ คุณอาจต้องพิจารณาเพิ่มมิติข้อมูลนี้ในผลิตภัณฑ์โดยค่าเริ่มต้น
การทดสอบเว็บไซต์ในโหมดประหยัดหน่วยความจำ
คุณทดสอบได้ว่าระบบทิ้งการจัดการหน้าเว็บอย่างไรโดยโหลดหน้าเว็บ จากนั้นไปที่ chrome://discards
ในแท็บหรือหน้าต่างแยกต่างหาก
จาก UI ของ chrome://discards
คุณสามารถค้นหาแท็บที่ต้องการยกเลิกจากรายการ จากนั้นคลิกยกเลิกโดยด่วนจากคอลัมน์การดำเนินการ
การดำเนินการนี้จะยกเลิกแท็บทำให้คุณสามารถกลับไปดูและยืนยันว่ามีการโหลดหน้าเว็บซ้ำในสถานะเดียวกับตอนที่ออกจากหน้าเว็บไปแล้ว
โปรดทราบว่าปัจจุบันยังไม่มีวิธีการยกเลิกแท็บโดยอัตโนมัติผ่านเครื่องมือทดสอบ เช่น Webdriver หรือ Puppeteer อย่างไรก็ตาม เนื่องจากการยกเลิกและการคืนค่าแท็บจะเหมือนกับการโหลดหน้าเว็บใหม่เกือบทั้งหมด หากคุณทดสอบว่ามีการคืนค่าสถานะผู้ใช้หลังจากโหลดซ้ำระหว่างขั้นตอนการใช้งานของผู้ใช้ ก็น่าจะเหมาะสำหรับการทิ้ง/การกู้คืนด้วยเช่นกัน ความแตกต่างหลักระหว่าง 2 อย่างนี้คือเหตุการณ์ beforeunload
, pagehide
และ unload
จะไม่เริ่มทำงานเมื่อมีการทิ้งแท็บ ตราบใดที่คุณไม่ได้พึ่งพาเหตุการณ์เหล่านั้นในการคงสถานะผู้ใช้ไว้ คุณจะใช้การโหลดซ้ำเพื่อทดสอบลักษณะการทำงานของการยกเลิก/กู้คืนได้
โหมดประหยัดพลังงาน
เมื่อเปิดใช้โหมดประหยัดพลังงาน Chrome จะช่วยสงวนพลังงานแบตเตอรี่โดยการลดอัตราการรีเฟรชจอแสดงผล ซึ่งส่งผลต่อการเลื่อน รวมถึงความแม่นยำของภาพเคลื่อนไหวและอัตราเฟรมของวิดีโอ
โดยทั่วไป นักพัฒนาแอปไม่จำเป็นต้องดำเนินการใดๆ เพื่อให้รองรับโหมดประหยัดพลังงาน CSS และ JavaScript API สำหรับภาพเคลื่อนไหว การเปลี่ยน และ requestAnimationFrame()
จะปรับตามการเปลี่ยนแปลงอัตราการรีเฟรชจอแสดงผลโดยอัตโนมัติเมื่อเปิดใช้โหมดนี้
สถานการณ์หลักที่โหมดนี้อาจเกิดปัญหาคือ เว็บไซต์ของคุณใช้ภาพเคลื่อนไหวแบบ JavaScript ซึ่งสันนิษฐานถึงอัตราการรีเฟรชหนึ่งๆ สำหรับผู้ใช้ทุกคน
ตัวอย่างเช่น หากเว็บไซต์ใช้การวนซ้ำ requestAnimationFrame()
และสมมติว่าจะผ่านไป 16.67 มิลลิวินาทีระหว่างโค้ดเรียกกลับ ภาพเคลื่อนไหวจะทำงานช้าลง 2 เท่าเมื่อเปิดใช้โหมดประหยัดพลังงาน
โปรดทราบว่านักพัฒนาซอฟต์แวร์มักคิดว่าอัตราการรีเฟรชเริ่มต้นที่ 60 Hz สำหรับผู้ใช้ทุกคนอาจเป็นปัญหาอยู่แล้ว เนื่องจากอุปกรณ์ส่วนใหญ่ในปัจจุบันไม่ได้เป็นเช่นนั้น
การวัดอัตราการรีเฟรชจอแสดงผล
ไม่มี API เว็บสำหรับวัดอัตราการรีเฟรชการแสดงผลโดยเฉพาะ แต่โดยทั่วไปแล้ว ไม่แนะนำให้พยายามวัดอัตราการรีเฟรชการแสดงผลด้วย API ปัจจุบัน
วิธีที่ดีที่สุดที่นักพัฒนาแอปสามารถทำได้กับ API ที่มีอยู่คือการเปรียบเทียบการประทับเวลาระหว่างโค้ดเรียกกลับของ requestAnimationFrame()
ที่ต่อเนื่องกัน แม้ว่าในกรณีส่วนใหญ่ วิธีนี้จะใช้เพื่อประมาณอัตราการรีเฟรช ณ เวลาหนึ่งๆ ได้ แต่จะไม่แจ้งให้คุณทราบเมื่ออัตราการรีเฟรชมีการเปลี่ยนแปลง ในการทำเช่นนั้น คุณจะต้องเรียกใช้แบบสำรวจ requestAnimationFrame()
อย่างต่อเนื่อง ซึ่งจะไม่ตรงตามเป้าหมายในการประหยัดพลังงานหรืออายุการใช้งานแบตเตอรี่ของผู้ใช้
การทดสอบเว็บไซต์ในโหมดประหยัดพลังงาน
วิธีหนึ่งในการทดสอบเว็บไซต์ในโหมดประหยัดพลังงานคือการเปิดใช้โหมดในการตั้งค่าของ Chrome และกำหนดค่าให้ทำงานเมื่อถอดปลั๊กอุปกรณ์
หากคุณไม่มีอุปกรณ์ที่สามารถถอดปลั๊ก คุณสามารถเปิดใช้งานโหมดด้วยตนเองโดยทำตามขั้นตอนต่อไปนี้
- เปิดใช้แฟล็ก
chrome://flags/#battery-saver-mode-available
- ไปที่
chrome://discards
แล้วคลิกลิงก์สลับโหมดประหยัดแบตเตอรี่ (สำคัญ: ต้องเปิดใช้ธง#battery-saver-mode-available
เพื่อให้ลิงก์ใช้งานได้)
เมื่อเปิดใช้แล้ว คุณจะสามารถโต้ตอบกับเว็บไซต์และยืนยันว่าทุกอย่างมีรูปลักษณ์ตามที่ควรจะเป็น เช่น ภาพเคลื่อนไหวและการเปลี่ยนภาพจะทำงานด้วยความเร็วที่ต้องการ
สรุป
แม้ว่าโหมดประหยัดหน่วยความจำและโหมดประหยัดพลังงานของ Chrome จะเป็นฟีเจอร์ที่แสดงต่อผู้ใช้เป็นหลัก แต่ก็มีผลเสียต่อนักพัฒนาแอปเนื่องจากอาจส่งผลเสียต่อประสบการณ์ในการเข้าชมเว็บไซต์หากไม่ได้รับการจัดการอย่างถูกต้อง
โดยทั่วไป โหมดใหม่เหล่านี้ออกแบบมาโดยคำนึงถึงแนวทางปฏิบัติแนะนำของนักพัฒนาซอฟต์แวร์อยู่แล้ว หากนักพัฒนาซอฟต์แวร์ได้ปฏิบัติตามแนวทางปฏิบัติที่ดีที่สุดสำหรับเว็บที่มีมาอย่างยาวนาน เว็บไซต์ควรทำงานได้อย่างดีกับโหมดใหม่เหล่านี้
อย่างไรก็ตาม หากเว็บไซต์ของคุณมีแนวทางปฏิบัติใดๆ ที่กล่าวถึงในโพสต์นี้ เป็นไปได้ว่าผู้ใช้พบปัญหาที่จะเพิ่มขึ้นเมื่อเปิดใช้งาน 2 โหมดนี้เท่านั้น
และเช่นเคย วิธีที่ดีที่สุดในการยืนยันว่าคุณกำลังมอบประสบการณ์ที่ยอดเยี่ยมอยู่คือการทดสอบเว็บไซต์ซึ่งมีเงื่อนไขตรงกับเงื่อนไขของผู้ใช้ดังกล่าว