ภายใน 2-3 เดือน เว็บไซต์ข่าวชั้นนําของสหราชอาณาจักรปรับปรุง CLS ของเปอร์เซ็นไทล์ 75 ได้ 250% จาก 0.25 เป็น 0.1
ปัญหาความเสถียรของภาพ
การเปลี่ยนแปลงเลย์เอาต์อาจทำให้เกิดความไม่สะดวกอย่างมาก ที่ Telegraph Media Group (TMG) ความเสถียรของภาพมีความสำคัญอย่างยิ่งเนื่องจากผู้อ่านส่วนใหญ่ใช้แอปพลิเคชันของเราเพื่อรับข่าวสาร หากเลย์เอาต์เปลี่ยนไปขณะอ่านบทความ ผู้อ่านก็อาจไม่ทราบว่าอ่านถึงตรงไหนแล้ว ซึ่งอาจทำให้ผู้ใช้ได้รับประสบการณ์การใช้งานที่น่าหงุดหงิดและน่ารำคาญ
จากมุมมองวิศวกร การตรวจสอบว่าหน้าเว็บไม่เลื่อนและรบกวนผู้อ่านอาจเป็นเรื่องยาก โดยเฉพาะเมื่อโหลดพื้นที่ของแอปพลิเคชันแบบไม่พร้อมกันและเพิ่มลงในหน้าเว็บแบบไดนามิก
เรามีทีมหลายทีมที่มีส่วนร่วมในโค้ดฝั่งไคลเอ็นต์ที่ TMG ดังนี้
- วิศวกรหลัก การใช้โซลูชันของบุคคลที่สามเพื่อขับเคลื่อนส่วนต่างๆ เช่น การแนะนำเนื้อหาและการเขียนความคิดเห็น
- การตลาด ทำการทดสอบ A/B เพื่อประเมินวิธีที่ผู้อ่านโต้ตอบกับฟีเจอร์หรือการเปลี่ยนแปลงใหม่
- การโฆษณา การจัดการคําขอโฆษณาและการเสนอราคาล่วงหน้าสําหรับโฆษณา
- บรรณาธิการ การฝังโค้ดภายในบทความ เช่น ทวีตหรือวิดีโอ รวมถึงวิดเจ็ตที่กำหนดเอง (เช่น เครื่องมือติดตามผู้ติดเชื้อโคโรนาไวรัส)
การทำให้แต่ละทีมเหล่านี้ไม่ทำให้เลย์เอาต์ของหน้าเว็บกระโดดไปมานั้นเป็นเรื่องยาก การใช้เมตริกการเปลี่ยนเลย์เอาต์แบบสะสมเพื่อวัดความถี่ที่การเปลี่ยนแปลงนี้เกิดขึ้นกับผู้อ่านช่วยให้ทีมได้รับข้อมูลเชิงลึกเพิ่มเติมเกี่ยวกับประสบการณ์การใช้งานจริงของผู้ใช้และเป้าหมายที่ชัดเจนที่ควรมุ่งมั่น ส่งผลให้ CLS ของเปอร์เซ็นต์ไทล์ 75 เพิ่มขึ้นจาก 0.25 เป็น 0.1 และกลุ่มที่ผ่านเกณฑ์เพิ่มขึ้นจาก 57% เป็น 72%
250%
การปรับปรุง CLS ของเปอร์เซ็นไทล์ที่ 75
15%
ผู้ใช้ที่มีคะแนน CLS ดีมากขึ้น
จุดเริ่มต้น
เมื่อใช้หน้าแดชบอร์ดของ CrUX เราพบว่าหน้าเว็บมีการย้ายตำแหน่งมากกว่าที่เราต้องการ
เราต้องการให้ผู้อ่านอย่างน้อย 75% ได้รับประสบการณ์การใช้งานที่ "ดี" ดังนั้นเราจึงเริ่มระบุสาเหตุของเลย์เอาต์ที่ไม่เสถียร
วิธีที่เราวัดการเปลี่ยนแปลงเลย์เอาต์
เราใช้ Chrome DevTools และ WebPageTest ร่วมกันเพื่อช่วยระบุสาเหตุที่ทำให้เลย์เอาต์เปลี่ยน ในเครื่องมือสำหรับนักพัฒนาซอฟต์แวร์ เราใช้ส่วนประสบการณ์การใช้งานของแท็บประสิทธิภาพเพื่อไฮไลต์อินสแตนซ์แต่ละรายการของเลย์เอาต์ที่เปลี่ยนไป และผลกระทบต่อคะแนนโดยรวม
WebPageTest จะไฮไลต์ตําแหน่งที่เลย์เอาต์เปลี่ยนในมุมมองไทม์ไลน์เมื่อเลือก "ไฮไลต์การเปลี่ยนเลย์เอาต์"
หลังจากตรวจสอบการเปลี่ยนแปลงของเทมเพลตที่มีการเข้าชมมากที่สุดแต่ละรายการแล้ว เราจึงได้รวบรวมรายการไอเดียในการปรับปรุง
การลดการเปลี่ยนแปลงเลย์เอาต์
เรามุ่งเน้นที่ 4 ด้านที่ช่วยลดการเปลี่ยนแปลงเลย์เอาต์ได้ ซึ่งได้แก่ adverts (โฆษณา) รูปภาพ ส่วนหัว และเนื้อหาที่ฝัง
โฆษณา
โฆษณาจะโหลดหลังจากการวาดภาพครั้งแรกผ่าน JavaScript คอนเทนเนอร์บางรายการที่โหลดไว้ไม่มีความสูงที่สงวนไว้
แม้ว่าเราจะไม่ทราบความสูงที่แน่นอน แต่ก็สามารถจองพื้นที่ได้โดยใช้ขนาดโฆษณาที่พบบ่อยที่สุดซึ่งโหลดในช่อง
เราประเมินความสูงเฉลี่ยของโฆษณาไม่ถูกต้องในบางกรณี สำหรับโปรแกรมอ่านแท็บเล็ต ช่องจะยุบ
เรากลับมาดูช่องนี้อีกครั้งและปรับความสูงให้ใช้ขนาดที่พบบ่อยที่สุด
รูปภาพ
รูปภาพจำนวนมากในเว็บไซต์มีการโหลดแบบ Lazy Load และมีการจัดสรรพื้นที่ไว้สำหรับรูปภาพเหล่านั้น
อย่างไรก็ตาม รูปภาพในบรรทัดด้านบนของบทความไม่มีการจัดสรรพื้นที่ในคอนเทนเนอร์ รวมถึงไม่มีแอตทริบิวต์ความกว้างและความสูงที่เชื่อมโยงกับแท็ก ซึ่งทำให้เลย์เอาต์เปลี่ยนขณะที่โหลด
เพียงเพิ่มแอตทริบิวต์ความกว้างและความสูงลงในรูปภาพก็ช่วยให้เลย์เอาต์ไม่เปลี่ยน
ส่วนหัว
ส่วนหัวอยู่ใต้เนื้อหาในมาร์กอัปและอยู่ด้านบนโดยใช้ CSS แนวคิดเดิมคือจัดลําดับความสําคัญของการโหลดเนื้อหาก่อนการนําทาง แต่ทําให้หน้าเว็บเปลี่ยนเป็นระยะเวลาสั้นๆ
การย้ายส่วนหัวไปไว้ที่ด้านบนของมาร์กอัปช่วยให้หน้าเว็บแสดงผลได้โดยไม่ต้องมีการเลื่อน
การฝัง
ชิ้นงานแบบฝังที่ใช้บ่อยบางรายการมีสัดส่วนที่กำหนดไว้ เช่น วิดีโอ YouTube ขณะโหลดโปรแกรมเล่น เราจะดึงภาพปกจาก YouTube และใช้ภาพดังกล่าวเป็นตัวยึดตำแหน่งขณะที่วิดีโอโหลด
การวัดผลลัพธ์
เราวัดผลลัพธ์ที่ระดับฟีเจอร์ได้ค่อนข้างง่ายโดยใช้เครื่องมือที่กล่าวถึงในช่วงต้นบทความ แต่เราต้องการวัด CLS ทั้งในระดับเทมเพลตและระดับเว็บไซต์ ในการสังเคราะห์ เราใช้ SpeedCurve เพื่อตรวจสอบการเปลี่ยนแปลงทั้งในช่วงก่อนเข้าสู่ช่วงการเผยแพร่และช่วงเผยแพร่
จากนั้นเราจะตรวจสอบผลลัพธ์ในข้อมูล RUM (ได้จาก mPulse) ได้เมื่อโค้ดเข้าสู่เวอร์ชันที่ใช้งานจริง
การตรวจสอบข้อมูล RUM ช่วยให้เรามีความมั่นใจในระดับที่ดีว่าการเปลี่ยนแปลงที่เราทำอยู่ส่งผลเชิงบวกต่อผู้อ่าน
ตัวเลขสุดท้ายที่เราดูคือข้อมูล RUM ที่ Google รวบรวม ซึ่งมีความเกี่ยวข้องอย่างยิ่งในตอนนี้เนื่องจากในเร็วๆ นี้ จะมีผลต่อการจัดอันดับหน้าเว็บ ในการเริ่มต้น เราใช้รายงาน UX ของ Chrome ทั้งในรูปแบบข้อมูลระดับต้นทางรายเดือนที่มีผ่านแดชบอร์ด CrUX รวมถึงการค้นหาใน BigQuery เพื่อดึงข้อมูล p75 ที่ผ่านมา วิธีนี้ช่วยให้เราเห็นว่าCLS ของเปอร์เซ็นไทล์ 75 เพิ่มขึ้น 250% จาก 0.25 เป็น 0.1 และกลุ่มที่ผ่านเกณฑ์เพิ่มขึ้นจาก 57% เป็น 72% สำหรับการเข้าชมทั้งหมดที่ CrUX วัดได้
นอกจากนี้ เรายังใช้ประโยชน์จาก Chrome UX Report API และสร้างแดชบอร์ดภายในบางส่วนที่แยกออกเป็นเทมเพลต
การหลีกเลี่ยงการถดถอยของ CLS
สิ่งสำคัญในการปรับปรุงประสิทธิภาพคือการหลีกเลี่ยงการถดถอย เราได้ตั้งค่างบประมาณด้านประสิทธิภาพพื้นฐานสําหรับเมตริกหลักและรวม CLS ไว้ในงบประมาณเหล่านั้นแล้ว
หากการทดสอบมีค่าใช้จ่ายเกินงบประมาณ ระบบจะส่งข้อความไปยังแชแนล Slack เพื่อให้เราตรวจสอบสาเหตุได้ นอกจากนี้ เรายังได้ตั้งค่ารายงานรายสัปดาห์ไว้ด้วย เพื่อให้เราทราบถึงการเปลี่ยนแปลงที่ส่งผลเสียแม้ว่าเทมเพลตจะยังอยู่ในงบประมาณก็ตาม
นอกจากนี้ เรายังวางแผนที่จะขยายงบประมาณเพื่อใช้ข้อมูล RUM และข้อมูลสังเคราะห์โดยใช้ mPulse เพื่อตั้งค่าทั้งการแจ้งเตือนแบบคงที่และการตรวจหาความผิดปกติที่อาจเกิดขึ้น ซึ่งจะช่วยให้เราทราบถึงการเปลี่ยนแปลงที่ผิดปกติ
เราต้องคำนึงถึง CLS เมื่อพัฒนาฟีเจอร์ใหม่ การเปลี่ยนแปลงหลายอย่างที่ฉันพูดถึงคือการเปลี่ยนแปลงที่เราจำเป็นต้องแก้ไขหลังจากที่เผยแพร่ให้ผู้อ่านแล้ว ความเสถียรของเลย์เอาต์จะเป็นข้อพิจารณาในการออกแบบโซลูชันของฟีเจอร์ใหม่ในอนาคต เพื่อให้เราหลีกเลี่ยงการเปลี่ยนแปลงเลย์เอาต์ที่ไม่คาดคิดตั้งแต่เริ่มต้น
บทสรุป
การปรับปรุงที่เราทํามาจนถึงตอนนี้ทําได้ง่ายและได้ผลลัพธ์ที่ดีมาก การเปลี่ยนแปลงหลายอย่างที่ฉันได้ระบุไว้ในบทความนี้ใช้เวลาไม่นานนักและมีผลกับเทมเพลตที่ใช้กันมากที่สุดทั้งหมด ซึ่งหมายความว่าการเปลี่ยนแปลงเหล่านี้ส่งผลเชิงบวกต่อผู้อ่านของเราในวงกว้าง
ยังมีส่วนต่างๆ ของเว็บไซต์ที่เราต้องปรับปรุง เรากําลังสํารวจวิธีต่างๆ ที่อาจทําให้ใช้ตรรกะฝั่งไคลเอ็นต์ในฝั่งเซิร์ฟเวอร์ได้มากขึ้น ซึ่งจะช่วยปรับปรุง CLS ได้มากยิ่งขึ้น เราจะติดตามและตรวจสอบเมตริกของเราต่อไปโดยมีเป้าหมายเพื่อปรับปรุงเมตริกอย่างต่อเนื่องและมอบประสบการณ์การใช้งานที่ดีที่สุดให้แก่ผู้อ่าน