เมตริกประสิทธิภาพที่ยึดผู้ใช้เป็นศูนย์กลาง

เราต่างได้ยินว่าประสิทธิภาพสำคัญเพียงใด แต่เมื่อเราพูดถึงประสิทธิภาพ และการทำให้เว็บไซต์ "โหลดเร็ว" เราหมายถึงอะไร

แต่ความจริงก็คือประสิทธิภาพนั้นสัมพันธ์กัน

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

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

แต่การที่เมตริกอิงตามเกณฑ์ที่เป็นรูปธรรมและสามารถวัดในเชิงปริมาณได้ ไม่ได้หมายความว่าการวัดเหล่านั้นมีประโยชน์เสมอไป

การกำหนดเมตริก

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

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

ในช่วง 2-3 ปีที่ผ่านมา สมาชิกในทีม Chrome ซึ่งทำงานร่วมกับคณะทำงานเพื่อประสิทธิภาพของเว็บ W3C ได้ทำงานเพื่อสร้างมาตรฐานให้กับชุด API และเมตริกใหม่ๆ ที่วัดประสิทธิภาพของหน้าเว็บได้แม่นยำขึ้น

เรากำหนดกรอบคำถามที่สำคัญ 2-3 ข้อเพื่อให้แน่ใจว่าเมตริกมีความเกี่ยวข้องกับผู้ใช้

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

วิธีวัดเมตริก

โดยทั่วไปแล้ว เมตริกประสิทธิภาพจะวัดด้วย 1 ใน 2 วิธีต่อไปนี้

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

แต่ละตัวเลือกไม่มีดีหรือแย่เสมอไป กล่าวคือโดยทั่วไปคุณต้องการใช้ทั้ง 2 ตัวเลือกเพื่อประสิทธิภาพที่ดี

ในห้องทดลอง

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

ในพื้นที่

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

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

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

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

ประเภทของเมตริก

มีเมตริกประเภทอื่นๆ อีกหลายประเภทที่เกี่ยวข้องกับมุมมองของผู้ใช้ในประสิทธิภาพ

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

เมื่อพิจารณาจากเมตริกประสิทธิภาพทุกประเภทข้างต้น เราเห็นได้อย่างชัดเจนว่าไม่มีเมตริกเดียวเพียงพอที่จะบันทึกลักษณะประสิทธิภาพทั้งหมดของหน้าเว็บ

เมตริกสำคัญที่ต้องวัด

  • First Contentful Paint (FCP): วัดระยะเวลาตั้งแต่ที่หน้าเว็บเริ่มโหลดจนถึงตอนที่เนื้อหาส่วนใดส่วนหนึ่งของหน้าแสดงบนหน้าจอ (lab, ฟิลด์)
  • Largest Contentful Paint (LCP): วัดระยะเวลาตั้งแต่ที่หน้าเว็บเริ่มโหลดจนถึงตอนที่แสดงผลองค์ประกอบบล็อกข้อความหรือองค์ประกอบรูปภาพที่ใหญ่ที่สุดบนหน้าจอ (lab, ฟิลด์)
  • First Input Delay (FID): วัดระยะเวลาตั้งแต่ที่ผู้ใช้โต้ตอบกับเว็บไซต์ของคุณเป็นครั้งแรก (เมื่อผู้ใช้คลิกลิงก์ แตะปุ่ม หรือใช้การควบคุมที่กำหนดเองที่ขับเคลื่อนโดย JavaScript) ไปจนถึงตอนที่เบราว์เซอร์ตอบสนองต่อการโต้ตอบนั้นได้จริง (ฟิลด์)
  • การโต้ตอบกับ Next Paint (INP): วัดเวลาในการตอบสนองทุกครั้งที่แตะ การคลิก หรือการโต้ตอบด้วยแป้นพิมพ์กับหน้าเว็บ และเลือกเวลาในการตอบสนองของการโต้ตอบที่แย่ที่สุดของหน้าเว็บ (หรือใกล้เคียงกับค่าสูงสุด) เป็นค่าตัวแทนค่าเดียวเพื่ออธิบายการตอบสนองโดยรวมของหน้าเว็บ (lab, ฟิลด์)
  • เวลาในการบล็อกทั้งหมด (TBT): วัดระยะเวลารวมระหว่าง FCP กับ TTI ที่เทรดหลักถูกบล็อกเป็นเวลานานพอที่จะป้องกันการตอบสนองของอินพุต (ห้องทดลอง)
  • Cumulative Layout Shift (CLS): วัดคะแนนสะสมของการเปลี่ยนเลย์เอาต์ที่ไม่คาดคิดทั้งหมดซึ่งเกิดขึ้นระหว่างเวลาที่หน้าเว็บเริ่มโหลดและเมื่อสถานะวงจรเปลี่ยนเป็นซ่อนไว้ (lab, ฟิลด์)
  • Time to First Byte (TTFB): วัดระยะเวลาที่เครือข่ายใช้ตอบกลับคำขอของผู้ใช้ด้วยไบต์แรกของทรัพยากร (lab, ฟิลด์)

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

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

เมตริกที่กำหนดเอง

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

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

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

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