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

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

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

4 ส่วนของโมเดลประสิทธิภาพแบบ RAIL ได้แก่ การตอบสนอง ภาพเคลื่อนไหว การไม่ใช้งาน และการโหลด
ทั้ง 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 มิลลิวินาที เพื่อให้ผู้ใช้รู้สึกว่าการโต้ตอบเกิดขึ้นทันที

หลักเกณฑ์

  • โปรดประมวลผลเหตุการณ์การป้อนข้อมูลของผู้ใช้ภายใน 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

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

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

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

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

ประภาคาร

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

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

คำตอบ

โหลด

WebPageTest

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

สรุป

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

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

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

  • สร้างเฟรมที่ใช้เวลาน้อยกว่า 10 มิลลิวินาทีเมื่อเคลื่อนไหวหรือเลื่อน

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

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