วัดประสิทธิภาพด้วยโมเดล RAIL

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

RAIL ย่อมาจาก 4 ด้านที่แตกต่างกันของวงจรเว็บแอป ได้แก่ การตอบสนอง (Response) ภาพเคลื่อนไหว (Animation) ไม่มีการใช้งาน (Idle) และการโหลด (Load) ผู้ใช้มีความคาดหวังด้านประสิทธิภาพที่แตกต่างกันสำหรับแต่ละบริบทเหล่านี้ ดังนั้นเป้าหมายด้านประสิทธิภาพจึงกำหนดขึ้นตามบริบทและการวิจัย UX เกี่ยวกับวิธีที่ผู้ใช้รับรู้ถึงความล่าช้า

โมเดลประสิทธิภาพ RAIL มี 4 ส่วน ได้แก่ การตอบสนอง ภาพเคลื่อนไหว ไม่มีการใช้งาน และการโหลด
4 ส่วนของโมเดลประสิทธิภาพ RAIL

มุ่งเน้นที่ผู้ใช้

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

การรับรู้ของผู้ใช้เกี่ยวกับความล่าช้าของประสิทธิภาพ
0 ถึง 16 มิลลิวินาที ผู้ใช้ติดตามการเคลื่อนไหวได้ดีเป็นพิเศษ และไม่ชอบเมื่อภาพเคลื่อนไหวไม่ราบรื่น ผู้ใช้จะมองเห็นภาพเคลื่อนไหวที่ราบรื่นตราบใดที่มีการแสดงผลเฟรมใหม่ 60 เฟรมทุกวินาที ซึ่งเท่ากับ 16 มิลลิวินาทีต่อเฟรม รวมถึงเวลาที่เบราว์เซอร์ใช้ในการแสดงเฟรมใหม่บนหน้าจอ ทำให้แอปมีเวลาประมาณ 10 มิลลิวินาทีในการสร้างเฟรม
0 ถึง 100 มิลลิวินาที ตอบสนองต่อการดำเนินการของผู้ใช้ภายในกรอบเวลานี้ และผู้ใช้จะรู้สึกว่าผลลัพธ์เกิดขึ้นทันที หากนานกว่านั้น การเชื่อมโยงระหว่างการกระทำและปฏิกิริยาจะขาดหายไป
100 ถึง 1,000 มิลลิวินาที ภายในหน้าต่างนี้ สิ่งต่างๆ จะดูเป็นส่วนหนึ่งของความคืบหน้าของงานที่เป็นธรรมชาติและต่อเนื่อง สำหรับผู้ใช้ส่วนใหญ่บนเว็บ การโหลดหน้าเว็บหรือการเปลี่ยนมุมมองแสดงถึงงาน
1,000 มิลลิวินาทีขึ้นไป หากเกิน 1,000 มิลลิวินาที (1 วินาที) ผู้ใช้จะเสียสมาธิจากงานที่กำลังทำอยู่
10,000 มิลลิวินาทีขึ้นไป หากเกิน 10,000 มิลลิวินาที (10 วินาที) ผู้ใช้จะรู้สึกหงุดหงิดและมีแนวโน้มที่จะละทิ้งงาน โดยที่ผู้ใช้เหล่านั้นอาจกลับมาหรือไม่กลับมาอีกก็ได้

เป้าหมายและหลักเกณฑ์

ในบริบทของ RAIL คำว่าเป้าหมายและหลักเกณฑ์มีความหมายที่เฉพาะเจาะจง ดังนี้

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

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

การตอบสนอง: ประมวลผลเหตุการณ์ภายใน 50 มิลลิวินาที

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

หลักเกณฑ์

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

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

  • สำหรับการดำเนินการที่ใช้เวลานานกว่า 50 มิลลิวินาทีจึงจะเสร็จสมบูรณ์ ให้แสดงความคิดเห็นเสมอ

50 มิลลิวินาทีหรือ 100 มิลลิวินาที

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

แผนภาพแสดงวิธีจัดคิวอินพุตที่ได้รับระหว่างงานที่ไม่มีการใช้งาน ซึ่งจะลดเวลาในการประมวลผลอินพุตที่พร้อมใช้งานลงเหลือ 50 มิลลิวินาที
งานที่ไม่มีการใช้งานส่งผลต่องบประมาณการตอบสนองต่ออินพุตอย่างไร

ภาพเคลื่อนไหว: สร้างเฟรมใน 10 มิลลิวินาที

เป้าหมาย

  • สร้างแต่ละเฟรมในภาพเคลื่อนไหวภายใน 10 มิลลิวินาทีหรือน้อยกว่า ในทางเทคนิคแล้ว งบประมาณสูงสุดสำหรับแต่ละเฟรมคือ 16 มิลลิวินาที (1,000 มิลลิวินาที / 60 เฟรมต่อวินาที ≈ 16 มิลลิวินาที) แต่เบราว์เซอร์ต้องใช้เวลาประมาณ 6 มิลลิวินาทีในการแสดงผลแต่ละเฟรม จึงเป็นที่มาของหลักเกณฑ์ 10 มิลลิวินาทีต่อเฟรม

  • ตั้งเป้าให้ภาพมีความลื่นไหล ผู้ใช้จะสังเกตเห็นเมื่ออัตราเฟรมแตกต่างกัน

หลักเกณฑ์

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

  • ดูประสิทธิภาพการแสดงผลสำหรับกลยุทธ์การเพิ่มประสิทธิภาพภาพเคลื่อนไหวต่างๆ

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

ไม่มีการใช้งาน: เพิ่มเวลาที่ไม่มีการใช้งานให้ได้มากที่สุด

เป้าหมาย: เพิ่มเวลาที่ไม่มีการใช้งานให้มากที่สุดเพื่อเพิ่มโอกาสที่หน้าเว็บจะตอบสนองต่ออินพุตของผู้ใช้ภายใน 50 มิลลิวินาที

หลักเกณฑ์

  • ใช้เวลาที่ไม่มีการใช้งานเพื่อทำงานที่เลื่อนออกไปให้เสร็จ เช่น สำหรับการโหลดหน้าเว็บครั้งแรก ให้โหลดข้อมูลให้น้อยที่สุด จากนั้นใช้เวลาที่ไม่มีการใช้งานเพื่อโหลดส่วนที่เหลือ

  • ทำงานในช่วงที่ไม่มีการใช้งานภายใน 50 มิลลิวินาทีหรือน้อยกว่านั้น หากนานกว่านั้น คุณอาจรบกวนความสามารถของแอปในการตอบสนองต่ออินพุตของผู้ใช้ภายใน 50 มิลลิวินาที

  • หากผู้ใช้โต้ตอบกับหน้าเว็บระหว่างการทำงานในเวลาที่ไม่มีการใช้งาน การโต้ตอบของผู้ใช้ควรมีความสำคัญสูงสุดเสมอและขัดจังหวะการทำงานในเวลาที่ไม่มีการใช้งาน

โหลด: แสดงเนื้อหาและพร้อมให้โต้ตอบได้ภายในไม่เกิน 5 วินาที

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

เป้าหมาย

หลักเกณฑ์

เครื่องมือสำหรับวัด RAIL

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

เครื่องมือสำหรับนักพัฒนาเว็บใน Chrome

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

ฟีเจอร์ DevTools ต่อไปนี้มีความเกี่ยวข้องเป็นพิเศษ

ประภาคาร

Lighthouse พร้อมใช้งานในเครื่องมือสำหรับนักพัฒนาเว็บใน Chrome, ที่ PageSpeed Insights, เป็นส่วนขยาย Chrome, เป็นโมดูล Node.js และภายใน WebPageTest คุณระบุ URL แล้วเครื่องมือจะจำลองอุปกรณ์ระดับกลางที่มีการเชื่อมต่อ 3G ที่ช้า เรียกใช้ชุดการตรวจสอบในหน้าเว็บ แล้วแสดงรายงานเกี่ยวกับประสิทธิภาพการโหลด รวมถึงคำแนะนำเกี่ยวกับวิธีปรับปรุง

การตรวจสอบต่อไปนี้มีความเกี่ยวข้องเป็นพิเศษ

คำตอบ

โหลด

WebPageTest

WebPageTest เป็นเครื่องมือวัดประสิทธิภาพเว็บที่ใช้เบราว์เซอร์จริงเพื่อเข้าถึงหน้าเว็บและรวบรวมเมตริกเวลา ป้อน URL ที่ webpagetest.org/easy เพื่อดูรายงานโดยละเอียดเกี่ยวกับประสิทธิภาพการโหลดของหน้าในอุปกรณ์ Moto G4 จริงที่มีการเชื่อมต่อ 3G ที่ช้า นอกจากนี้ คุณยังกำหนดค่าให้รวมการตรวจสอบ Lighthouse ได้ด้วย

สรุป

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

  • มุ่งเน้นที่ผู้ใช้

  • ตอบสนองต่อการป้อนข้อมูลของผู้ใช้ภายใน 100 มิลลิวินาที

  • สร้างเฟรมในเวลาไม่ถึง 10 มิลลิวินาทีเมื่อแสดงภาพเคลื่อนไหวหรือเลื่อน

  • เพิ่มเวลาที่ไม่มีการใช้งานเทรดหลักให้มากที่สุด

  • โหลดเนื้อหาแบบอินเทอร์แอกทีฟภายใน 5,000 มิลลิวินาที