RAIL เป็นรูปแบบประสิทธิภาพที่เน้นผู้ใช้และมีโครงสร้างสำหรับการคิดเกี่ยวกับประสิทธิภาพ โมเดลนี้จะแบ่งประสบการณ์ของผู้ใช้ออกเป็นการดำเนินการสำคัญ (เช่น แตะ เลื่อน โหลด) และช่วยให้คุณกำหนดเป้าหมายด้านประสิทธิภาพสำหรับการกระทำแต่ละอย่างได้
RAIL ย่อมาจาก 4 แง่มุมที่แตกต่างกันของวงจรการทำงานของเว็บแอป ได้แก่ การตอบสนอง ภาพเคลื่อนไหว, การไม่มีความเคลื่อนไหว และการโหลด ผู้ใช้มีความคาดหวังด้านประสิทธิภาพที่แตกต่างกันสำหรับแต่ละบริบทเหล่านี้ ดังนั้นระบบจะกำหนดเป้าหมายด้านประสิทธิภาพตามบริบทและการวิจัย UX เกี่ยวกับมุมมองของผู้ใช้ที่มีต่อความล่าช้า
![4 ส่วนของโมเดลประสิทธิภาพแบบ RAIL ได้แก่ การตอบสนอง ภาพเคลื่อนไหว การไม่ใช้งาน และการโหลด](https://web.dev/static/articles/rail/image/the-4-parts-the-rail-per-0bf45984bc75a.png?authuser=5&hl=th)
มุ่งเน้นที่ผู้ใช้
ทำให้ผู้ใช้เป็นจุดสนใจหลักในการเพิ่มประสิทธิภาพ ตารางด้านล่างจะอธิบายเมตริกหลักเกี่ยวกับมุมมองของผู้ใช้ที่มีต่อความล่าช้าด้านประสิทธิภาพ
การรับรู้ของผู้ใช้เกี่ยวกับความล่าช้าด้านประสิทธิภาพ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 มิลลิวินาที](https://web.dev/static/articles/rail/image/diagram-showing-input-re-2349b4a3db617.png?authuser=5&hl=th)
ภาพเคลื่อนไหว: สร้างเฟรมใน 10 มิลลิวินาที
เป้าหมาย:
สร้างแต่ละเฟรมเป็นภาพเคลื่อนไหวในเวลาไม่เกิน 10 มิลลิวินาที ในทางเทคนิค งบประมาณสูงสุดสำหรับแต่ละเฟรมคือ 16 มิลลิวินาที (1,000 มิลลิวินาที / 60 เฟรมต่อวินาที ≈ 16 มิลลิวินาที) แต่เบราว์เซอร์ต้องใช้เวลาประมาณ 6 มิลลิวินาทีในการแสดงผลแต่ละเฟรม ดังนั้นหลักเกณฑ์คือ 10 มิลลิวินาทีต่อเฟรม
พยายามทำให้ภาพนุ่มนวล ผู้ใช้จะสังเกตเห็นเมื่ออัตราเฟรมแตกต่างกันไป
หลักเกณฑ์
สำหรับจุดที่มีแรงกดดันสูงอย่างภาพเคลื่อนไหว กุญแจสำคัญคือการทำอะไรสักอย่าง เท่าที่ทำไม่ได้ และเป็นจุดต่ำสุดที่ไม่สามารถทำได้ หากเป็นไปได้ ให้ใช้การตอบสนอง 100 มิลลิวินาทีเพื่อคำนวณงานที่มีค่าใช้จ่ายสูงไว้ล่วงหน้าเพื่อให้คุณมีโอกาสได้ถึงขีดจำกัดสูงสุด 60 FPS
ดูประสิทธิภาพการแสดงผลสำหรับกลยุทธ์การเพิ่มประสิทธิภาพภาพเคลื่อนไหวต่างๆ
- ภาพเคลื่อนไหว เช่น การเข้าชมและการออก เด็กที่เข้าสู่วัยรุ่น และสัญญาณบอกสถานะการโหลด
- การเลื่อน ซึ่งรวมถึงการสะบัด ซึ่งก็คือช่วงที่ผู้ใช้เริ่มเลื่อนแล้วไปต่อ และหน้าเว็บจะเลื่อนไปเรื่อยๆ
- การลาก ภาพเคลื่อนไหวมักเกิดขึ้นตามการโต้ตอบของผู้ใช้ เช่น การเลื่อนแผนที่หรือการบีบเพื่อซูม
ไม่มีการใช้งาน: เพิ่มเวลาไม่มีการใช้งานสูงสุด
เป้าหมาย: เพิ่มเวลาที่ไม่มีการใช้งานสูงสุดเพื่อเพิ่มโอกาสที่หน้าเว็บจะตอบสนองต่อข้อมูลจากผู้ใช้ภายใน 50 มิลลิวินาที
หลักเกณฑ์
ใช้เวลาที่ไม่ได้ใช้งานเพื่อทำงานที่เลื่อนเวลาออกไป เช่น ในการโหลดหน้าครั้งแรก ให้โหลดข้อมูลให้น้อยที่สุด จากนั้นใช้เวลาที่ไม่มีการใช้งานเพื่อโหลดข้อมูลที่เหลือ
ทำงานในช่วงที่ไม่มีการใช้งานไม่เกิน 50 มิลลิวินาที เป็นเวลานานขึ้น และคุณอาจเสี่ยงต่อการรบกวนการทำงานของแอปต่อการตอบสนองข้อมูลของผู้ใช้ภายใน 50 มิลลิวินาที
หากผู้ใช้โต้ตอบกับหน้าเว็บในระหว่างที่ไม่มีการใช้งาน การโต้ตอบของผู้ใช้ควรมีความสำคัญสูงสุดและขัดจังหวะการทำงานของเวลาที่ไม่มีการใช้งานเสมอ
โหลด: ส่งเนื้อหาและโต้ตอบกับผู้ใช้ได้ในไม่ถึง 5 วินาที
เมื่อหน้าเว็บโหลดช้า ความสนใจของผู้ใช้จะค่อยๆ เปลี่ยนไป และผู้ใช้ก็มองว่างานติดขัด เว็บไซต์ที่โหลดได้เร็วมีเซสชันเฉลี่ยที่ยาวนานกว่า อัตราตีกลับต่ำกว่า และมีการมองเห็นโฆษณาสูงกว่า
เป้าหมาย:
เพิ่มประสิทธิภาพเพื่อประสิทธิภาพในการโหลดที่รวดเร็วซึ่งสัมพันธ์กับความสามารถของอุปกรณ์และเครือข่ายของผู้ใช้ ปัจจุบัน เป้าหมายที่ดีสำหรับการโหลดครั้งแรกคือ การโหลดหน้าเว็บและมีการโต้ตอบภายในไม่เกิน 5 วินาที ในอุปกรณ์เคลื่อนที่ระดับกลางที่มีการเชื่อมต่อ 3G ช้า
สำหรับการโหลดครั้งต่อๆ ไป เป้าหมายที่ดีคือการโหลดหน้าเว็บภายใน 2 วินาที
หลักเกณฑ์
ทดสอบประสิทธิภาพการโหลดบนอุปกรณ์เคลื่อนที่และการเชื่อมต่อเครือข่ายที่ผู้ใช้พบบ่อย คุณอาจใช้รายงานประสบการณ์ของผู้ใช้ Chrome เพื่อดูการกระจายการเชื่อมต่อของผู้ใช้ แต่หากไม่มีข้อมูลสำหรับเว็บไซต์ของคุณ The Mobile Economy 2019 แนะนำว่าเกณฑ์พื้นฐานที่ดีทั่วโลกคือโทรศัพท์ Android ระดับกลาง เช่น Moto G4 และเครือข่าย 3G ที่ช้า (หมายถึง RTT 400 มิลลิวินาที และความเร็วในการโอนข้อมูล 400 kbps) ชุดค่าผสมนี้มีอยู่ใน WebPageTest
โปรดทราบว่าแม้อุปกรณ์ของผู้ใช้อุปกรณ์เคลื่อนที่โดยทั่วไปอาจอ้างว่าใช้การเชื่อมต่อ 2G, 3G หรือ 4G แต่ในความเป็นจริง ความเร็วในการเชื่อมต่อที่มีประสิทธิภาพมักจะช้ากว่ามากเนื่องจากการสูญเสียแพ็กเก็ตและความแปรปรวนของเครือข่าย
คุณไม่จำเป็นต้องโหลดทุกอย่างภายใน 5 วินาทีเพื่อสร้างการรับรู้ถึงการโหลดที่สมบูรณ์ ลองใช้รูปภาพการโหลดแบบ Lazy Loading, กลุ่ม JavaScript ที่แยกโค้ด และการเพิ่มประสิทธิภาพอื่นๆ ที่แนะนำใน web.dev
เครื่องมือสำหรับวัด RAIL
มีเครื่องมือ 2-3 อย่างที่จะช่วยให้คุณวัด RAIL ได้โดยอัตโนมัติ คุณจะใช้วิธีใดนั้นขึ้นอยู่กับประเภทข้อมูลที่ต้องการและประเภทเวิร์กโฟลว์ที่ต้องการ
เครื่องมือสำหรับนักพัฒนาเว็บใน Chrome
เครื่องมือสำหรับนักพัฒนาเว็บใน Chrome ให้การวิเคราะห์เชิงลึกเกี่ยวกับทุกอย่างที่เกิดขึ้นขณะที่หน้าเว็บโหลดหรือเรียกใช้ ดูเริ่มต้นใช้งานการวิเคราะห์ประสิทธิภาพรันไทม์เพื่อทำความคุ้นเคยกับ UI ของแผงประสิทธิภาพ
ฟีเจอร์ต่อไปนี้เกี่ยวข้องกับเครื่องมือสำหรับนักพัฒนาเว็บโดยเฉพาะ
ควบคุม CPU เพื่อจำลองอุปกรณ์ที่มีประสิทธิภาพน้อยกว่า
ควบคุมเครือข่ายเพื่อจำลองการเชื่อมต่อที่ช้าลง
ดูกิจกรรมของเทรดหลักเพื่อดูทุกเหตุการณ์ที่เกิดขึ้นในเทรดหลักขณะที่คุณบันทึก
ดูกิจกรรมเทรดหลักในตารางเพื่อจัดเรียงกิจกรรมตามกิจกรรมที่ใช้เวลามากที่สุด
วิเคราะห์เฟรมต่อวินาที (FPS) เพื่อวัดว่าภาพเคลื่อนไหวทำงานได้ราบรื่นจริงไหม
ตรวจสอบการใช้งาน CPU, ขนาดฮีปของ JS, โหนด DOM, เลย์เอาต์ต่อวินาที และอื่นๆ แบบเรียลไทม์ด้วยเครื่องมือตรวจสอบประสิทธิภาพ
แสดงภาพคำขอเครือข่ายที่เกิดขึ้นขณะที่คุณบันทึกในส่วนเครือข่าย
จับภาพหน้าจอขณะบันทึกเพื่อแสดงลักษณะของหน้าเว็บในขณะที่โหลดหน้าเว็บ หรือภาพเคลื่อนไหวเริ่มทำงาน และอื่นๆ
ดูการโต้ตอบเพื่อระบุอย่างรวดเร็วว่าเกิดอะไรขึ้นในหน้าเว็บหลังจากที่ผู้ใช้โต้ตอบด้วย
ค้นหาปัญหาด้านประสิทธิภาพการเลื่อนแบบเรียลไทม์ด้วยการไฮไลต์หน้าทุกครั้งที่ Listener ที่อาจมีปัญหาเริ่มทำงาน
ดูเหตุการณ์สีในแบบเรียลไทม์เพื่อระบุเหตุการณ์สีที่มีค่าใช้จ่ายสูงซึ่งอาจเป็นอันตรายต่อประสิทธิภาพของภาพเคลื่อนไหว
ประภาคาร
Lighthouse มีใน Chrome DevTools, ที่ PageSpeed Insights, เป็นส่วนขยาย Chrome, โมดูล Node.js และภายใน WebPageTest เพียงคุณใส่ URL ให้ URL นั้นจำลองอุปกรณ์ระดับกลางที่มีการเชื่อมต่อ 3G ที่ช้า เรียกใช้ชุดการตรวจสอบในหน้าเว็บ จากนั้นส่งรายงานประสิทธิภาพการโหลด ตลอดจนคำแนะนำเกี่ยวกับวิธีปรับปรุง
การตรวจสอบต่อไปนี้มีความเกี่ยวข้องมากเป็นพิเศษ
คำตอบ
First Input Delay สูงสุด ประมาณระยะเวลาที่แอปใช้ในการตอบสนองต่อข้อมูลจากผู้ใช้ โดยอิงตามเวลาที่ไม่ได้ใช้งานของเทรดหลัก
ไม่ได้ใช้ Listener แบบแพสซีฟเพื่อปรับปรุงประสิทธิภาพการเลื่อน
เวลาทั้งหมดในการบล็อก วัดระยะเวลารวมที่หน้าเว็บถูกบล็อกไม่ให้ตอบสนองต่อข้อมูลจากผู้ใช้ เช่น การคลิกเมาส์ การแตะหน้าจอ หรือการกดแป้นพิมพ์
เวลาในการตอบสนอง วัดว่าผู้ใช้โต้ตอบกับองค์ประกอบทั้งหมดของหน้าได้อย่างต่อเนื่องเมื่อใด
โหลด
ไม่ได้ลงทะเบียน Service Worker ที่ควบคุมหน้าเว็บและstart_url โปรแกรมทำงานของบริการสามารถแคชทรัพยากรทั่วไปในอุปกรณ์ของผู้ใช้ ซึ่งจะช่วยลดเวลาที่ใช้ในการดึงข้อมูลทรัพยากรผ่านเครือข่าย
เลื่อนเวลาโหลดรูปภาพนอกหน้าจอ เลื่อนการโหลดรูปภาพนอกหน้าจอออกไปจนกว่าจะจำเป็น
ขนาดรูปภาพที่เหมาะสม อย่าแสดงรูปภาพที่มีขนาดใหญ่กว่าขนาดที่แสดงผลในวิวพอร์ตบนอุปกรณ์เคลื่อนที่มาก
หลีกเลี่ยง DOM ที่มีขนาดใหญ่เกินไป ลดจำนวนไบต์ของเครือข่ายโดยจัดส่งเฉพาะโหนด DOM ที่จำเป็นต่อการแสดงผลหน้าเว็บเท่านั้น
WebPageTest
WebPageTest เป็นเครื่องมือประสิทธิภาพเว็บที่ใช้เบราว์เซอร์จริงในการเข้าถึงหน้าเว็บและรวบรวมเมตริกการจับเวลา ป้อน URL ที่ webpagetest.org/easy เพื่อดูรายงานโดยละเอียดเกี่ยวกับประสิทธิภาพในการโหลดของหน้าในอุปกรณ์ Moto G4 จริงที่มีการเชื่อมต่อ 3G ช้า นอกจากนี้ คุณยังกำหนดค่าให้รวมการตรวจสอบ Lighthouse ได้ด้วย
สรุป
RAIL เป็นเลนส์ที่ใช้พิจารณาประสบการณ์ของผู้ใช้เว็บไซต์ในฐานะเส้นทาง ที่ประกอบด้วยการโต้ตอบที่แตกต่างกัน ทำความเข้าใจมุมมองของผู้ใช้ที่มีต่อเว็บไซต์ของคุณเพื่อตั้งเป้าหมายด้านประสิทธิภาพที่ส่งผลต่อประสบการณ์ของผู้ใช้มากที่สุด
มุ่งเน้นที่ผู้ใช้
ตอบสนองต่อข้อมูลจากผู้ใช้ภายใน 100 มิลลิวินาที
สร้างเฟรมที่ใช้เวลาน้อยกว่า 10 มิลลิวินาทีเมื่อเคลื่อนไหวหรือเลื่อน
เพิ่มเวลาไม่มีการใช้งานของเทรดหลัก
โหลดเนื้อหาแบบอินเทอร์แอกทีฟที่ใช้เวลาน้อยกว่า 5,000 มิลลิวินาที