สิ่งที่นักพัฒนาซอฟต์แวร์จำเป็นต้องทราบเกี่ยวกับโหมดหน่วยความจำและโหมดประหยัดพลังงานของ Chrome

Philip Walton

Chrome 108 เปิดตัว 2 โหมดใหม่ ได้แก่ โหมดประหยัดหน่วยความจำและโหมดประหยัดพลังงาน เพื่อให้ผู้ใช้ควบคุมวิธีที่ Chrome ใช้ทรัพยากรระบบของตนได้มากขึ้น

แม้ว่าโหมดใหม่เหล่านี้จะแสดงต่อผู้ใช้เป็นหลัก แต่ก็มีนัยสำคัญที่นักพัฒนาเว็บควรทราบ เนื่องจากอาจส่งผลต่อประสบการณ์ของผู้ใช้ในเว็บไซต์ได้

โพสต์นี้จะครอบคลุมผลกระทบที่อาจมีจากโหมดใหม่เหล่านี้และสิ่งที่นักพัฒนาเว็บทำเพื่อมอบประสบการณ์ที่ดีที่สุดได้

โหมดประหยัดหน่วยความจำ

เมื่อเปิดใช้โหมดการประหยัดหน่วยความจำ Chrome จะทิ้งแท็บที่ไม่ได้ใช้งานในพื้นหลังมาระยะหนึ่งแล้ว ซึ่งจะช่วยเพิ่มหน่วยความจำสำหรับแท็บที่ใช้งานอยู่ รวมถึงแอปพลิเคชันอื่นๆ ที่อาจทำงานอยู่ ผู้ใช้สามารถสั่ง Chrome ไม่ให้ทิ้งแท็บของบางเว็บไซต์ได้ อย่างไรก็ตาม วิธีนี้เป็นค่ากำหนดของผู้ใช้ ไม่ใช่สิ่งที่คุณสามารถควบคุมในฐานะนักพัฒนาซอฟต์แวร์ได้

เมื่อยกเลิกแท็บแล้ว ชื่อและไอคอน Fav จะยังคงปรากฏในแนวแท็บ แต่หน้าเว็บจะหายไปเอง เหมือนกับว่าแท็บปิดอยู่ตามปกติ หากผู้ใช้ไปที่แท็บนั้นอีกครั้ง หน้าเว็บจะโหลดซ้ำโดยอัตโนมัติ

สำหรับหน้าเนื้อหาเพียงอย่างเดียว การทิ้งและการโหลดแท็บซ้ำมักไม่ส่งผลกระทบต่อประสบการณ์ของผู้ใช้ แต่สำหรับเว็บไซต์แบบอินเทอร์แอกทีฟที่มีขั้นตอนการใช้งานที่ซับซ้อน การโหลดซ้ำระหว่างขั้นตอนดังกล่าวอาจทำให้รู้สึกหงุดหงิดอย่างมากหากเว็บไซต์คืนค่าหน้าเว็บในจุดที่ผู้ใช้ค้างไว้ไม่ได้

การยกเลิกแท็บเพื่อประหยัดหน่วยความจำเป็นการดำเนินการที่ Chrome ได้ทำมาหลายปีแล้ว แต่การทำเช่นนี้จะเกิดขึ้นเฉพาะในกรณีที่ระบบมีหน่วยความจำไม่พอ เนื่องจากเหตุการณ์ดังกล่าวเกิดขึ้นค่อนข้างน้อย นักพัฒนาเว็บจึงอาจไม่ทราบว่าเกิดอะไรขึ้น

ตั้งแต่ Chrome 108 เป็นต้นไป การลบแท็บจะเริ่มเป็นที่นิยมมากขึ้น เว็บไซต์ต่างๆ จึงจำเป็นต้องจัดการกับเหตุการณ์เหล่านี้ได้อย่างลงตัว

แนวทางปฏิบัติแนะนำในการจัดการกับการทิ้งแท็บ

การยกเลิกแท็บไม่ใช่เรื่องใหม่สําหรับนักพัฒนาเว็บ เป็นไปได้เสมอที่ผู้ใช้จะสามารถโหลดหน้าเว็บซ้ำได้ ไม่ว่าจะตั้งใจหรือไม่ได้ตั้งใจก่อนที่จะทำงานนั้นเสร็จ เว็บไซต์จึงควรเก็บสถานะผู้ใช้ไว้เพื่อให้กู้คืนได้หากผู้ใช้ออกและกลับเข้ามาใหม่

ข้อควรพิจารณาที่สำคัญที่สุดคือไม่ใช่จะจัดเก็บสถานะผู้ใช้ แต่ควรเก็บไว้เมื่อใด และนี่เป็นกุญแจสำคัญเนื่องจากไม่มีเหตุการณ์ที่เริ่มทำงานเมื่อทิ้งแท็บไป นักพัฒนาซอฟต์แวร์จึงไม่สามารถตอบสนองต่อข้อเท็จจริงที่เกิดขึ้นได้ แต่นักพัฒนาแอปต้องคาดการณ์ถึงความเป็นไปได้นี้และเตรียมตัวล่วงหน้า

เวลาที่ดีที่สุดในการจัดเก็บสถานะผู้ใช้คือ

  • การเปลี่ยนแปลงสถานะเป็นระยะๆ
  • เมื่อใดก็ตามที่แท็บอยู่ในเบื้องหลัง (เหตุการณ์ visibilitychange)

เวลาที่แย่ที่สุดในการจัดเก็บสถานะคือ

  • ในโค้ดเรียกกลับของเหตุการณ์ beforeunload
  • ในโค้ดเรียกกลับของเหตุการณ์ unload

นี่คือช่วงเวลาที่เลวร้ายที่สุดในการจัดเก็บสถานะ เนื่องจากเหตุการณ์เหล่านี้ไม่น่าเชื่อถือเลย และไม่สามารถเริ่มทำงานได้ในหลายๆ สถานการณ์ รวมถึงเมื่อมีการทิ้งแท็บ

คุณสามารถดูแผนภาพเหตุการณ์ตลอดอายุการใช้งานหน้าเว็บได้เพื่อดูว่าเหตุการณ์ใดที่คาดว่าจะเริ่มทำงานเมื่อมีการทิ้งหน้าเว็บ คุณจะเห็นจากแผนภาพดังกล่าว แท็บอาจเปลี่ยนจากสถานะ "ซ่อน" เป็น "ยกเลิกแล้ว" โดยไม่มีเหตุการณ์เริ่มทํางาน

สถานะและโฟลว์เหตุการณ์ของ Lifecycle API หน้า การนำเสนอภาพขั้นตอนการดำเนินการของรัฐและเหตุการณ์ต่างๆ ซึ่งอธิบายตลอดทั้งเอกสารนี้

ที่จริงแล้ว เมื่อใดก็ตามที่หน้าเว็บอยู่ในสถานะ "ซ่อน" ไม่มีการรับประกันว่าเหตุการณ์อื่นๆ จะเริ่มทำงานก่อนที่เบราว์เซอร์จะถูกลบทิ้ง หรือผู้ใช้จะสิ้นสุดการทำงาน ด้วยเหตุนี้คุณจึงต้องจัดเก็บสถานะผู้ใช้ที่ไม่ได้บันทึกไว้ในเหตุการณ์ 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 คุณสามารถค้นหาแท็บที่ต้องการยกเลิกจากรายการ จากนั้นคลิกยกเลิกโดยด่วนจากคอลัมน์การดำเนินการ

ภาพหน้าจอ 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 และกำหนดค่าให้ทำงานเมื่อถอดปลั๊กอุปกรณ์

หากคุณไม่มีอุปกรณ์ที่สามารถถอดปลั๊ก คุณสามารถเปิดใช้งานโหมดด้วยตนเองโดยทำตามขั้นตอนต่อไปนี้

  1. เปิดใช้แฟล็ก chrome://flags/#battery-saver-mode-available
  2. ไปที่ chrome://discards แล้วคลิกลิงก์สลับโหมดประหยัดแบตเตอรี่ (สำคัญ: ต้องเปิดใช้ธง #battery-saver-mode-available เพื่อให้ลิงก์ใช้งานได้)

ภาพหน้าจอ UI ของ chrome://discards ซึ่งแสดงตำแหน่งของลิงก์เพื่อเปิดใช้โหมดประหยัดพลังงาน

เมื่อเปิดใช้แล้ว คุณจะสามารถโต้ตอบกับเว็บไซต์และยืนยันว่าทุกอย่างมีรูปลักษณ์ตามที่ควรจะเป็น เช่น ภาพเคลื่อนไหวและการเปลี่ยนภาพจะทำงานด้วยความเร็วที่ต้องการ

สรุป

แม้ว่าโหมดประหยัดหน่วยความจำและโหมดประหยัดพลังงานของ Chrome จะเป็นฟีเจอร์ที่แสดงต่อผู้ใช้เป็นหลัก แต่ก็มีผลเสียต่อนักพัฒนาแอปเนื่องจากอาจส่งผลเสียต่อประสบการณ์ในการเข้าชมเว็บไซต์หากไม่ได้รับการจัดการอย่างถูกต้อง

โดยทั่วไป โหมดใหม่เหล่านี้ออกแบบมาโดยคำนึงถึงแนวทางปฏิบัติแนะนำของนักพัฒนาซอฟต์แวร์อยู่แล้ว หากนักพัฒนาซอฟต์แวร์ได้ปฏิบัติตามแนวทางปฏิบัติที่ดีที่สุดสำหรับเว็บที่มีมาอย่างยาวนาน เว็บไซต์ควรทำงานได้อย่างดีกับโหมดใหม่เหล่านี้

อย่างไรก็ตาม หากเว็บไซต์ของคุณมีแนวทางปฏิบัติใดๆ ที่กล่าวถึงในโพสต์นี้ เป็นไปได้ว่าผู้ใช้พบปัญหาที่จะเพิ่มขึ้นเมื่อเปิดใช้งาน 2 โหมดนี้เท่านั้น

และเช่นเคย วิธีที่ดีที่สุดในการยืนยันว่าคุณกำลังมอบประสบการณ์ที่ยอดเยี่ยมอยู่คือการทดสอบเว็บไซต์ซึ่งมีเงื่อนไขตรงกับเงื่อนไขของผู้ใช้ดังกล่าว