การเพิ่มประสิทธิภาพ Web Vitals โดยใช้ Lighthouse

ค้นหาโอกาสในการปรับปรุงประสบการณ์ของผู้ใช้ด้วยเครื่องมือบนเว็บของ Chrome

Addy Osmani

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

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

Lighthouse 7.x มีฟีเจอร์ใหม่ๆ เช่น ภาพหน้าจอองค์ประกอบ เพื่อให้ตรวจสอบส่วนต่างๆ ของ UI ได้ง่ายขึ้น ซึ่งส่งผลต่อเมตริกประสบการณ์ของผู้ใช้ (เช่น โหนดที่ทําให้เกิดการเปลี่ยนเลย์เอาต์)

นอกจากนี้ เรายังรองรับภาพหน้าจอองค์ประกอบใน PageSpeed Insights ที่ช่วยให้สามารถระบุปัญหาสำหรับการแสดงหน้าเว็บแบบดำเนินการเพียงครั้งเดียวได้ง่ายขึ้น

วัด Core Web Vitals

Lighthouse สามารถวัดเมตริก Core Web Vitals โดยการสังเคราะห์ ซึ่งรวมถึง Largest Contentful Paint, Cumulative Layout Shift และ Total Block Time (พร็อกซีของห้องทดลองสำหรับFirst Input Delay) เมตริกเหล่านี้แสดงการโหลด ความเสถียรของเลย์เอาต์ และความพร้อมในการโต้ตอบ เมตริกอื่นๆ เช่น First Contentful Paint ที่ไฮไลต์ในอนาคตของ Core Web Vitals ก็มีเช่นกัน

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

หมายเหตุ: Lighthouse มุ่งเน้นการวัดประสบการณ์ของผู้ใช้ระหว่างการโหลดหน้าเว็บเริ่มต้นในการตั้งค่าห้องทดลอง โดยจำลองการทำงานของโทรศัพท์หรือเดสก์ท็อปที่ทำงานช้า หากมีลักษณะการทำงานในหน้าเว็บที่อาจทำให้เกิดการเปลี่ยนเลย์เอาต์หรืองาน JavaScript ที่ใช้เวลานานหลังจากการโหลดหน้าเว็บ เมตริกของ Lab จะไม่แสดงผลตามนี้ ลองใช้แผงประสิทธิภาพของเครื่องมือสำหรับนักพัฒนาเว็บ, Search Console, ส่วนขยาย Web Vitals หรือ RUM เพื่อดูเมตริกหลังการโหลด

ตัวเลือก Web Vitals ใหม่ในแผงประสิทธิภาพของเครื่องมือสำหรับนักพัฒนาเว็บจะแสดงแทร็กที่ไฮไลต์ช่วงเวลาของเมตริก เช่น Layout Shift (LS) ที่แสดงด้านบน

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

ระบุจุดที่คุณปรับปรุงใน Web Vitals ได้

ระบุองค์ประกอบ Largest Contentful Paint

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

Lighthouse มีการตรวจสอบ "องค์ประกอบ Largest Contentful Paint" ที่ระบุว่าองค์ประกอบใดเป็น Largest Contentful Paint การวางเมาส์เหนือองค์ประกอบจะไฮไลต์องค์ประกอบนั้นในหน้าต่างเบราว์เซอร์หลัก

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

นอกจากนี้ คุณอาจพบว่า LCP Bookmarkslet โดย Annie Sullivan มีประโยชน์ในการระบุองค์ประกอบ LCP ที่มีสี่เหลี่ยมผืนผ้าสีแดงได้อย่างรวดเร็วในคลิกเดียว

โหลดรูปภาพที่ค้นพบล่าช้าล่วงหน้าเพื่อปรับปรุง LCP

หากต้องการปรับปรุง Largest Contentful Paint ให้โหลดรูปภาพหลักที่สำคัญไว้ล่วงหน้าหากเบราว์เซอร์พบรูปภาพดังกล่าวล่าช้า การค้นพบล่าช้าอาจเกิดขึ้นหากต้องโหลดแพ็กเกจ JavaScript ก่อนที่จะค้นพบรูปภาพได้

หมายเหตุ: ควรใช้การเติมเงินเท่าที่จำเป็น แบนด์วิดท์ของเครือข่ายในตอนต้นเป็นทรัพยากรที่น้อย และการใช้การโหลดล่วงหน้าอาจทำให้เกิดค่าใช้จ่ายที่ต้องเสียไปกับทรัพยากรอื่น เพื่อให้การโหลดล่วงหน้ามีประสิทธิภาพ โปรดตรวจสอบว่ามีการจัดเรียงทรัพยากรอย่างถูกต้องเพื่อหลีกเลี่ยงการเกิดปัญหาซ้ำเมื่อเมตริกอื่นๆ ในหน้าดังกล่าวมีความสำคัญเช่นกัน (เช่น CSS, JS, แบบอักษร) ค่าใช้จ่ายในการโหลดล่วงหน้าจะครอบคลุมเรื่องนี้อย่างละเอียดมากขึ้น

เรามีคำถามที่พบบ่อย 2-3 ข้อเกี่ยวกับการโหลดรูปภาพ LCP ล่วงหน้าที่อาจมีคุณค่ากล่าวโดยสรุป

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

<img src="lighthouse.jpg"
          srcset="lighthouse_400px.jpg 400w,
                  lighthouse_800px.jpg 800w,
                  lighthouse_1600px.jpg 1600w" sizes="50vw" alt="A helpful
Lighthouse">

การเพิ่มแอตทริบิวต์ imagesrcset และ imagesizes ลงในแอตทริบิวต์ link ทำให้เราสามารถโหลดรูปภาพที่ปรับเปลี่ยนตามอุปกรณ์ล่วงหน้าได้โดยใช้ตรรกะการเลือกรูปภาพเดียวกันกับที่ srcset และ sizes ใช้ ดังนี้

<link rel="preload" as="image" href="lighthouse.jpg"
           imagesrcset="lighthouse_400px.jpg 400w,
                        lighthouse_800px.jpg 800w,
                        lighthouse_1600px.jpg 1600w"
imagesizes="50vw">

การตรวจสอบจะไฮไลต์โอกาสในการโหลดล่วงหน้าไหมหากกำหนดรูปภาพ LCP ผ่านพื้นหลัง CSS ใช่

รูปภาพที่มีการแจ้งว่าเป็นรูปภาพ LCP ไม่ว่าจะผ่านพื้นหลัง CSS หรือ <img> จะเป็นรูปภาพที่เหมาะสม หากค้นพบที่ความลึกของ Waterfall ตั้งแต่ 3 ขึ้นไป

การโหลดรูปภาพนอกหน้าจอแบบ Lazy Loading และการหลีกเลี่ยงสิ่งนี้สำหรับ LCP

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

รูปภาพครึ่งหน้าบนที่สำคัญ เช่น รูปภาพ Largest Contentful Paint ไม่ควรโหลดแบบ Lazy Loading เนื่องจากอาจเป็นความล่าช้าในการโหลดรูปภาพ LCP Lighthouse จะไฮไลต์หากรูปภาพ LCP โหลดแบบ Lazy Loading อย่างไม่ถูกต้องผ่านการตรวจสอบ "โหลดรูปภาพ Largest Contentful Paint แบบ Lazy Loading"

ระบุการมีส่วนร่วม CLS

Cumulative Layout Shift คือการวัดความเสถียรของภาพ เครื่องมือนี้วัดปริมาณว่าเนื้อหา ในหน้าหนึ่งมีการเปลี่ยนแปลงมากน้อยเพียงใด Lighthouse มีการตรวจสอบการแก้ไขข้อบกพร่อง CLS ที่มีชื่อว่า "หลีกเลี่ยงการเปลี่ยนเลย์เอาต์ขนาดใหญ่"

การตรวจสอบนี้จะไฮไลต์องค์ประกอบ DOM ที่มีผลต่อการเปลี่ยนแปลงของหน้ามากที่สุด ในคอลัมน์ "องค์ประกอบ" ทางด้านซ้าย คุณจะเห็นรายการองค์ประกอบ DOM เหล่านี้ และส่วนทางด้านขวาคือการมีส่วนร่วม CLS โดยรวม

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

สำหรับ CLS หลังการโหลดอาจมีค่าในการแสดงภาพด้วยสี่เหลี่ยมผืนผ้าแบบถาวรซึ่งมีองค์ประกอบที่ส่งผลต่อ CLS มากที่สุด นี่เป็นฟีเจอร์ที่คุณจะพบในเครื่องมือของบุคคลที่สาม เช่น แดชบอร์ด Core Web Vitals ของ SpeedCurve ซึ่งฉันชอบใช้ โปรแกรมสร้าง GIF ของ Layout Shift ของ Defaced สำหรับการดำเนินการต่อไปนี้

ฉันได้รับประโยชน์อย่างมากจากรายงาน Core Web Vitals ของ Search Console เมื่อมองภาพรวมของปัญหาการเปลี่ยนเลย์เอาต์ทั้งเว็บไซต์ วิธีนี้จะช่วยให้ผมเห็นประเภทหน้าต่างๆ บนเว็บไซต์ที่มี CLS สูง (ในกรณีนี้ ซึ่งช่วยให้ระบุได้ด้วยตัวเองว่าส่วนเทมเพลตใดที่ต้องใช้เวลาบ้าง)

หมายเหตุ: โปรดคอยสังเกตตัวบ่งชี้size-adjustใหม่สำหรับ @font-face เพื่อลดการเปลี่ยนเลย์เอาต์ที่เกิดจาก Web Fonts วิธีนี้สามารถปรับขนาดแบบอักษรสำรองเพื่อลด CLS

การระบุ CLS จากรูปภาพที่ไม่มีขนาด

หากต้องการจำกัด Cumulative Layout Shift ที่เกิดจากรูปภาพที่ไม่มีขนาด ให้ใส่แอตทริบิวต์ขนาดความกว้างและความสูงในองค์ประกอบรูปภาพและวิดีโอ วิธีนี้จะทำให้เบราว์เซอร์จัดสรรพื้นที่ในเอกสารในปริมาณที่ถูกต้องขณะที่โหลดรูปภาพ

ดูการตั้งค่าความสูงและความกว้างของรูปภาพเป็นสิ่งสำคัญ อีกครั้งสำหรับการเขียนถึงความสำคัญของการคิดเกี่ยวกับขนาดและอัตราส่วนของรูปภาพ

การระบุ CLS จากโฆษณา

Publisher Ads สำหรับ Lighthouse ช่วยให้คุณค้นหาโอกาสในการปรับปรุงประสบการณ์การโหลดโฆษณาในหน้าเว็บ ซึ่งรวมถึงการมีส่วนร่วมในการเปลี่ยนแปลงเลย์เอาต์และงานยาวๆ ที่อาจส่งผลให้ผู้ใช้ใช้งานหน้าเว็บได้เร็วขึ้น ใน Lighthouse คุณเปิดใช้ฟีเจอร์นี้ได้ผ่านปลั๊กอินชุมชน

อย่าลืมว่าโฆษณาเป็นหนึ่งใน ปัจจัยที่สำคัญที่สุดในการเปลี่ยนแปลงเลย์เอาต์บนเว็บ สิ่งสำคัญที่ต้องปฏิบัติมีดังนี้

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

หลีกเลี่ยงการใช้ภาพเคลื่อนไหวที่ไม่ได้ทำการ Composite

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

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

แก้ไขข้อบกพร่องความล่าช้าของอินพุตแรก / เวลาทั้งหมดในการบล็อก / งานที่ใช้เวลานาน

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

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

เราจะเห็นระยะเวลาของงานเหล่านี้ทางด้านขวา โปรดอย่าลืมว่า "งานที่ใช้เวลานาน" คืองานที่ดำเนินการนานกว่า 50 มิลลิวินาที ซึ่งถือว่าเป็นการบล็อกเทรดหลักนานพอที่จะส่งผลต่ออัตราเฟรมหรือเวลาในการตอบสนองของอินพุต

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

บล็อกคำขอเครือข่ายเพื่อดูผลกระทบก่อน/หลังผลกระทบใน Lighthouse

เครื่องมือสำหรับนักพัฒนาเว็บใน Chrome รองรับการบล็อกคำขอเครือข่ายเพื่อดูผลกระทบของการนำทรัพยากรแต่ละรายการออกหรือไม่พร้อมใช้งาน ซึ่งอาจเป็นประโยชน์สำหรับการทำความเข้าใจค่าใช้จ่ายของแต่ละสคริปต์ (เช่น การฝังหรือเครื่องมือติดตามของบุคคลที่สาม) ที่มีต่อเมตริก เช่น Total Block Time (TBT) และ Time to Interactive

การบล็อกคำขอจากเครือข่ายใช้งานกับ Lighthouse ได้ด้วย เรามาดูรายงานของ Lighthouse ของเว็บไซต์คร่าวๆ กัน คะแนนประสิทธิภาพคือ 63/100 โดยมี TBT ที่ 400 มิลลิวินาที เมื่อเจาะลึกโค้ด เราพบว่าเว็บไซต์นี้โหลด Polyfill ของ Intersection Observer ใน Chrome ซึ่งไม่จำเป็น มาบล็อกกันเถอะ!

เราสามารถคลิกขวาที่สคริปต์ในแผงเครือข่ายเครื่องมือสำหรับนักพัฒนาเว็บ แล้วคลิก Block Request URL เพื่อบล็อกสคริปต์ ในที่นี้เราจะดำเนินการกับ Polyfill ของ Intersection Observer

ขั้นต่อไป เราสามารถเรียกใช้ Lighthouse อีกครั้ง คราวนี้เราเห็นว่าคะแนนประสิทธิภาพดีขึ้น (70/100) เช่นเดียวกับเวลาทั้งหมดในการบล็อก (400 มิลลิวินาที => 300 มิลลิวินาที)

แทนที่การฝังของบุคคลที่สามที่มีราคาสูงด้วย Facade

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

รูปแบบหนึ่งในการปรับปรุงประสิทธิภาพของวิดเจ็ตดังกล่าวคือการโหลดแบบ Lazy Loading ในการโต้ตอบของผู้ใช้ ซึ่งสามารถทำได้โดยการแสดงผลตัวอย่างขนาดเล็กของวิดเจ็ต (ส่วนหน้า) และโหลดเวอร์ชันเต็มเฉพาะเมื่อผู้ใช้โต้ตอบกับวิดเจ็ต Lighthouse มีการตรวจสอบซึ่งจะแนะนําทรัพยากรของบุคคลที่สามซึ่งโหลดแบบ Lazy Loading กับ Facade ได้ เช่น การฝังวิดีโอ YouTube

โปรดทราบว่า Lighthouse จะไฮไลต์โค้ดของบุคคลที่สามที่บล็อกเทรดหลักนานกว่า 250 มิลลิวินาที ซึ่งจะแสดงสคริปต์ของบุคคลที่สามทุกประเภท (รวมถึงสคริปต์ที่เขียนโดย Google) ซึ่งอาจคุ้มค่ากว่าการโหลดแบบเลื่อนเวลาหรือแบบ Lazy Loading หากสิ่งที่แสดงผลจำเป็นต้องเลื่อนเพื่อดู

ก้าวไปไกลกว่า Core Web Vitals

นอกเหนือจากการเน้น Core Web Vitals แล้ว Lighthouse และ PageSpeed Insights เวอร์ชันล่าสุดยังพยายามให้คำแนะนำที่เป็นรูปธรรมซึ่งคุณปฏิบัติตามได้เพื่อปรับปรุงความเร็วในการโหลดเว็บแอปพลิเคชันที่ใช้ JavaScript สูงหากคุณเปิดแผนที่แหล่งที่มาไว้

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

ดูข้อมูลเพิ่มเติมเกี่ยวกับเครื่องมือ Core Web Vitals ได้ที่บัญชี Twitter ของทีม Lighthouse และมีอะไรใหม่ในเครื่องมือสำหรับนักพัฒนาเว็บ

รูปภาพหลักโดย Mercedes Mehling ใน Unsplash