วัดประสิทธิภาพด้วยโมเดล 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 มิลลิวินาที