กรณีศึกษาเกี่ยวกับการเปลี่ยนแปลงที่ GoDaddy นำมาใช้เพื่อปรับปรุงประสิทธิภาพของเว็บไซต์หลายล้านเว็บไซต์ ซึ่งช่วยให้เว็บไซต์เหล่านั้นได้รับคะแนน PageSpeed Insights และ Core Web Vitals ที่ดี
GoDaddy เป็นแพลตฟอร์มบริการที่ใหญ่ที่สุดในโลกสําหรับผู้ประกอบการทั่วโลก เรามีพันธกิจในการส่งเสริมชุมชนลูกค้าทั่วโลกกว่า 20 ล้านรายและผู้ประกอบการทุกที่ด้วยการให้ความช่วยเหลือและเครื่องมือทั้งหมดที่จำเป็นต่อการเติบโตบนโลกออนไลน์
ในปี 2019 GoDaddy ได้เปิดตัวเว็บไซต์ + การตลาดโดยมุ่งมั่นที่จะมอบเครื่องมือและบริการที่ใช้งานง่ายและช่วยให้เจ้าของธุรกิจบรรลุเป้าหมาย เว็บไซต์ + การตลาดผสานรวมการสร้างเว็บไซต์เข้ากับเครื่องมือการตลาดและอีคอมเมิร์ซ รวมถึงคำแนะนำที่ดีที่สุดเพื่อช่วยให้ลูกค้าประสบความสำเร็จในธุรกิจใหม่
นับตั้งแต่เปิดตัว "เว็บไซต์และการตลาด" ประสิทธิภาพถือเป็นส่วนสําคัญของผลิตภัณฑ์และเป็นสิ่งที่เราตรวจสอบและดำเนินการอย่างสม่ำเสมอ บทความนี้จะกล่าวถึงเส้นทางของ GoDaddy จากการใช้การทดสอบประสิทธิภาพในห้องทดลองไปจนถึงการใช้ข้อมูลการใช้งานจริงกับ Core Web Vitals และชุดการปรับปรุงผลิตภัณฑ์เพื่อให้เว็บไซต์ของลูกค้าผ่านเกณฑ์ด้วยคะแนนสูงมาก
การติดตามประสิทธิภาพด้วย Lighthouse
เราใช้ข้อมูล Lighthouse ในการติดตามประสิทธิภาพ ทุกครั้งที่เผยแพร่เว็บไซต์บนแพลตฟอร์ม เราจะวัดประสิทธิภาพโดยใช้เครื่องมือภายในชื่อ "Lighthouse4u" ซึ่งให้บริการ Google Lighthouse https://github.com/godaddy/lighthouse4u ข้อมูลนี้ช่วยให้เราทราบประสิทธิภาพโดยทั่วไปของเว็บไซต์ในการตั้งค่าห้องทดลอง
เนื่องจากเว็บไซต์หลายล้านแห่งที่เราโฮสต์บนแพลตฟอร์มของเรามีฟีเจอร์และเนื้อหาที่หลากหลาย จึงจำเป็นต้องรวมข้อมูลประสิทธิภาพเข้ากับข้อมูลเมตาเกี่ยวกับแต่ละเว็บไซต์ที่ทดสอบ (เช่น เทมเพลตที่ใช้ ประเภทวิดเจ็ตที่แสดงผล และอื่นๆ) ข้อมูลนี้ช่วยให้เราสรุปได้ว่าฟีเจอร์ใดของเว็บไซต์มีประสิทธิภาพต่ำกว่า ทั้งยังให้ข้อมูลเชิงลึกเกี่ยวกับจุดที่ควรปรับปรุง
ตัวอย่างเช่น ข้อมูลนี้ช่วยให้เราทราบว่า "โมดัลป๊อปอัป" ส่งผลเสียต่อความเร็วหน้าเว็บ โดยเว็บไซต์ที่มีฟีเจอร์นี้มีประสิทธิภาพต่ำกว่าเว็บไซต์ที่ไม่มี 12 จุด หลังจากอัปเดตโค้ดเพื่อเลื่อนการโหลด JavaScript ออกไป คะแนน Lighthouse ของเราเพิ่มขึ้น 2 คะแนน เรานำสิ่งที่ได้เรียนรู้นี้ไปใช้กับฟีเจอร์อื่นๆ เช่น "แบนเนอร์คุกกี้" ที่แสดงผลหลังจากโหลดหน้าเว็บไม่นาน
นอกจากการตรวจสอบเว็บไซต์ที่มีปัญหาตามฟีเจอร์แล้ว เรายังทำการวิเคราะห์แพ็กเกจ JavaScript และพบว่าขนาดส่วนใหญ่มาจากทรัพยากรภายนอก (immutable.js และ draft.js) เราลดขนาด Bundle ด้วยการปรับโครงสร้างผู้บริโภคให้โหลดทรัพยากรตามต้องการแบบ Lazy Load การดำเนินการนี้ส่งผลให้ขนาดกลุ่ม JavaScript ทั่วไปลดลงกว่า 50% จากกว่า 200 KB เหลือประมาณ 90 KB (ไฟล์ที่ผ่านการย่อขนาด) ขนาดกลุ่มที่เล็กลงช่วยให้เบราว์เซอร์โหลดชิ้นงานภายนอกและเรียกใช้สคริปต์ที่สำคัญได้เร็วขึ้นในวงจรการโหลดเว็บไซต์ครั้งแรก ซึ่งส่งผลให้ Largest Contentful Paint (LCP) และ First Input Delay (FID) เพิ่มขึ้น
ความพยายามอย่างต่อเนื่องของเราทําให้คะแนน Lighthouse ของเว็บไซต์ลูกค้าโดยเฉลี่ยเพิ่มขึ้นจากประมาณ 40 คะแนนในเดือนพฤศจิกายน 2020 เป็นมากกว่า 70 คะแนนในเดือนพฤษภาคม 2021 อย่างไรก็ตาม บางครั้งการพยายามของเราก็ใช้ไม่ได้ผล และบางครั้งเราก็ประหลาดใจเมื่อผลลัพธ์ที่ได้ไม่สอดคล้องกันเสมอไประหว่างสิ่งที่ทดสอบในสภาพแวดล้อมการทดสอบในเครื่องกับผลลัพธ์ที่เราได้รับในสนาม ผลลัพธ์จากห้องทดลองมีประโยชน์มาก แต่ถึงเวลาแล้วที่เราจะมุ่งเน้นที่ประสบการณ์ของผู้ใช้จริงที่สังเกตได้จริง
การติดตามข้อมูลผู้ใช้จริงด้วย Core Web Vitals
หลังจากเพิ่มไลบรารี web-vitals ลงในเว็บไซต์ของลูกค้าแล้ว เราวัดข้อมูลในอุปกรณ์จริงจากผู้เข้าชมจริงได้ โดยฮาร์ดแวร์ ความเร็วของเครือข่าย การโต้ตอบของผู้ใช้ (เช่น การเลื่อนหรือคลิก) ไม่ได้อยู่ในพื้นฐานที่สอดคล้องกันเหมือนในการตั้งค่าห้องทดลองโดยใช้ Lighthouse นี่เป็นก้าวสําคัญในทิศทางที่ถูกต้อง เนื่องจากตอนนี้เรามีข้อมูลที่แสดงถึงสิ่งที่ผู้เข้าชมเว็บไซต์ได้รับ
มุ่งเน้นที่จุดอ่อนที่สุดของเรา: Cumulative Layout Shift (CLS)
การวิเคราะห์ข้อมูลใหม่ทำให้เรามีมุมมองใหม่เกี่ยวกับสิ่งที่ต้องทำเพื่อปรับปรุงความเร็วของเว็บไซต์ เนื่องจากการปรับปรุงคะแนน Lighthouse ทำให้ LCP ของเปอร์เซ็นต์ไทล์ 75 คือ 860 มิลลิวินาที และ FID ที่เกณฑ์เดียวกันคือต่ำกว่า 10 มิลลิวินาที เราจึงมีอัตราผ่านสูงสำหรับเมตริกเหล่านี้ในเว็บไซต์ของลูกค้า ซึ่งได้แก่ 78% และ 98% ตามลำดับ อย่างไรก็ตาม ตัวเลขการเปลี่ยนเลย์เอาต์สะสม (CLS) ดูแตกต่างออกไปมากจากที่เราเคยเห็นใน Lighthouse CLS ที่เปอร์เซ็นต์ไทล์ 75 คือ 0.17 ซึ่งสูงกว่าเกณฑ์ 0.1 ในการ "ผ่าน" และอัตราผ่านของเราจึงอยู่ที่ 47% เท่านั้นในเว็บไซต์ทั้งหมด
เมตริกดังกล่าวทำให้อัตราการผ่านโดยรวมลดลงเหลือ 40% เราจึงตัดสินใจตั้งเป้าหมายที่ท้าทายเพื่อเพิ่มตัวเลขดังกล่าวให้สูงกว่า 60% ภายในสิ้นเดือนสิงหาคม 2021 ซึ่งเราต้องมุ่งเน้นที่ CLS
ในชีวิตจริง ผู้ใช้โต้ตอบกับหน้าเว็บและเลื่อนผ่านเนื้อหา "เหนือครึ่งหน้าบน" ซึ่งเป็นสิ่งที่ Core Web Vitals จับภาพได้ดีกว่า CLS แตกต่างจากข้อมูลในห้องทดลองและภาคสนามเนื่องจากความแปรปรวนของวิธีที่ผู้ใช้โต้ตอบกับเว็บไซต์ขณะที่โหลดครั้งแรก
เส้นทางสู่การผ่าน Core Web Vitals ทั้งหมด
การปรับปรุงประสิทธิภาพต้องใช้การลองผิดลองถูก และการพยายามแต่ละครั้งอาจไม่ได้ผลตามที่คาดหวังเสมอไป อย่างไรก็ตาม ต่อไปนี้คือตัวอย่างการปรับปรุงที่ช่วยให้บรรลุเป้าหมาย
การจองพื้นที่สำหรับการโหลดรูปภาพช่วยเพิ่มคะแนน CLS ของเราได้อย่างมากเนื่องจากช่วยป้องกันไม่ให้เนื้อหาที่อยู่ใต้รูปภาพเลื่อน เราใช้พร็อพเพอร์ตี้ aspect-ratio ของ CSS เพื่อแก้ไขปัญหานี้ในเบราว์เซอร์ที่รองรับ สำหรับอุปกรณ์ที่ไม่มีความละเอียดระดับดังกล่าว เราจะโหลดรูปภาพตัวยึดตําแหน่งแบบโปร่งใสที่แคชไว้และมีขนาดใหญ่เพียงไม่กี่ไบต์ จึงโหลดได้เกือบจะทันที
ลักษณะการทํางานของรูปภาพทั่วไปนี้ช่วยให้เราคํานวณความสูงของรูปภาพสุดท้ายล่วงหน้าในระหว่างการแสดงผลฝั่งเซิร์ฟเวอร์ โดยอิงตามความกว้างของวิวพอร์ตและสัดส่วนภาพของรูปภาพ การดำเนินการนี้ส่งผลให้มาร์กอัป HTML มีการจัดสรรพื้นที่แนวตั้งไว้อย่างเหมาะสมสำหรับรูปภาพสุดท้าย การปรับปรุงนี้เห็นได้ชัดในอุปกรณ์เคลื่อนที่ เนื่องจากระบบจะแสดงผลรูปภาพให้เต็มความกว้างของวิวพอร์ตบนอุปกรณ์เคลื่อนที่
คอมโพเนนต์บางอย่างในเว็บไซต์ของลูกค้ามีเนื้อหาแบบไดนามิก (เช่น รายการรีวิวของลูกค้าภายนอก) และไม่สามารถแปลงเป็น CSS ล้วนๆ เพื่อใช้ประโยชน์จากข้อดีด้านประสิทธิภาพของการแสดงผลฝั่งเซิร์ฟเวอร์ พื้นที่เหล่านี้เป็นพื้นที่ที่ปรับปรุงการเปลี่ยนแปลงเลย์เอาต์ได้ยากเนื่องจากเนื้อหา (และส่วนสูง) จะแตกต่างกันไป ในกรณีดังกล่าว เราจะรวมคอมโพเนนต์ไว้ในคอนเทนเนอร์ที่มี min-height ที่กำหนดไว้ล่วงหน้าโดยอิงตามการสังเกตความสูงเฉลี่ยของคอมโพเนนต์แต่ละรายการ ระบบจะนำ min-height ออกเมื่อคอมโพเนนต์แบบไดนามิกภายในแสดงผลเสร็จแล้ว แม้ว่าจะยังไม่สมบูรณ์แบบ แต่โซลูชันนี้ช่วยให้เราลดการเปลี่ยนแปลงเลย์เอาต์ได้อย่างมาก
แม้จะมุ่งเน้นที่การปรับปรุง CLS แต่เราก็ยังคงทํางานเกี่ยวกับ LCP อย่างต่อเนื่อง ในเว็บไซต์จํานวนมาก รูปภาพคือผู้ร้ายรายใหญ่ที่สุดที่ทําให้ LCP ช้า และเราเห็นว่านี่เป็นจุดที่ต้องปรับปรุงอย่างชัดเจน เราได้ทำการปรับปรุงการโหลดรูปภาพแบบ Lazy Load โดยใช้ IntersectionObserver แต่พบว่าไม่ได้ตั้งค่าขนาดรูปภาพในลักษณะที่เหมาะสมที่สุดสำหรับจุดพักแต่ละจุด (อุปกรณ์เคลื่อนที่ แท็บเล็ต เดสก์ท็อป เดสก์ท็อปขนาดใหญ่) เราจึงอัปเดตโค้ดการสร้างรูปภาพเพื่อจำกัดและปรับขนาดรูปภาพตามจุดพัก จากนั้นจึงปรับขนาดความละเอียดอีกครั้งตามความหนาแน่นของพิกเซล ตัวอย่างเช่น การดำเนินการนี้ทำให้รูปภาพขนาดใหญ่รูปหนึ่งมีขนาดเล็กลงจาก 192 KB เป็น 102 KB
เราได้เพิ่มโค้ดเพื่อลดคุณภาพรูปภาพแบบไดนามิกตามความเร็วในการเชื่อมต่อเพื่อให้แสดงผลเว็บไซต์ในอุปกรณ์ที่มีการเชื่อมต่อเครือข่ายไม่ดีได้อย่างรวดเร็ว ซึ่งทำได้โดยใช้พร็อพเพอร์ตี้ downlink ที่ navigator.connection แสดงผล เราใช้พารามิเตอร์การค้นหาตาม URL เพื่อลดคุณภาพรูปภาพผ่าน API ชิ้นงานตามสภาพเครือข่ายเหล่านั้น
เว็บไซต์ของลูกค้าบางส่วนจะโหลดแบบไดนามิก เนื่องจากเราทราบส่วนที่จะแสดงผลในเว็บไซต์หนึ่งๆ เมื่อเผยแพร่แล้ว เราจึงใช้rel=preconnect คำแนะนำทรัพยากรเพื่อเริ่มต้นการเชื่อมต่อและการจับมือที่จำเป็นล่วงหน้า นอกจากนี้ เรายังใช้คำแนะนำทรัพยากรเพื่อโหลดแบบอักษรและทรัพยากรสำคัญอื่นๆ อย่างรวดเร็วด้วย
เมื่อสร้างเว็บไซต์ ลูกค้าจะเพิ่มส่วนต่างๆ ซึ่งอาจมีสคริปต์ในบรรทัดเพื่อใช้ฟังก์ชันการทำงานที่แตกต่างกัน การมีสคริปต์เหล่านี้ในบรรทัดทั่วทั้งหน้า HTML อาจไม่เหมาะสําหรับประสิทธิภาพเสมอไป เราตัดสินใจที่จะย้ายสคริปต์เหล่านี้ไว้ภายนอกเพื่อให้เบราว์เซอร์โหลดและแยกวิเคราะห์เนื้อหาสคริปต์แบบไม่พร้อมกัน นอกจากนี้ คุณยังแชร์สคริปต์ที่ย้ายออกใหม่ไปยังหน้าต่างๆ ได้ด้วย ซึ่งช่วยให้ได้ประสิทธิภาพเพิ่มขึ้นในรูปแบบแคชของเบราว์เซอร์และ CDN เราเก็บสคริปต์ที่สำคัญไว้กับโค้ดเพื่อให้เบราว์เซอร์แยกวิเคราะห์และดำเนินการได้เร็วขึ้น
ผลลัพธ์
ผลลัพธ์ที่ได้จากการมุ่งเน้นที่ CLS นั้นคุ้มค่ามาก อัตราที่ผ่าน Core Web Vitals เพิ่มขึ้นจากประมาณ 40% เป็นเกือบ 70% ซึ่งถือเป็นการปรับปรุงที่ 75%
เมื่อผู้ใช้กลับมาที่แพลตฟอร์มของเราเพื่ออัปเดตและเผยแพร่เว็บไซต์อีกครั้ง ผู้ใช้จะได้รับประสิทธิภาพที่ปรับปรุงล่าสุด และส่งผลให้จำนวนเว็บไซต์ที่ "ผ่าน Core Web Vitals" เพิ่มขึ้นอย่างต่อเนื่องดังที่แสดงในแผนภูมิด้านล่าง
สรุป
การค้นหาจุดที่ควรปรับปรุงประสิทธิภาพและการติดตามความคืบหน้าให้ประสบความสําเร็จนั้นขึ้นอยู่กับเครื่องมือที่ใช้วัดผลเป็นอย่างมาก แม้ว่า Lighthouse จะมีประโยชน์ในการวัดประสิทธิภาพส่วนบนของหน้าใน "การตั้งค่าห้องทดลอง" แต่ก็ไม่ได้บันทึกปัญหาด้านประสิทธิภาพที่เกิดขึ้นจากการโต้ตอบของผู้ใช้เท่านั้น (เช่น การเลื่อนหน้าเว็บ) อย่างถูกต้อง
การติดตาม Core Web Vitals ในชีวิตจริงด้วยข้อมูลเมตาช่วยให้เราเห็นภาพ กำหนดเป้าหมาย และวัดผลลัพธ์ของการปรับปรุงได้ เส้นทางในการปรับปรุงคะแนน Core Web Vitals ช่วยให้ทีมระบุและแทนที่รูปแบบที่ไม่มีประสิทธิภาพซึ่งพบในโค้ดเบสของเราได้ บางครั้งการเปลี่ยนแปลงที่ดูเหมือนจะดีกลับไม่ได้ให้ผลตามที่คาดหวังไว้ และบางครั้งก็เกิดผลตรงกันข้าม โลกนี้ไม่ได้สมบูรณ์แบบ คุณจึงต้องพยายามต่อไป