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

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

แอดดี้ ออสมานี
แอดดี ออสมานี

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

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

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

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

ภาพหน้าจอองค์ประกอบที่ไฮไลต์โหนด DOM ซึ่งส่งผลต่อการเปลี่ยนเลย์เอาต์ในหน้าเว็บ

วัด Core Web Vitals

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

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

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

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

ระบุตำแหน่งที่คุณปรับปรุงได้ใน Web Vitals

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

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

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

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

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

การตรวจสอบรูปภาพที่มีขนาดเหมาะสม

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

การไฮไลต์องค์ประกอบ LCP ด้วย bookmarklet

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

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

โหลดรูปภาพ Contentful Paint ที่ใหญ่ที่สุดล่วงหน้า

มีคำถามทั่วไป 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"

หลีกเลี่ยงการโหลดรูปภาพ LCP แบบ Lazy Loading

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

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

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

การตรวจสอบการหลีกเลี่ยงเลย์เอาต์ขนาดใหญ่ใน Lighthouse ที่ไฮไลต์โหนด DOM ที่เกี่ยวข้องซึ่งส่งผลต่อ CLS

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

การคลิกภาพหน้าจอของ &quot;องค์ประกอบ&quot; จะเป็นการขยายภาพ

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

เครื่องมือสร้างการเปลี่ยนเลย์เอาต์ที่ไฮไลต์ Shift

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

Search Console แสดงปัญหา CLS

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

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

ตรวจสอบองค์ประกอบรูปภาพโดยไม่มีความกว้างและความสูงที่ชัดเจน

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

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

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

การตรวจสอบที่เกี่ยวข้องกับโฆษณาซึ่งไฮไลต์โอกาสในการลดเวลาในการส่งคําขอและการเปลี่ยนเลย์เอาต์

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

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

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

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

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

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

แก้ไขข้อบกพร่อง First Input Delay / เวลาในการบล็อกรวม / งานที่ใช้เวลานาน

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

การตรวจสอบเพื่อหลีกเลี่ยงงานในเทรดหลักที่ใช้เวลานาน

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

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

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

Calibre ภาพของไทม์ไลน์การดำเนินการในเทรดหลัก

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

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

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

การบล็อกคำขอจากเครือข่าย

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

บล็อก URL คำขอในเครื่องมือสำหรับนักพัฒนาเว็บ

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

มุมมองหลังของการบล็อกคำขอเครือข่ายที่มีค่าใช้จ่าย

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

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

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

การตรวจสอบที่เน้นว่าทรัพยากรของบุคคลที่สามซึ่งมีราคาสูงบางส่วนสามารถแทนที่ได้

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

ลดค่าใช้จ่ายในการตรวจสอบ JavaScript ของบุคคลที่สาม

มากกว่า Core Web Vitals

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

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

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

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