Largest Contentful Paint (LCP)

Philip Walton
แบร์รี โพลลาร์ด

การสนับสนุนเบราว์เซอร์

  • 77
  • 79
  • x
  • x

แหล่งที่มา

ที่ผ่านมา เป็นเรื่องยากสำหรับนักพัฒนาเว็บในการวัดว่าเนื้อหาหลักของหน้าโหลดและแสดงต่อผู้ใช้ได้เร็วเพียงใด

เมตริกเก่าๆ เช่น load หรือ DOMContentLoaded นั้นไม่ดีเพราะไม่จำเป็นต้องสอดคล้องกับสิ่งที่ผู้ใช้เห็นบนหน้าจอ และเมตริกประสิทธิภาพแบบใหม่ที่เน้นผู้ใช้เป็นหลัก เช่น First ContentfulPaint (FCP) จะแสดงเพียงช่วงแรกของประสบการณ์การโหลดเท่านั้น หากหน้าเว็บแสดงหน้าจอแนะนำหรือแสดงสัญญาณบอกสถานะการโหลด แสดงว่าช่วงนี้ไม่เกี่ยวข้องกับผู้ใช้มากนัก

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

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

LCP คืออะไร

เมตริก Largest Contentful Paint (LCP) จะรายงานเวลาในการแสดงผลของบล็อกรูปภาพหรือข้อความที่ใหญ่ที่สุดที่มองเห็นได้ภายในวิวพอร์ต เทียบกับเวลาที่หน้าเว็บเริ่มโหลดเป็นครั้งแรก

คะแนน LCP ที่ดีคืออะไร

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

ค่า LCP ที่ดีคือไม่เกิน 2.5 วินาที ค่าที่ไม่ดีควรมากกว่า 4.0 วินาที และสิ่งอื่นๆ ที่อยู่ระหว่างนั้นต้องปรับปรุง

องค์ประกอบใดบ้างที่ถือว่าเป็นองค์ประกอบ

ตามที่ระบุในปัจจุบันใน Largest Contentful Paint API ประเภทองค์ประกอบที่พิจารณาสำหรับ Largest Contentful Paint มีดังนี้

  • <img> องค์ประกอบ
  • องค์ประกอบ <image> ภายในองค์ประกอบ <svg>
  • องค์ประกอบ <video> ที่มีภาพโปสเตอร์ (ใช้เวลาในการโหลดภาพโปสเตอร์)
  • องค์ประกอบที่มีภาพพื้นหลังที่โหลดผ่านฟังก์ชัน url() (ตรงข้ามกับ การไล่ระดับสี CSS)
  • องค์ประกอบระดับบล็อก ที่มีโหนดข้อความหรือองค์ประกอบข้อความระดับแทรกในบรรทัดอื่นๆ
  • เฟรมแรกที่วาดสำหรับองค์ประกอบ <video> ที่เล่นอัตโนมัติ (ข้อมูล ณ วันที่สิงหาคม 2023)
  • เฟรมแรกของรูปแบบภาพเคลื่อนไหว เช่น GIF แบบเคลื่อนไหว (ข้อมูล ณ วันที่ สิงหาคม 2023)

โปรดทราบว่าการจำกัดองค์ประกอบให้อยู่เฉพาะในชุดที่จำกัดนี้เป็นการตั้งใจเพื่อให้สิ่งต่างๆ ง่ายขึ้นในช่วงแรก ทั้งนี้อาจมีการเพิ่มองค์ประกอบอื่นๆ (เช่น การรองรับ <svg> เต็มรูปแบบ) ในอนาคตเมื่อมีการค้นคว้าเพิ่มเติม

นอกจากการพิจารณาเฉพาะองค์ประกอบบางอย่างแล้ว ยังมีการนำการเรียนรู้บางอย่างไปใช้เพื่อยกเว้นองค์ประกอบบางอย่างที่ผู้ใช้อาจมองว่า "ไม่น่าพอใจ" อีกด้วย สำหรับเบราว์เซอร์แบบ Chromium ได้แก่

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

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

ฮิวริสติกแบบ "เนื้อหา" เหล่านี้อาจแตกต่างจากที่ First Contentful Paint (FCP) ใช้ ซึ่งอาจพิจารณาองค์ประกอบเหล่านี้ เช่น รูปภาพตัวยึดตำแหน่งหรือรูปภาพวิวพอร์ตแบบเต็ม แม้ว่าจะไม่มีสิทธิ์เป็นตัวเลือกสำหรับ LCP แม้ว่าทั้งคู่จะใช้คำว่า "มีเนื้อหาตาม" ในชื่อ แต่เป้าหมายของเมตริกเหล่านี้แตกต่างกัน FCP จะวัดเมื่อมีการระบายเนื้อหาลงในหน้าจอและ LCP เมื่อมีการระบายเนื้อหาหลัก ดังนั้น LCP จึงตั้งใจให้มีการเลือกมากขึ้น

มีการกำหนดขนาดองค์ประกอบอย่างไร

โดยทั่วไปขนาดขององค์ประกอบที่รายงานสำหรับ Largest Contentful Paint จะเป็นขนาดที่ผู้ใช้มองเห็นได้ภายในวิวพอร์ต หากองค์ประกอบขยายออกนอกวิวพอร์ต หรือองค์ประกอบใดถูกตัดออกหรือมีoverflowที่มองไม่เห็น ส่วนเหล่านั้นจะไม่นับรวมในขนาดขององค์ประกอบ

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

สำหรับองค์ประกอบของข้อความ ระบบจะพิจารณาเฉพาะขนาดโหนดข้อความเท่านั้น (สี่เหลี่ยมผืนผ้าที่เล็กที่สุดที่ครอบคลุมโหนดข้อความทั้งหมด)

สำหรับองค์ประกอบทั้งหมด ระบบจะไม่พิจารณาระยะขอบ ระยะห่างจากขอบ หรือเส้นขอบที่ใช้ผ่าน CSS

จะมีการรายงาน Contentful Paint ที่ใหญ่ที่สุดเมื่อใด

หน้าเว็บมักโหลดเป็นพักๆ จึงอาจเป็นไปได้ว่าองค์ประกอบที่ใหญ่ที่สุดในหน้านั้นอาจมีการเปลี่ยนแปลง

ในการจัดการกับการเปลี่ยนแปลงที่อาจเกิดขึ้นนี้ เบราว์เซอร์จะส่ง PerformanceEntry ประเภท largest-contentful-paint ที่ระบุองค์ประกอบที่มีเนื้อหาขนาดใหญ่ที่สุดทันทีที่เบราว์เซอร์แสดงผลเฟรมแรก แต่หลังจากที่แสดงผลเฟรมต่อๆ ไป เฟรมที่ตามมาจะส่งไปอีกครั้ง PerformanceEntry ทุกครั้งที่องค์ประกอบที่มีเนื้อหาเต็มมีการเปลี่ยนแปลง

เช่น ในหน้าที่มีข้อความและรูปภาพหลัก เบราว์เซอร์อาจเพียงแค่แสดงข้อความในตอนแรก ซึ่งเบราว์เซอร์จะส่งรายการ largest-contentful-paint ซึ่งพร็อพเพอร์ตี้ element น่าจะอ้างอิง <p> หรือ <h1> หลังจากนั้น เมื่อรูปภาพหลักโหลดเสร็จแล้ว ระบบจะส่งรายการที่ 2 ของ largest-contentful-paint และพร็อพเพอร์ตี้ element จะอ้างอิง <img>

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

นอกเหนือจากรูปภาพและแบบอักษรที่โหลดช้าแล้ว หน้าเว็บอาจเพิ่มองค์ประกอบใหม่ไปยัง DOM เมื่อมีเนื้อหาใหม่พร้อมใช้งาน หากองค์ประกอบใหม่เหล่านี้มีขนาดใหญ่กว่าองค์ประกอบที่มีเนื้อหาขนาดใหญ่ที่สุดก่อนหน้านี้ ระบบจะรายงาน PerformanceEntry ใหม่ด้วย

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

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

เพื่อจุดประสงค์ในการวิเคราะห์ คุณควรรายงานเฉพาะ PerformanceEntry ที่ส่งไปยังบริการวิเคราะห์ครั้งล่าสุดเท่านั้น

เวลาที่ใช้ในการโหลดเทียบกับเวลาที่ใช้ในการแสดงผล

ด้วยเหตุผลด้านความปลอดภัย ระบบไม่แสดงการประทับเวลาการแสดงผลของรูปภาพสำหรับรูปภาพข้ามต้นทางที่ไม่มีส่วนหัว Timing-Allow-Origin แต่จะแสดงเฉพาะเวลาที่ใช้ในการโหลดเท่านั้น (เนื่องจากมีการเปิดเผยข้อมูลนี้ผ่าน API ของเว็บอื่นๆ จำนวนมากแล้ว)

ซึ่งอาจนำไปสู่สถานการณ์ที่ดูเป็นไปไม่ได้หากเว็บ API รายงาน LCP ว่าเร็วกว่า FCP ซึ่งไม่ได้เป็นเช่นนี้ แต่ปรากฏเพียงเพราะข้อจำกัดด้านความปลอดภัยนี้

หากทําได้ เราขอแนะนําให้ตั้งค่าส่วนหัว Timing-Allow-Origin เสมอเพื่อให้เมตริกแม่นยํายิ่งขึ้น

การเปลี่ยนแปลงขนาดและเลย์เอาต์ขององค์ประกอบมีการจัดการอย่างไร

เพื่อรักษาค่าใช้จ่ายในการคำนวณและการส่งรายการประสิทธิภาพใหม่ให้ต่ำ การเปลี่ยนแปลงขนาดหรือตำแหน่งขององค์ประกอบจะไม่สร้างตัวเลือก LCP ใหม่ ระบบจะพิจารณาเฉพาะขนาดและตำแหน่งเริ่มต้นขององค์ประกอบในวิวพอร์ตเท่านั้น

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

ตัวอย่าง

ตัวอย่างสถานการณ์ที่ Largest Contentful Paint เกิดขึ้นในเว็บไซต์ยอดนิยมบางแห่งมีดังนี้

ไทม์ไลน์ Largest Contentful Paint จาก cnn.com

ไทม์ไลน์ Largest Contentful Paint จาก techcrunch.com

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

แม้ว่ามักจะพบว่าเนื้อหาที่โหลดช้ามีขนาดใหญ่กว่าเนื้อหาที่มีอยู่แล้วในหน้า แต่ก็ไม่จำเป็นเสมอไป อีก 2 ตัวอย่างถัดไปจะแสดง Largest Contentful Paint ที่เกิดขึ้นก่อนที่หน้าเว็บจะโหลดเสร็จสมบูรณ์

ไทม์ไลน์ Largest Contentful Paint จาก instagram.com

ไทม์ไลน์ Largest Contentful Paint จาก google.com

ในตัวอย่างแรก โลโก้ Instagram จะโหลดเร็วและยังเป็นองค์ประกอบที่ใหญ่ที่สุด แม้ว่าจะแสดงเนื้อหาอื่นๆ มากขึ้นเรื่อยๆ ในตัวอย่างหน้าผลการค้นหาของ Google องค์ประกอบที่ใหญ่ที่สุดคือย่อหน้าข้อความที่แสดงก่อนที่รูปภาพหรือโลโก้จะโหลดเสร็จ เนื่องจากรูปภาพแต่ละรูปมีขนาดเล็กกว่าย่อหน้านี้ ทำให้ยังเป็นองค์ประกอบที่มีขนาดใหญ่ที่สุดตลอดกระบวนการโหลด

วิธีวัด LCP

ซึ่งจะวัด LCP ได้ในห้องทดลองหรือในภาคสนาม และมีให้ใช้งานในเครื่องมือต่อไปนี้

เครื่องมือภาคสนาม

เครื่องมือสำหรับห้องทดลอง

วัด LCP ใน JavaScript

หากต้องการวัด LCP ใน JavaScript ให้ใช้ Largest Contentful Paint API ตัวอย่างต่อไปนี้แสดงวิธีสร้าง PerformanceObserver ที่รอฟังรายการ largest-contentful-paint และบันทึกลงในคอนโซล

new PerformanceObserver((entryList) => {
  for (const entry of entryList.getEntries()) {
    console.log('LCP candidate:', entry.startTime, entry);
  }
}).observe({type: 'largest-contentful-paint', buffered: true});

ในตัวอย่างข้างต้น แต่ละรายการ largest-contentful-paint ที่บันทึกไว้จะแสดงตัวเลือก LCP ปัจจุบัน โดยทั่วไปค่า startTime ของรายการสุดท้ายที่ปล่อยออกมาจะเป็นค่า LCP แต่ก็ไม่เป็นเช่นนั้นเสมอไป รายการ largest-contentful-paint บางรายการใช้ไม่ได้กับการวัด LCP

ส่วนต่อไปนี้แสดงความแตกต่างระหว่างรายงาน API และวิธีคำนวณเมตริก

ความแตกต่างระหว่างเมตริกกับ API

  • API จะส่ง largest-contentful-paint รายการสำหรับหน้าที่โหลดในแท็บพื้นหลัง แต่ไม่ควรสนใจหน้าเหล่านั้นเมื่อคำนวณ LCP
  • API จะส่งรายการ largest-contentful-paint ต่อไปหลังจากที่หน้าเว็บมีพื้นหลัง แต่ระบบจะไม่สนใจรายการเหล่านั้นเมื่อคำนวณ LCP (ระบบอาจพิจารณาองค์ประกอบในกรณีที่หน้าเว็บอยู่เบื้องหน้าตลอดเวลา)
  • API ไม่รายงานรายการ largest-contentful-paint เมื่อกู้คืนหน้าเว็บจาก Back/Forward Cache แต่ควรวัด LCP ในกรณีเหล่านี้เนื่องจากผู้ใช้พบว่าหน้าเหล่านั้นมาจากการเข้าชมหน้าเว็บที่แตกต่างกัน
  • API จะไม่พิจารณาองค์ประกอบภายใน iframe แต่เมตริกจะประมวลผลเนื่องจากเป็นส่วนหนึ่งของประสบการณ์ของผู้ใช้หน้าเว็บ ในหน้าที่มี LCP ภายใน iframe เช่น ภาพโปสเตอร์ในวิดีโอแบบฝัง จะแสดงความแตกต่างระหว่าง CrUX และ RUM คุณควรพิจารณาใช้ LCP เพื่อวัด LCP ได้อย่างเหมาะสม เฟรมย่อยสามารถใช้ API เพื่อรายงานรายการ largest-contentful-paint ไปยังเฟรมหลักเพื่อทำการรวมได้

แทนที่จะจดจำความแตกต่างเล็กๆ น้อยๆ ทั้งหมดเหล่านี้ นักพัฒนาแอปสามารถใช้web-vitalsไลบรารี JavaScript เพื่อวัด LCP ซึ่งจัดการความแตกต่างเหล่านี้ให้คุณ (หากทำได้ โปรดทราบว่าปัญหา iframe จะไม่ครอบคลุม)

import {onLCP} from 'web-vitals';

// Measure and log LCP as soon as it's available.
onLCP(console.log);

โปรดดูซอร์สโค้ดของ onLCP() เพื่อดูตัวอย่างที่สมบูรณ์ของวิธีวัด LCP ใน JavaScript

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

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

วิธีปรับปรุง LCP

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

แหล่งข้อมูลเพิ่มเติม

บันทึกการเปลี่ยนแปลง

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

การเปลี่ยนแปลงทั้งหมดเกี่ยวกับการใช้งานหรือคำจำกัดความของเมตริกเหล่านี้จะแสดงใน CHANGELOG นี้ เพื่อช่วยคุณจัดการเรื่องนี้

หากคุณมีความคิดเห็นเกี่ยวกับเมตริกเหล่านี้ คุณสามารถแสดงความคิดเห็นในกลุ่ม Google web-vitals-feedback ได้