การปรับปรุง Cumulative Layout Shift ที่ Telegraph Media Group

ภายในไม่กี่เดือน เว็บไซต์ข่าวชั้นนำของสหราชอาณาจักรได้ปรับปรุง CLS เปอร์เซ็นไทล์ที่ 75 ขึ้น 250% จาก 0.25 เป็น 0.1

Chris Boakes

ความท้าทายด้านความเสถียรของภาพ

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

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

ที่ TMG เรามีทีมหลายทีมที่มีส่วนร่วมในการเขียนโค้ดฝั่งไคลเอ็นต์ ซึ่งได้แก่

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

การดูแลให้แต่ละทีมไม่ทำให้เลย์เอาต์ของหน้าแสดงปัญหาอาจเป็นเรื่องยาก ด้วยการใช้เมตริก Cumulative Layout Shift เพื่อวัดว่าผู้อ่านเกิดขึ้นบ่อยเท่าใด ทีมก็ได้รับข้อมูลเชิงลึกมากขึ้นเกี่ยวกับประสบการณ์ของผู้ใช้จริงและเป้าหมายที่ชัดเจนที่จะต้องพยายามทำ ซึ่งทำให้ CLS ของเปอร์เซ็นไทล์ที่ 75 เพิ่มขึ้นจาก 0.25 เป็น 0.1 และที่เก็บข้อมูลที่ส่งเพิ่มขึ้นจาก 57% เป็น 72%

จุดเริ่มต้น

การใช้แดชบอร์ด CrUX ช่วยให้เราเห็นได้ว่าหน้าเว็บมีการเปลี่ยนแปลงมากกว่าที่เราต้องการ

ตามหลักการแล้ว เราต้องการให้ผู้อ่านอย่างน้อย 75% ได้รับประสบการณ์ "ที่ดี" เราจึงเริ่มระบุสาเหตุของความไม่เสถียรของเลย์เอาต์

วิธีที่เราวัดการเปลี่ยนแปลงเลย์เอาต์

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

WebPageTest จะช่วยไฮไลต์จุดที่มีการเปลี่ยนแปลงเลย์เอาต์ในมุมมองไทม์ไลน์เมื่อเลือก "ไฮไลต์ Layout Shift" ไว้

หลังจากตรวจสอบแต่ละการเปลี่ยนแปลงของเทมเพลตที่เข้าชมบ่อยที่สุดแล้ว เราจึงมี รายการแนวคิดที่จะปรับปรุงให้ดีขึ้นได้

การลดการเปลี่ยนเลย์เอาต์

เรามุ่งเน้นที่ 4 ด้านที่เราสามารถลดการเปลี่ยนแปลงเลย์เอาต์ได้ - โฆษณา - รูปภาพ - ส่วนหัว - การฝัง

โฆษณา

โฆษณาจะโหลดหลังจากการแสดงผลครั้งแรกผ่าน JavaScript บางคอนเทนเนอร์ที่โหลดมาไม่ได้มีความสูงที่สงวนไว้

แม้เราจะไม่ทราบความสูงที่แน่ชัด แต่เราก็สามารถจองพื้นที่ได้โดยใช้ขนาดโฆษณาที่ใช้กันมากที่สุดที่โหลดในช่อง

เราตัดสินความสูงเฉลี่ยของโฆษณาผิดในบางกรณี สำหรับผู้อ่านแท็บเล็ต ช่องกำลังยุบอยู่

เราได้ตรวจสอบช่องโฆษณาอีกครั้งและปรับความสูงโดยใช้ขนาดที่ใช้กันมากที่สุด

รูปภาพ

รูปภาพจำนวนมากในเว็บไซต์โหลดแบบ Lazy Loading และสงวนพื้นที่ไว้สําหรับรูปภาพเหล่านั้น

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

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

ส่วนหัว

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

การย้ายส่วนหัวไปไว้ที่ด้านบนของมาร์กอัปทำให้หน้าแสดงผลได้โดยไม่ต้องมีการเปลี่ยนแปลงนี้

การฝัง

การฝังที่ใช้บ่อยบางรายการมีสัดส่วนภาพที่กำหนดไว้ เช่น วิดีโอ YouTube ขณะที่โปรแกรมเล่นโหลด เราจะดึงภาพขนาดย่อจาก YouTube และใช้เป็นตัวยึดตําแหน่งขณะวิดีโอโหลด

การวัดผลกระทบ

เราสามารถวัดผลกระทบในระดับฟีเจอร์ได้อย่างง่ายดายโดยใช้เครื่องมือที่กล่าวถึงในตอนต้นของบทความ อย่างไรก็ตาม เราต้องการวัด CLS ทั้งในระดับเทมเพลตและระดับเว็บไซต์ เราใช้ SpeedCurve เพื่อตรวจสอบการเปลี่ยนแปลงทั้งในขั้นตอนก่อนและเวอร์ชันที่ใช้งานจริง

จากนั้นเราจะสามารถตรวจสอบผลลัพธ์ในข้อมูล RUM ของเรา (ระบุโดย mPulse) เมื่อโค้ดถึงเวอร์ชันที่ใช้งานจริง

การตรวจสอบข้อมูล RUM ช่วยให้เรามั่นใจว่าการเปลี่ยนแปลงที่เราทำจะส่งผลดีต่อผู้อ่านของเรา

ตัวเลขสุดท้ายที่เราตรวจสอบเป็นข้อมูล RUM ที่ Google รวบรวม ซึ่งถือเป็นเรื่องเกี่ยวข้องอย่างมากในตอนนี้ เนื่องจากจะส่งผลต่อการจัดอันดับหน้าเว็บในเร็วๆ นี้ สำหรับผู้เริ่มต้น เราใช้รายงาน UX ของ Chrome ทั้งในข้อมูลระดับต้นทางรายเดือนที่พร้อมใช้งานผ่านแดชบอร์ด CrUX และการค้นหา BigQuery เพื่อดึงข้อมูล p75 ในอดีต วิธีนี้ช่วยให้เราเห็นได้ง่ายว่าสำหรับการเข้าชมทั้งหมดที่วัดโดย CrUX CLS เปอร์เซ็นไทล์ที่ 75 ของเราเพิ่มขึ้น 250% จาก 0.25 เป็น 0.1 และที่เก็บข้อมูลที่ส่งเพิ่มขึ้นจาก 57% เป็น 72%

นอกจากนี้ เรายังใช้ Chrome UX Report API และสร้างแดชบอร์ดภายในที่แยกออกเป็นเทมเพลตได้อีกด้วย

การหลีกเลี่ยง CLS การถดถอย

องค์ประกอบสำคัญของการปรับปรุงประสิทธิภาพคือการหลีกเลี่ยงความถดถอย เราได้กำหนดงบประมาณด้านประสิทธิภาพพื้นฐานบางรายการสำหรับเมตริกหลักและรวม CLS ไว้ในเมตริกเหล่านั้น

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

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

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

บทสรุป

การปรับปรุงที่เราทำจนถึงตอนนี้ค่อนข้างใช้งานง่ายและมีผลกระทบอย่างมาก การเปลี่ยนแปลงต่างๆ จำนวนมากที่เราได้สรุปไว้ในบทความนี้ใช้เวลาไม่มากนักในการนำเสนอ และได้นำไปใช้กับเทมเพลตที่ใช้กันโดยทั่วไปทั้งหมด ซึ่งหมายความว่าการเปลี่ยนแปลงเหล่านั้นส่งผลดีอย่างกว้างขวางต่อผู้อ่านของเรา

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