กรณีศึกษาเกี่ยวกับการเปลี่ยนแปลงที่ GoDaddy นำไปใช้เพื่อปรับปรุงประสิทธิภาพเว็บไซต์สำหรับเว็บไซต์นับล้านๆ แห่ง ช่วยให้เว็บไซต์เหล่านั้นได้รับคะแนน PageSpeed Insights และ Core Web Vitals ที่ดี
GoDaddy เป็นแพลตฟอร์มบริการที่ใหญ่ที่สุดของโลกสำหรับผู้ประกอบการทั่วโลก เรามุ่งมั่นที่จะส่งเสริมชุมชนลูกค้ากว่า 20 ล้านคนและผู้ประกอบการกว่า 20 ล้านคนทั่วโลกด้วยการให้ความช่วยเหลือและเครื่องมือทั้งหมดที่จำเป็นต่อการเติบโตในโลกออนไลน์
ในปี 2019 GoDaddy ได้เปิดตัว "เว็บไซต์ + การตลาด" ด้วยความมุ่งมั่นที่จะมอบเครื่องมือและบริการที่ใช้งานง่ายและช่วยให้เจ้าของธุรกิจบรรลุเป้าหมายของตน เว็บไซต์ + การตลาดผสานรวมการสร้างเว็บไซต์เข้ากับเครื่องมือทางการตลาดและอีคอมเมิร์ซ และจับคู่เข้ากับคำแนะนำที่ดีที่สุดเพื่อช่วยให้ลูกค้าประสบความสำเร็จในธุรกิจใหม่ๆ
นับตั้งแต่การเปิดตัวเว็บไซต์ + การตลาด ประสิทธิภาพก็เป็นส่วนสำคัญของผลิตภัณฑ์และเป็นสิ่งที่ได้รับการตรวจสอบและทำงานอย่างต่อเนื่อง ในบทความนี้ เราจะทบทวนเส้นทางของ GoDaddy จากการใช้การทดสอบประสิทธิภาพในห้องปฏิบัติการไปจนถึงการใช้ข้อมูลในชีวิตจริงด้วย Core Web Vitals และชุดการปรับปรุงต่างๆ ที่เกิดขึ้นกับผลิตภัณฑ์เพื่อให้ได้รับอัตราการส่งผ่านที่สูงมากสำหรับเว็บไซต์ของลูกค้า
การติดตามประสิทธิภาพด้วย Lighthouse
เราอาศัยข้อมูลของ Lighthouse ในการติดตามประสิทธิภาพ ทุกครั้งที่มีการเผยแพร่เว็บไซต์บนแพลตฟอร์ม เราจะวัดประสิทธิภาพของเว็บไซต์โดยใช้เครื่องมือภายในชื่อ "Lighthouse4u" ซึ่งให้บริการ Google Lighthouse เป็นบริการ https://github.com/godaddy/lighthouse4u ข้อมูลนี้เป็นตัวชี้วัดที่ดีเกี่ยวกับประสิทธิภาพโดยทั่วไปของเว็บไซต์ในการตั้งค่าห้องทดลอง
เนื่องจากเว็บไซต์นับล้านที่เราโฮสต์ในแพลตฟอร์มของเรามีฟีเจอร์และเนื้อหาที่หลากหลาย คุณจึงต้องรวมข้อมูลประสิทธิภาพเข้ากับข้อมูลเมตาเกี่ยวกับแต่ละเว็บไซต์ที่ทดสอบ (เช่น เทมเพลตที่ใช้ ประเภทวิดเจ็ตที่แสดงผล และอื่นๆ) การทำเช่นนี้ช่วยให้เราสามารถสรุปว่าคุณลักษณะใดของเว็บไซต์ที่มีประสิทธิภาพต่ำ และยังให้ข้อมูลเชิงลึกว่าควรปรับปรุงในด้านใด
ตัวอย่างเช่น ข้อมูลนี้ช่วยให้เราระบุได้ว่า "โมดัลป๊อปอัป" มีผลกระทบเชิงลบต่อความเร็วของหน้าเว็บ เว็บไซต์ที่มีฟีเจอร์นี้มีประสิทธิภาพต่ำกว่าที่ไม่มีอยู่ 12 คะแนน หลังจากอัปเดตโค้ดเพื่อเลื่อนการโหลด JavaScript แล้ว เราได้ปรับปรุงคะแนน Lighthouse ขึ้น 2 คะแนน เรานำการเรียนรู้นี้ไปใช้กับฟีเจอร์อื่นๆ ได้ เช่น "แบนเนอร์คุกกี้" ที่แสดงผลไม่นานหลังการโหลดหน้าเว็บ
นอกจากการตรวจสอบเว็บไซต์ที่เป็นปัญหาจากฟีเจอร์แล้ว เรายังได้ทำการวิเคราะห์กลุ่ม JavaScript และพบว่าเนื้อหาจำนวนมากมาจากทรัพยากร Dependency ภายนอก (immutable.js และ draft.js) เราลดขนาดแพ็กเกจโดยปรับโครงสร้างผู้บริโภคให้เป็นแบบ Lazy Load Dependency แบบออนดีมานด์ ส่งผลให้ขนาดกลุ่ม 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% ตามลำดับ อย่างไรก็ตาม ตัวเลขของ Cumulative Layout Shift (CLS) จะแตกต่างจาก Lighthouse CLS ของเราที่เปอร์เซ็นไทล์ที่ 75 คือ 0.17 ซึ่งสูงกว่าเกณฑ์ 0.1 เพื่อ "ผ่าน" ดังนั้นอัตราการผ่านของเราจึงเป็นเพียง 47% จากทั่วทั้งเว็บไซต์ของเรา
เมตริกดังกล่าวส่งผลให้อัตราการผ่านโดยรวมของเราลดลงเหลือ 40% เราจึงตัดสินใจที่จะตั้งเป้าหมายที่ทะเยอทะยานเพื่อเพิ่มตัวเลขดังกล่าวให้สูงกว่า 60% ภายในสิ้นเดือนสิงหาคม 2021 เราจึงต้องมุ่งเน้นที่ CLS
ในชีวิตจริง ผู้ใช้โต้ตอบกับหน้าเว็บและเลื่อนผ่านเนื้อหา "ครึ่งหน้าบน" ซึ่งเป็นสิ่งที่ Core Web Vitals ตรวจจับได้ดีกว่า เนื่องจากความแปรปรวนของวิธีที่ผู้ใช้โต้ตอบกับเว็บไซต์ขณะโหลดครั้งแรก CLS จึงแตกต่างจากข้อมูลห้องปฏิบัติการและข้อมูลภาคสนาม
เส้นทางสู่การส่งผ่าน Core Web Vitals ทั้งหมด
การปรับปรุงประสิทธิภาพต้องอาศัยการลองผิดลองถูก และความพยายามทุกครั้งอาจไม่ได้ผลอย่างที่คาดไว้ อย่างไรก็ตาม ต่อไปนี้เป็นการปรับปรุงที่ช่วยให้เราบรรลุเป้าหมายได้
การจองพื้นที่ในการโหลดรูปภาพทำให้คะแนน CLS ดีขึ้นอย่างมาก เนื่องจากจะทำให้เนื้อหาที่อยู่ใต้รูปภาพไม่ขยับ เราใช้พร็อพเพอร์ตี้ CSS aspect-ratio เพื่อจัดการกับเบราว์เซอร์ที่รองรับ สำหรับผู้ที่ไม่มีเนื้อหา เราได้โหลดรูปภาพตัวยึดตำแหน่งแบบโปร่งใสที่ถูกแคชไว้และมีขนาดเพียงไม่กี่ไบต์ ซึ่งโหลดได้แทบจะในทันที
ลักษณะการทำงานทั่วไปของรูปภาพนี้ช่วยให้เราคำนวณความสูงของรูปภาพสุดท้ายได้ล่วงหน้าในระหว่างการแสดงผลฝั่งเซิร์ฟเวอร์ โดยอิงตามความกว้างของวิวพอร์ตและสัดส่วนภาพ ซึ่งทำให้มาร์กอัป HTML ที่มีพื้นที่แนวตั้งถูกจองไว้อย่างเหมาะสมสำหรับรูปภาพสุดท้าย การปรับปรุงนี้สังเกตได้เป็นพิเศษในอุปกรณ์เคลื่อนที่ เนื่องจากรูปภาพจะแสดงผลได้เต็มระยะของวิวพอร์ตสำหรับอุปกรณ์เคลื่อนที่
องค์ประกอบบางอย่างในเว็บไซต์ของลูกค้ามีเนื้อหาแบบไดนามิก (เช่น รายการรีวิวจากลูกค้าภายนอก) และไม่สามารถแปลงเป็น CSS เพียงอย่างเดียวได้เพื่อใช้ประโยชน์จากการแสดงผลฝั่งเซิร์ฟเวอร์ให้เกิดประโยชน์สูงสุด บริเวณเหล่านี้ยากต่อการปรับปรุงการเปลี่ยนเลย์เอาต์เนื่องจากเนื้อหา (ความสูงดังกล่าว) จะแตกต่างกันไป ในกรณีเหล่านั้น เรารวมคอมโพเนนต์ไว้ในคอนเทนเนอร์ที่ใช้ min-height ซึ่งกำหนดไว้ล่วงหน้าตามการสังเกตความสูงเฉลี่ยขององค์ประกอบเฉพาะแต่ละรายการ ระบบจะนำ min-height ออกเมื่อคอมโพเนนต์แบบไดนามิกภายในแสดงผลเสร็จแล้ว แม้จะไม่สมบูรณ์แบบ แต่โซลูชันนี้ช่วยให้เราลดการเปลี่ยนแปลงเลย์เอาต์ลงได้อย่างมาก
เรายังคงพยายามพัฒนา LCP อย่างต่อเนื่องแม้ว่าจะมุ่งเน้นการปรับปรุง CLS ในหลายๆ เว็บไซต์ รูปภาพคือตัวการสำคัญที่สุดที่ทำให้เกิด LCP และสำหรับเราแล้ว นี่เป็นจุดที่ต้องปรับปรุงอย่างเห็นได้ชัด เราได้ทำการปรับปรุงกับรูปภาพที่โหลดแบบ Lazy Loading โดยใช้ IntersectionObserver แต่พบว่าขนาดรูปภาพไม่ได้กำหนดขนาดที่เหมาะสมที่สุดสำหรับแต่ละเบรกพอยท์ (อุปกรณ์เคลื่อนที่ แท็บเล็ต เดสก์ท็อป เดสก์ท็อปขนาดใหญ่) เราจึงได้อัปเดตโค้ดการสร้างรูปภาพเพื่อบีบและปรับขนาดรูปภาพตามเบรกพอยท์ จากนั้นปรับความละเอียดตามความหนาแน่นพิกเซลอีกครั้ง ตัวอย่างเช่น การลดขนาดของรูปภาพขนาดใหญ่หนึ่งๆ จะลดขนาดลงจาก 192 KB เป็น 102 KB
ในการแสดงผลเว็บไซต์อย่างรวดเร็วบนอุปกรณ์ที่มีการเชื่อมต่อเครือข่ายไม่ดี เราได้เพิ่มโค้ดเพื่อลดขนาดภาพลงแบบไดนามิกตามความเร็วในการเชื่อมต่อ ซึ่งทำได้โดยใช้พร็อพเพอร์ตี้ downlink ซึ่งแสดงผลโดย navigator.connection เราใช้พารามิเตอร์การค้นหาตาม URL เพื่อลดคุณภาพของรูปผ่าน Asset API ตามเงื่อนไขของเครือข่ายเหล่านั้น
โดยระบบจะโหลดส่วนต่างๆ ในเว็บไซต์ของลูกค้าแบบไดนามิก เนื่องจากเราทราบว่าส่วนใดที่จะแสดงในเว็บไซต์หนึ่งๆ เมื่อเผยแพร่ เราจึงใช้คำแนะนำด้านทรัพยากร rel=preconnect เพื่อเริ่มต้นการเชื่อมต่อและแฮนด์เชคที่จำเป็นล่วงหน้า นอกจากนี้ เรายังใช้คำแนะนำด้านทรัพยากรเพื่อโหลดแบบอักษรและทรัพยากรที่สำคัญอื่นๆ อย่างรวดเร็ว
ขณะสร้างเว็บไซต์ ลูกค้าเพิ่มส่วนต่างๆ ซึ่งอาจมีสคริปต์แทรกในบรรทัดเพื่อรองรับฟังก์ชันการทำงานที่แตกต่างกัน การใส่สคริปต์เหล่านี้ในบรรทัดตลอดทั้งหน้า HTML อาจไม่ใช่ประสิทธิภาพที่ดีที่สุดเสมอไป เราตัดสินใจที่จะทำให้สคริปต์ภายนอกเป็นสคริปต์ภายนอกเพื่อให้เบราว์เซอร์สามารถโหลดและแยกวิเคราะห์เนื้อหาสคริปต์แบบไม่พร้อมกัน นอกจากนี้ยังแชร์สคริปต์ภายนอกที่เพิ่งสร้างขึ้นใหม่ข้ามหน้าเว็บได้ด้วย วิธีนี้ช่วยให้ได้รับประสิทธิภาพการทำงานเพิ่มขึ้นในรูปแบบของเบราว์เซอร์และการแคช CDN เราได้เก็บสคริปต์ที่สำคัญต่างๆ ไว้เพื่อให้เบราว์เซอร์แยกวิเคราะห์และเรียกใช้สคริปต์ได้เร็วขึ้น
ผลลัพธ์
การทุ่มเทความพยายามของเรากับ CLS ช่วยให้อัตราการสอบผ่านของ Core Web Vitals เพิ่มขึ้นจากประมาณ 40% เป็นเกือบ 70% ซึ่งเพิ่มขึ้น 75%
เมื่อผู้ใช้กลับมายังแพลตฟอร์มของเราเพื่ออัปเดตและเผยแพร่เว็บไซต์ของตนอีกครั้ง ก็พบว่าผู้ใช้ได้รับการปรับปรุงประสิทธิภาพล่าสุด ซึ่งส่งผลให้จำนวนเว็บไซต์ที่มี "ผ่าน Core Web Vitals" เพิ่มขึ้นอย่างต่อเนื่องดังที่แสดงในแผนภูมิด้านล่าง
บทสรุป
การค้นหาจุดเพื่อปรับปรุงประสิทธิภาพและการติดตามความคืบหน้าให้ประสบความสำเร็จจะขึ้นอยู่กับเครื่องมือที่ใช้ในการวัดผล แม้ว่า Lighthouse จะมีประโยชน์ในการวัดประสิทธิภาพครึ่งหน้าบนใน "การตั้งค่าห้องทดลอง" แต่ก็ไม่ได้บันทึกปัญหาด้านประสิทธิภาพที่เกิดขึ้นเฉพาะจากการโต้ตอบของผู้ใช้อย่างถูกต้อง (เช่น การเลื่อนผ่านหน้าเว็บ)
การติดตาม Core Web Vitals ในชีวิตจริงด้วยข้อมูลเมตาช่วยให้เราสามารถแสดงภาพ กําหนดเป้าหมาย และวัดผลกระทบที่เกิดจากการปรับปรุงได้ เส้นทางในการปรับปรุงคะแนน Core Web Vitals ช่วยให้ทีมระบุและแทนที่รูปแบบที่มีประสิทธิภาพซึ่งพบในฐานของโค้ดได้ บางครั้งการเปลี่ยนแปลงที่สัญญาว่าจะให้ผลกระทบแทบไม่ส่งผลกระทบอย่างที่เราคาดหวัง แต่บางครั้งสิ่งที่ตรงกันข้าม มันไม่ได้สวยสมบูรณ์แบบหรอกนะ คุณจึงต้องพยายามต่อไป