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

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

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

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

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

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

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

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

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

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

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

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

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

หลักเกณฑ์

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

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

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

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

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

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

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

เป้าหมาย

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

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

หลักเกณฑ์

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

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

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

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

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

หลักเกณฑ์

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

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

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

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

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

เป้าหมาย

หลักเกณฑ์

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

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

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

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

ฟีเจอร์ต่อไปนี้ของเครื่องมือสำหรับนักพัฒนาเว็บมีความเกี่ยวข้องเป็นพิเศษ

ประภาคาร

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 มิลลิวินาที