Largest Contentful Paint (LCP)

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

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

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

LCP คืออะไร

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

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

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

องค์ประกอบใดบ้างถูกนำมาพิจารณา

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

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

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

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

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

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

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

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

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

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

สำหรับองค์ประกอบของข้อความ 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 แต่จะแสดงเฉพาะเวลาในการโหลดเท่านั้น (เนื่องจากมีการเปิดเผยผ่าน API ของเว็บอื่นๆ จำนวนมากแล้ว)

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

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

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

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

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

ตัวอย่าง

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

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

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

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

วิธีวัด LCP

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

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

• รายงานประสบการณ์ของผู้ใช้ Chrome
• PageSpeed Insights
• Search Console (รายงาน Core Web Vitals)
• ไลบรารี JavaScript web-vitals รายการ

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

• เครื่องมือสำหรับนักพัฒนาเว็บใน Chrome
• Lighthouse
• PageSpeed Insights
• WebPageTest

วัด 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);

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

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

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

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

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

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

• บทเรียนที่ได้รับจากการตรวจสอบประสิทธิภาพใน Chrome โดย Annie Sullivan ที่ performance.now() (2019)

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

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

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

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