Largest Contentful Paint (LCP)

Philip Walton
Barry Pollard

การรองรับเบราว์เซอร์

  • Chrome: 77
  • ขอบ: 79
  • Firefox: 122
  • Safari: ไม่รองรับ

แหล่งที่มา

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

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

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

LCP คืออะไร

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

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

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

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

ระบบจะพิจารณาองค์ประกอบใดบ้าง

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

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

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

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

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

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

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

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

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

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

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

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

LCP มีการรายงานเมื่อใด

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ตัวอย่าง

ต่อไปนี้คือตัวอย่างเวลาที่ Largest Contentful Paint เกิดขึ้นในเว็บไซต์ยอดนิยมบางแห่ง

ไทม์ไลน์ Largest Contentful Paint จาก cnn.com
ไทม์ไลน์ LCP จาก cnn.com
ไทม์ไลน์ของ Largest Contentful Paint จาก techcrunch.com
ไทม์ไลน์ LCP จาก techcrunch.com

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

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

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

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

วิธีวัด 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 ของตนไปยังเฟรมหลักเพื่อการรวมได้
  • API จะวัด LCP จากจุดเริ่มต้นของการนําทาง แต่สําหรับหน้าเว็บที่แสดงผลล่วงหน้า ควรวัด LCP จาก activationStart เนื่องจากเวลาดังกล่าวสอดคล้องกับเวลา LCP ที่ผู้ใช้ได้รับ

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

import {onLCP} from 'web-vitals';

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

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

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

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

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

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

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

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

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

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

หากมีความคิดเห็นเกี่ยวกับเมตริกเหล่านี้ โปรดแสดงความคิดเห็นในกลุ่ม Google สำหรับ Web Vitals Feedback