การเพิ่มประสิทธิภาพ Core Web Vitals ในเว็บไซต์ The Economic Times ปรับปรุงประสบการณ์ของผู้ใช้ได้อย่างมากและลดอัตราตีกลับของทั้งเว็บไซต์ได้เป็นอย่างมาก
ด้วยความเร็วอินเทอร์เน็ตที่เพิ่มขึ้นในแต่ละวัน ผู้ใช้คาดหวังให้เว็บไซต์ตอบสนองและทำงานได้เร็วกว่าที่เคย The Economic Times มีผู้ใช้ที่ใช้งานอยู่รายเดือนกว่า 45 ล้านคน การเพิ่มประสิทธิภาพสำหรับ Core Web Vitals ทั่วทั้งโดเมน รวมถึงในหน้า AMP และหน้าที่ไม่ใช่ AMP ช่วยให้เราลดอัตราตีกลับและปรับปรุงประสบการณ์การอ่านได้อย่างมาก
การวัดผลกระทบ
เรามุ่งเน้นที่ Largest Contentful Paint (LCP) และ Cumulative Layout Shift (CLS) เนื่องจากการแสดงผลเหล่านี้มีความสำคัญมากที่สุดในการมอบประสบการณ์การอ่านที่ยอดเยี่ยมแก่ผู้ใช้ หลังจากใช้การแก้ไขประสิทธิภาพต่างๆ ตามที่อธิบายไว้ด้านล่าง The Economic Times ก็สามารถปรับปรุงเมตริกรายงานการทดสอบของผู้ใช้ Chrome (CrUX) ได้อย่างมากภายในไม่กี่เดือน
โดยรวมแล้ว CLS เพิ่มขึ้น 250% จาก 0.25 เป็น 0.09 โดยรวมแล้ว LCP ดีขึ้น 80% จาก 4.5 วินาทีเป็น 2.5 วินาที
นอกจากนี้ ค่า LCP ในช่วง "แย่" ลดลง 33% ตั้งแต่เดือนตุลาคม 2020 ถึงกรกฎาคม 2021 ดังนี้
นอกจากนี้ ค่า CLS ในช่วง "แย่" ยังลดลง 65% และค่า CLS ในช่วง "ดี" เพิ่มขึ้น 20% ในกรอบเวลาเดียวกัน
ผลที่ได้คือ The Economic Times ซึ่งก่อนหน้านี้ไม่เป็นไปตามเกณฑ์ของ Core Web Vitals ขณะนี้ได้ผ่านเกณฑ์ Core Web Vitals ทั่วทั้งต้นทางและลดอัตราตีกลับโดยรวมลง 43%
LCP คืออะไรและเราปรับปรุงอย่างไร
องค์ประกอบที่ใหญ่ที่สุดคือองค์ประกอบที่เกี่ยวข้องมากที่สุดสำหรับการปรับปรุงประสบการณ์ของผู้ใช้และการจดจำความเร็วในการโหลด เมตริกประสิทธิภาพ เช่น First Contentful Paint (FCP) จะบันทึกเฉพาะประสบการณ์เริ่มต้นของการโหลดหน้าเว็บเท่านั้น ในทางกลับกัน LCP จะรายงานเวลาในการแสดงผลของรูปภาพ ข้อความ หรือวิดีโอขนาดใหญ่ที่สุดที่ผู้ใช้เห็น
นอกจากการเปลี่ยนไปใช้ผู้ให้บริการ DNS ที่เร็วขึ้นและการเพิ่มประสิทธิภาพรูปภาพแล้ว ต่อไปนี้คือเทคนิคส่วนหนึ่งที่เราใช้เพื่อปรับปรุง LCP
คำขอที่สำคัญก่อน
เนื่องจากเบราว์เซอร์ที่ทันสมัยทั้งหมดจำกัดจำนวนคำขอพร้อมกัน นักพัฒนาแอปจึงต้องให้ความสำคัญกับการโหลดเนื้อหาสำคัญก่อน ในการโหลดหน้าเว็บที่ซับซ้อน เราต้องดาวน์โหลดเนื้อหาต่างๆ เช่น องค์ประกอบส่วนหัว, CSS, ทรัพยากร JavaScript, รูปภาพหลัก, เนื้อหาบทความ, ความคิดเห็น, ข่าวสารอื่นๆ ที่เกี่ยวข้อง, ส่วนท้าย และโฆษณา เราประเมินองค์ประกอบที่จำเป็นสำหรับ LCP และกำหนดให้โหลดรายการเหล่านั้นก่อนเพื่อปรับปรุง LCP และเรายังเลื่อนการเรียกที่ไม่ได้เป็นส่วนหนึ่งของการแสดงหน้าเว็บเริ่มต้นออกไปด้วย
ลักษณะข้อความ
เราทดสอบกับพร็อพเพอร์ตี้ font-display เนื่องจากจะส่งผลต่อทั้ง LCP และ CLS เราลองใช้ font-display: auto; แล้ว จากนั้นเปลี่ยนไปใช้ font-display: swap; ซึ่งจะแสดงข้อความในตอนแรกที่มีแบบอักษรที่ตรงกันและเหมาะสมที่สุด จากนั้นจึงเปลี่ยนเป็นแบบอักษรเมื่อดาวน์โหลดมา ซึ่งทำให้การแสดงผลข้อความของเราเป็นไปอย่างรวดเร็วโดยไม่ขึ้นอยู่กับความเร็วของเครือข่าย
การบีบอัดที่ดียิ่งขึ้น
Brotli เป็นอัลกอริทึมในการบีบอัดอีกทางเลือกของ Gzip และ Deflate ที่พัฒนาโดย Google เราแทนที่แบบอักษรและเนื้อหา และเปลี่ยนการบีบอัดเซิร์ฟเวอร์จาก Gzip เป็น Brotli เพื่อให้มีขอบเขตการใช้งานที่เล็กลง
- ไฟล์ JavaScript มีขนาดเล็กกว่า Gzip 15%
- ไฟล์ HTML มีขนาดเล็กกว่า Gzip 18%
- ไฟล์ CSS และแบบอักษรมีขนาดเล็กกว่า Gzip 17%
เชื่อมต่อกับโดเมนของบุคคลที่สามล่วงหน้า
คุณควรใช้ preconnect อย่างรอบคอบเนื่องจากอาจทำให้ CPU ทำงานหนักเกินไปและทำให้ทรัพยากรสำคัญอื่นๆ ล่าช้าลง โดยเฉพาะกับการเชื่อมต่อที่ปลอดภัย
แต่หากทราบว่าจะมีการดึงข้อมูลทรัพยากรในโดเมนของบุคคลที่สาม ระบบจะใช้ preconnect แทน แต่หากเกิดขึ้นเป็นครั้งคราวในเว็บไซต์ที่มีการเข้าชมสูง preconnect อาจทริกเกอร์การทำงาน TCP และ TLS ที่ไม่จำเป็น ดังนั้น dns-prefetch จึงเหมาะสำหรับทรัพยากรของบุคคลที่สาม เช่น โซเชียลมีเดีย ข้อมูลวิเคราะห์ และอื่นๆ เพื่อดำเนินการค้นหา DNS ล่วงหน้า
แบ่งโค้ดออกเป็นส่วนๆ
ในส่วนหัวของเว็บไซต์ เราโหลดเฉพาะทรัพยากรที่มีส่วนสำคัญของตรรกะทางธุรกิจหรือสำคัญสำหรับการแสดงผลหน้าครึ่งหน้าบนเท่านั้น นอกจากนี้ เรายังแบ่งโค้ดออกเป็นส่วนๆ ด้วยการแยกโค้ด ซึ่งช่วยเราปรับปรุง LCP ของหน้าเว็บให้ดียิ่งขึ้น
การแคชที่ดีขึ้น
สำหรับเส้นทางส่วนหน้าทั้งหมด เราได้เพิ่มเลเยอร์ Redis ซึ่งจะแสดงเทมเพลตจากแคช ซึ่งจะลดเวลาในการคำนวณบนเซิร์ฟเวอร์และสร้าง UI ทั้งหมดในแต่ละคำขอ ซึ่งเป็นการลด LCP ในคำขอที่ตามมา
สรุปเป้าหมายและความสำเร็จของ LCP
ก่อนเริ่มโครงการเพิ่มประสิทธิภาพ ทีมได้เปรียบเทียบคะแนน LCP ที่ 4.5 วินาที (สำหรับเปอร์เซ็นไทล์ที่ 75 ของผู้ใช้โดยอิงตามข้อมูลช่องในรายงาน CrUX) หลังโปรเจ็กต์การเพิ่มประสิทธิภาพ ระยะเวลาลดลงเหลือ 2.5 วินาที
CLS คืออะไรและเราปรับปรุงอย่างไร
คุณเคยสังเกตเห็นการเคลื่อนไหวที่ไม่คาดคิดของเนื้อหาของหน้าเว็บขณะเรียกดูเว็บไซต์หรือไม่ สาเหตุหนึ่งคือการโหลดสื่อแบบไม่พร้อมกัน (รูปภาพ วิดีโอ โฆษณา ฯลฯ) บนหน้าเว็บที่มีขนาดที่ไม่รู้จัก ทันทีที่ทรัพยากรสื่อโหลดขึ้นมา ทรัพยากรจะเปลี่ยนเลย์เอาต์ของหน้า
เราจะกล่าวถึงมาตรการต่างๆ ที่เราใช้เพื่อปรับปรุง CLS ในเว็บไซต์ The Economic Times
ใช้ตัวยึดตำแหน่ง
เราใช้ตัวยึดตำแหน่งที่มีการจัดรูปแบบสำหรับหน่วยโฆษณาและองค์ประกอบสื่อของมิติข้อมูลที่รู้จักเพื่อหลีกเลี่ยงการเปลี่ยนเลย์เอาต์เมื่อไลบรารีโฆษณาโหลดและแสดงโฆษณาในหน้าเว็บ เพื่อให้มั่นใจว่าการเปลี่ยนแปลงเลย์เอาต์จะถูกกำจัดออกโดยการจองพื้นที่สำหรับโฆษณา
มิติข้อมูลคอนเทนเนอร์ที่กำหนด
เราได้ระบุขนาดที่ชัดเจนสำหรับรูปภาพและคอนเทนเนอร์ทั้งหมดเพื่อให้เครื่องมือของเบราว์เซอร์ไม่ต้องคำนวณความกว้างและความสูงขององค์ประกอบ DOM เมื่อองค์ประกอบเหล่านั้นพร้อมใช้งาน เพื่อหลีกเลี่ยงการเปลี่ยนเลย์เอาต์ที่ไม่จำเป็นและใช้การทาสีเพิ่มเติม
สรุปเป้าหมายและความสำเร็จใน CLS
ก่อนเริ่มโครงการเพิ่มประสิทธิภาพ ทีมได้เปรียบเทียบคะแนน CLS ที่ 0.25 เราลดได้อย่างมากถึง 90% เหลือ 0.09
First Input Delay (FID) คืออะไร และเราปรับปรุงฟีเจอร์นี้อย่างไร
First Input Delay คือเมตริกที่ติดตามการตอบสนองของเว็บไซต์ต่อข้อมูลจากผู้ใช้ สาเหตุหลักของคะแนน FID ที่ต่ำคือ JavaScript มีภาระงานหนักที่ทำให้เทรดหลักของเบราว์เซอร์ไม่ว่าง ซึ่งอาจทำให้การโต้ตอบของผู้ใช้ล่าช้า เราได้ปรับปรุง FID ในหลายด้าน
แยกงาน JavaScript ที่ใช้เวลานาน
งานที่ใช้เวลานานคืองานที่ยาว 50 มิลลิวินาทีขึ้นไป งานที่ใช้เวลานานจะอยู่ในเทรดหลักของเบราว์เซอร์และป้องกันไม่ให้ตอบสนองต่อข้อมูลจากผู้ใช้ เราแบ่งงานที่ใช้เวลานานออกเป็นงานย่อยๆ ตามที่ผู้ใช้ร้องขอได้ ซึ่งช่วยลดการขยายของ JavaScript
เลื่อน JavaScript ที่ไม่ได้ใช้
เราให้ความสำคัญกับเนื้อหาของหน้าเว็บมากกว่าสคริปต์ของบุคคลที่สาม เช่น การวิเคราะห์ เพื่อให้หน้าเว็บตอบสนองมากยิ่งขึ้น แต่บางไลบรารีก็มีข้อจำกัดเนื่องจากต้องโหลดในเอกสาร <head> เพื่อให้สามารถติดตามเส้นทางของผู้ใช้ได้อย่างถูกต้อง
ลดการใช้โพลีฟิล
เราลดการพึ่งพา Polyfill และไลบรารีบางรายการลง เนื่องจากเบราว์เซอร์ให้การสนับสนุน API ที่ทันสมัย และมีผู้ใช้เบราว์เซอร์รุ่นเก่า เช่น Internet Explorer น้อยลง
โฆษณาการโหลดแบบ Lazy Loading
การโหลดโฆษณาครึ่งหน้าล่างแบบ Lazy Loading ช่วยลดเวลาในการบล็อกเทรดหลัก และปรับปรุง FID ให้ดีขึ้นด้วย
สรุปเป้าหมายและความสำเร็จของ FID
จากการทดสอบตามปกติ เราสามารถลด FID ของเราจาก 200 มิลลิวินาทีเหลือน้อยกว่า 50 มิลลิวินาทีในวันนี้
การป้องกันการถดถอย
The Economics Times วางแผนที่จะเปิดตัวการตรวจสอบประสิทธิภาพโดยอัตโนมัติในเวอร์ชันที่ใช้งานจริงเพื่อหลีกเลี่ยงความถดถอยด้านประสิทธิภาพของหน้าเว็บ บริษัทวางแผนที่จะประเมิน Lighthouse-CI เพื่อทำการทดสอบในห้องทดลองแบบอัตโนมัติ ซึ่งสามารถป้องกันการถดถอยในสายงานการผลิตได้