User-centric performance metrics
ตัวชี้วัดประสิทธิภาพที่เน้นผู้ใช้เป็นศูนย์กลาง
ช่วงนี้อยู่กับเรื่อง performance มาหลายวันละครับ เลยอยากจะเอาความรู้มาแบ่งปันกัน ในเรื่องที่ว่าแบบไหนกันที่บอกว่าเว็บเร็ว อะไรคือคำจำกัดความของคำว่า “เร็ว” และไอ้ที่บอกว่าเร็ว มันมีอะไรมาเป็นตัววัดเหรอ? วันนี้เรามาทำความเข้าใจไปพร้อมๆ กันครับ
ก่อนที่เราจะไปเรื่องของ Core Web Vitals ซี่งเป็นการเอาตัวชี้วัดนี้ไปปรับปรุงให้เว็บไซต์เรา เราจำเป็นที่จะต้องมาเข้าใจเรื่อง ตัวชี้วัดประสิทธิภาพที่เน้นผู้ใช้เป็นศูนย์กลาง กันก่อนนะครับ เพราะ Core Web Vitals ที่จะเขียนใน blog ถัดไปนั้นก็ใช้ User-centric performance metrics นี้แหละครับเป็นตัววัดผล
ลองมาดูสถานการณ์นี้กัน
- เว็บไซต์อาจจะเร็วสำหรับผู้ใช้คนหนึ่ง (บนเครือข่ายที่เร็วและอุปกรณ์ที่มีประสิทธิภาพสูง) แต่อาจช้าสำหรับผู้ใช้อีกคน (บนเครือข่ายที่ช้าและอุปกรณ์ระดับล่าง)
- เว็บไซต์สองที่อาจใช้เวลาโหลดเสร็จเท่ากัน แต่อาจ ดูเหมือน ว่าเว็บไซต์หนึ่งโหลดเร็วกว่า (หากมันโหลดเนื้อหาแบบค่อยเป็นค่อยไปแทนที่จะรอจนกว่าจะโหลดเสร็จทั้งหมดก่อนแสดงผล)
- เว็บไซต์อาจจะดูเหมือนโหลดเร็ว แต่แล้วตอบสนองช้า (หรือไม่ตอบสนองเลย) ต่อการโต้ตอบของผู้ใช้
“ประสิทธิภาพ” หรือ “ความเร็วในการทำงาน” ไม่ใช่สิ่งที่สามารถประเมินได้โดยทั่วไปว่าดีหรือไม่ดี เพราะประสิทธิภาพนั้นขึ้นอยู่กับเงื่อนไขหรือสถานการณ์ต่างๆ เช่น สภาพแวดล้อมของผู้ใช้หรืออุปกรณ์ที่ใช้ ซึ่งอาจทำให้ประสบการณ์ของผู้ใช้แต่ละคนแตกต่างกันไป ในบางกรณี สิ่งที่ดูเหมือนทำงานได้ดีสำหรับคนหนึ่ง อาจทำงานได้ไม่ดีสำหรับอีกคนหนึ่ง ทั้งหมดนี้แสดงให้เห็นว่า ประสิทธิภาพไม่ได้เป็นสิ่งที่แน่นอนและสม่ำเสมอสำหรับทุกคน แต่จะเปลี่ยนแปลงตามบริบทต่างๆ
กำหนดเกณฑ์การวัด
เมื่อก่อน เราจะวัดเว็บใดเว็บหนึ่งเรามักจะวัดด้วยระยะเวลาในการโหลดหน้าเว็บ แต่ว่าบางครั้งมันก็ไม่ได้เป็นส่วนที่ผู้ใช้งานอย่าเราๆ ต้องการส่วนนั้นสักเท่าไหร่
ตัวอย่างเช่น เว็บของผมโหลดเร็วมากแต่ว่าข้อความบางส่วนที่สำคัญยังต้องไป get มาจาก api อีกที จะเห็นว่าถึงแม้จะโหลดเร็วแต่ไหน แต่บางส่วน ส่วนที่ผู้ใช้ต้องการดูจริงๆ ก็ยังต้องไปโหลดมาอีกหลายวินาทีอยู่ดี
คำถามสี่คำถามนี้ เป็นคำถามที่เราควรพิจารณาเมื่อเริ่มปรับปรุงประสิทธิภาพของเว็บไซต์ คำถามเหล่านี้มาจาก Philip Walton และถูกใช้ในทีม Chrome รวมถึง W3C Web Performance Working Group เพื่อพัฒนามาตรฐาน API ที่ใช้ในการวัดประสิทธิภาพของเว็บจากมุมมองของผู้ใช้
- เริ่มทำงานหรือยัง? - การเข้าถึงสำเร็จหรือยัง? เซิร์ฟเวอร์ตอบสนองแล้วหรือยัง?
- ประโยชน์หรือไม่? - มีเนื้อหาเพียงพอให้ผู้ใช้สามารถดูหรือมีส่วนร่วมได้หรือยัง?
- ใช้งานได้หรือไม่? - ผู้ใช้สามารถโต้ตอบกับหน้าเว็บได้หรือไม่ หรือหน้าเว็บยังคงโหลด หรือประมวลผลอยู่?
- น่าประทับใจหรือไม่? - การโต้ตอบกับเว็บไซต์ราบรื่นหรือยังมีความล่าช้าอยู่?
ที่มาคำถามทั้งสี่ข้อด้านบนนั้น
- Philip Walton เป็นนักพัฒนาและนักวิจัยที่มีส่วนร่วมในการพัฒนามาตรฐานเว็บและเครื่องมือที่เกี่ยวข้องกับประสิทธิภาพของเว็บไซต์
- คำถามสี่ข้อที่อ้างถึงในบทความเกี่ยวกับการวัดประสิทธิภาพของเว็บไซต์จริงๆ ได้ถูกใช้ในงานของ W3C Web Performance Working Group เพื่อสร้างมาตรฐานและ API ที่ใช้ในการวัดประสิทธิภาพจากมุมมองของผู้ใช้
- ทีม Chrome รวมถึง Philip Walton และกลุ่มที่เกี่ยวข้องได้ใช้คำถามเหล่านี้ในการพัฒนามาตรฐานและเครื่องมือที่ช่วยในการวัดประสิทธิภาพเว็บอย่างถูกต้องและสอดคล้อง
คำถามทั้งสี่ข้อที่อ้างถึง (เริ่มทำงานหรือยัง, ประโยชน์หรือไม่, ใช้งานได้หรือไม่, น่าประทับใจหรือไม่) มีพื้นฐานมาจากการทำงานของ Philip Walton และกลุ่มที่เกี่ยวข้อง ซึ่งเป็นส่วนหนึ่งของความพยายามในการปรับปรุงวิธีการวัดประสิทธิภาพเว็บให้สะท้อนถึงประสบการณ์ของผู้ใช้ได้ดียิ่งขึ้น
ตัวชี้ที่วัดสำคัญในการวัดประสิทธิภาพ
จากที่กล่าวมาทั้งหมด ตัวชี้วัดที่สำคัญและเป็นที่นิยม ซึ่งอยู่ในเครื่องมือของ Google ล้วนเป็นตัวชี้วัดที่ควรนำมาใช้ประเมินประสิทธิภาพเว็บไซต์ของเราในขั้นต้น อย่างไรก็ตาม ยังมีตัวชี้วัดอื่นๆ ที่อาจไม่ได้กล่าวถึงในที่นี้
- First Contentful Paint (FCP): วัดเวลาตั้งแต่หน้าเว็บเริ่มโหลดจนกระทั่งเนื้อหาส่วนใดส่วนหนึ่งของหน้าเว็บถูกแสดงผลบนหน้าจอ
- Largest Contentful Paint (LCP): วัดเวลาตั้งแต่หน้าเว็บเริ่มโหลดจนกระทั่งบล็อกข้อความหรือรูปภาพที่ใหญ่ที่สุดถูกแสดงผลบนหน้าจอ
- Interaction to Next Paint (INP): วัดความล่าช้าของทุกการแตะ คลิก หรือการใช้แป้นพิมพ์ที่เกิดขึ้นบนหน้าเว็บ (ขึ้นอยู่กับจำนวนของการโต้ตอบ) และเลือกความล่าช้าที่มากที่สุด (หรือใกล้เคียงที่สุด) มาเป็นค่าเดียว
- Total Blocking Time (TBT): วัดระยะเวลาระหว่าง First Contentful Paint และ Time to Interactive (ตั้งแต่การโหลดข้อมูลชุดแรกจนถึงข้อมูลถูกโหลดเสร็จสิ้น)
- Cumulative Layout Shift (CLS): วัดความเสถียรในการจัดวางเลย์เอาต์ของหน้าเว็บ ซึ่งส่งผลต่อการจัดอันดับบน Google เช่น ปัญหาปุ่มเลื่อนไปมา ข้อความขนาดไม่เท่ากัน หรือข้อความที่เอียงเกินไป เป็นต้น
- Time to First Byte (TTFB): วัดระยะเวลาที่เบราว์เซอร์ของผู้ใช้รอรับเนื้อหาของเว็บไซต์ (หน้าสีขาวที่ปรากฏขึ้นเมื่อเราคลิกเปลี่ยนหน้า) เพื่อดูความเร็วของการตอบสนองของเว็บไซต์
ในบางครั้งอาจมีตัวชี้วัดอื่นๆ ที่เหมาะสมหรือมีประโยชน์สำหรับเรา แต่ตัวชี้วัดที่กล่าวถึงข้างต้นก็เพียงพอแล้วสำหรับการเริ่มต้น พบกันใหม่ในบทความหน้าครับ