Largest Contentful Paint (LCP) ของหน้าเว็บอาจปรับปรุงได้ยาก เนื่องจากมักเกี่ยวข้องกับหลายองค์ประกอบที่เคลื่อนไหวและข้อเสียที่อาจเกิดขึ้น โพสต์นี้จะพิจารณาข้อมูลภาคสนามจากการโหลดหน้าเว็บจริงทั่วทั้งเว็บเพื่อพิจารณาว่านักพัฒนาซอฟต์แวร์ควรมุ่งเน้นที่การเพิ่มประสิทธิภาพที่ใด
คำแนะนำ LCP แบบคลาสสิก: ลดขนาดรูปภาพ
สําหรับหน้าเว็บส่วนใหญ่บนเว็บ องค์ประกอบ LCP คือรูปภาพ ด้วยเหตุนี้ เราจึงเข้าใจว่าวิธีที่ดีที่สุดในการปรับปรุง LCP คือการเพิ่มประสิทธิภาพรูปภาพ LCP
ในช่วง 5 ปีหรือมากกว่านั้นนับตั้งแต่มีการเปิดตัว LCP คำแนะนำบรรทัดแรกมักเป็นเช่นนั้น ตรวจสอบว่ารูปภาพมีขนาดเหมาะสมและบีบอัดอย่างเพียงพอ รวมถึงอาจใช้รูปแบบรูปภาพในศตวรรษที่ 21 ขณะดำเนินการ Lighthouse ยังมีการตรวจสอบที่แตกต่างกัน3 ประเภทเพื่อให้คําแนะนําเหล่านี้
สาเหตุที่คำแนะนำนี้กลายเป็นเรื่องธรรมดาส่วนหนึ่งคือ คุณสามารถวัดจำนวนไบต์ที่มากเกินไปได้ง่ายๆ และแนะนำเครื่องมือบีบอัดรูปภาพได้ง่ายๆ นอกจากนี้ ยังอาจใช้งานได้ง่ายด้วย ทั้งนี้ขึ้นอยู่กับไปป์ไลน์การสร้างและการนำส่ง
หากใช่ ก็ดำเนินการได้เลย การส่งไบต์ไปยังผู้ใช้น้อยลงมักจะส่งผลดีเสมอ มีเว็บไซต์จํานวนมากบนเว็บที่ยังคงแสดงรูปภาพขนาดใหญ่เกินความจำเป็นซึ่งการบีบอัดขั้นพื้นฐานก็สามารถแก้ไขได้
อย่างไรก็ตาม เมื่อเราเริ่มดูข้อมูลประสิทธิภาพในสนามสําหรับผู้ใช้ใน Chrome เพื่อดูว่าเวลาในการเข้าถึง LCP มักจะหมดไปที่ไหน เราพบว่าเวลาในการดาวน์โหลดรูปภาพแทบจะไม่ได้เป็นปัญหาคอขวด
แต่ส่วนอื่นๆ ของ LCP กลับเป็นปัญหาที่ใหญ่กว่ามาก
รายละเอียดของส่วนย่อย LCP
เราได้ดูข้อมูลจากส่วนย่อยของ LCP ตามที่อธิบายไว้ในเพิ่มประสิทธิภาพ LCP เพื่อทําความเข้าใจว่าส่วนใดมีศักยภาพมากที่สุดในการปรับปรุง LCP
แม้ว่าหน้าเว็บและเฟรมเวิร์กแต่ละหน้าจะใช้วิธีการที่แตกต่างกันในการโหลดและแสดงสิ่งที่จะกลายเป็นองค์ประกอบ LCP ของหน้า แต่หน้าเว็บแต่ละหน้าก็แบ่งออกเป็นส่วนย่อยๆ ต่อไปนี้
การอ้างอิงจากบทความดังกล่าว ระบุว่าส่วนย่อยๆ มีดังนี้
- เวลาที่ได้รับข้อมูลไบต์แรก (TTFB)
- ระยะเวลาตั้งแต่ที่ผู้ใช้เริ่มโหลดหน้าเว็บจนถึงตอนที่เบราว์เซอร์ได้รับไบต์แรกของการตอบสนองเอกสาร HTML
- ความล่าช้าในการโหลดทรัพยากร
- เวลาที่ผ่านไประหว่าง TTFB กับเวลาที่เบราว์เซอร์เริ่มโหลดทรัพยากร LCP หากองค์ประกอบ LCP ไม่ต้องการโหลดทรัพยากรเพื่อแสดงผล เวลานี้จะเท่ากับ
0 - ระยะเวลาในการโหลดทรัพยากร
- ระยะเวลาที่ใช้ในการโหลดทรัพยากร LCP เอง หากองค์ประกอบ LCP ไม่ต้องการโหลดทรัพยากรเพื่อแสดงผล เวลานี้คือ
0 - ความล่าช้าในการแสดงผลองค์ประกอบ
- เวลาที่ผ่านไประหว่างที่ทรัพยากร LCP โหลดเสร็จและองค์ประกอบ LCP แสดงผลอย่างสมบูรณ์
ข้อมูลประสิทธิภาพการนําทางจริง
| การจัดประเภท LCP | TTFB (มิลลิวินาที) | ความล่าช้าในการโหลดรูปภาพ (มิลลิวินาที) | ระยะเวลาในการโหลดรูปภาพ (มิลลิวินาที) | ความล่าช้าในการแสดงผล (มิลลิวินาที) |
|---|---|---|---|---|
| ดี | 600 | 350 | 160 | 230 |
| ต้องปรับปรุง | 1,360 | 720 | 270 | 310 |
| แย่ | 2,270 | 1,290 | 350 | 360 |
ในโพสต์นี้ เราใช้ข้อมูลจากการนำทางหน้าเว็บที่มี LCP ของทรัพยากรย่อยรูปภาพใน Chrome เพื่อดูส่วนย่อยของ LCP เราเคยดูข้อมูลประเภทนี้มาก่อน แต่ไม่เคยดูจากข้อมูลภาคสนามเพื่อดูว่าผู้ใช้จริงใช้เวลาอยู่ที่ใดขณะรอ LCP ของหน้า
เช่นเดียวกับ Core Web Vitals เราใช้เปอร์เซ็นต์ไทล์ที่ 75 (p75) ของ LCP แต่ละส่วนย่อยสำหรับต้นทางแต่ละรายการในชุดข้อมูล CrUX ซึ่งส่งผลให้มีค่า p75 4 ค่า (1 ค่าสำหรับแต่ละส่วนย่อย) ในการสรุปการแจกแจงเหล่านี้ เรานำค่ามัธยฐานของค่าเหล่านั้นจากต้นทางทั้งหมดสำหรับแต่ละส่วนย่อยของ LCP 4 ส่วน
สุดท้าย เราจะแยกต้นทางออกเป็นกลุ่มๆ โดยพิจารณาจาก LCP ที่ 75 เปอร์เซ็นต์ว่า"ดี" "ต้องปรับปรุง" หรือ "แย่" ซึ่งช่วยแสดงให้เห็นความแตกต่างระหว่างต้นทางที่มี LCP ดีกับต้นทางที่มี LCP ไม่ดี
ลดขนาดรูปภาพ LCP ไหม ครั้งนี้มีข้อมูล
ระยะเวลาในการโหลดคือค่าที่วัดระยะเวลาในการดึงข้อมูลทรัพยากร LCP ซึ่งในกรณีนี้คือรูปภาพ โดยปกติแล้ว เวลานี้สัมพันธ์กับจำนวนไบต์ในรูปภาพ ด้วยเหตุนี้คำแนะนำด้านประสิทธิภาพทั้งหมดจึงแนะนำให้ลดจำนวนไบต์นั้น
เมื่อดูที่เวลาในกราฟก่อนหน้า สิ่งที่เห็นได้ชัดคือเวลาในการโหลดรูปภาพนั้นไม่นาน อันที่จริงแล้ว นี่เป็นชิ้นส่วนย่อย LCP ที่สั้นที่สุดในกลุ่ม LCP ทั้งหมด ระยะเวลาในการโหลดของต้นทาง LCP ไม่ดีจะนานกว่าต้นทาง LCP ดี แต่ก็ยังไม่ใช่ต้นทางที่ใช้เวลาส่วนใหญ่
ต้นทางส่วนใหญ่ที่มี LCP ไม่ดีใช้เวลาน้อยกว่า 10% ของเวลา LCP p75 ในการดาวน์โหลดรูปภาพ LCP
ใช่ คุณควรเพิ่มประสิทธิภาพรูปภาพ แต่นั่นเป็นเพียงส่วนหนึ่งของการปรับปรุง LCP และจากข้อมูลนี้ เห็นได้ชัดว่าต้นทางทั่วไปบนเว็บมีศักยภาพในการลดเวลา LCP โดยรวมได้เพียงไม่กี่มิลลิวินาที ไม่ว่ารูปแบบการบีบอัดจะซับซ้อนเพียงใดก็ตาม
ความประหลาดใจสุดท้ายคือ ก่อนหน้านี้เรามักจะโทษอุปกรณ์เคลื่อนที่และคุณภาพของเครือข่ายมือถือว่าเป็นต้นเหตุของเวลาในการโหลดที่ช้า เมื่อก่อนเราอาจคาดหวังว่าโทรศัพท์ทั่วไปจะใช้เวลานานกว่าหลายเท่าในการดาวน์โหลดรูปภาพเดียวกันกับเครื่องเดสก์ท็อปในการเชื่อมต่อแบบใช้สาย แต่ข้อมูลแสดงให้เห็นว่าไม่เป็นเช่นนั้นแล้ว สำหรับต้นทางที่มี LCP ช้า ระยะเวลาการโหลดรูปภาพ p75 มัธยฐานช้ากว่าในอุปกรณ์เคลื่อนที่เพียง 20% เมื่อเทียบกับเดสก์ท็อป
เวลาที่ได้รับข้อมูลไบต์แรก (TTFB)
สำหรับการไปยังส่วนต่างๆ ที่มีการส่งคำขอเครือข่าย TTFB จะใช้เวลาสักครู่เสมอ การค้นหา DNS และเริ่มการเชื่อมต่อต้องใช้เวลา และคุณไม่สามารถเอาชนะกฎของฟิสิกส์ได้ เนื่องจากคำขอต้องเดินทางผ่านโลกแห่งความเป็นจริงผ่านสายไฟและสายไฟเบอร์ออปติกเพื่อไปยังเซิร์ฟเวอร์ จากนั้นการตอบกลับต้องเดินทางกลับ แม้แต่ต้นทางค่ามัธยฐานที่มี LCP ดีก็ใช้เวลามากกว่าครึ่งวินาทีใน TTFB ที่เปอร์เซ็นต์ไทล์ 75
อย่างไรก็ตาม ความแปรปรวนของ TTFB ระหว่างต้นทาง LCP ที่ดีและไม่ดีแสดงให้เห็นถึงโอกาสในการปรับปรุง สำหรับต้นทางอย่างน้อยครึ่งที่มี LCP "แย่" TTFB ของ p75 ที่ 2,270 มิลลิวินาทีเพียงอย่างเดียวแทบจะรับประกันได้ว่า LCP ของ p75 จะเร็วกว่าเกณฑ์ "ดี" ที่ 2.5 วินาทีไม่ได้ การลดเวลาดังกล่าวเพียงเล็กน้อยก็อาจส่งผลให้ LCP ดีขึ้นอย่างมาก
คุณอาจไม่สามารถเอาชนะกฎของฟิสิกส์ได้ แต่ก็มีบางสิ่งที่ทำได้ เช่น หากผู้ใช้อยู่ในพื้นที่ที่แตกต่างจากเซิร์ฟเวอร์ของคุณมาก CDN จะช่วยให้ผู้ใช้เข้าถึงเนื้อหาของคุณได้เร็วขึ้น
ดูข้อมูลเพิ่มเติมได้ที่คู่มือการเพิ่มประสิทธิภาพ TTFB
ความล่าช้าในการโหลดทรัพยากร ซึ่งเป็นสาเหตุที่ทำให้เกิด LCP ที่ช้าซึ่งมักถูกมองข้าม
หาก TTFB ปรับปรุงได้ แต่การปรับปรุงถูกจำกัดด้วยข้อจำกัดทางกายภาพ ก็อาจลดเวลาในการโหลดทรัพยากรได้ แต่ในทางปฏิบัติแล้ว TTFB จะจำกัดด้วยสถาปัตยกรรมการแสดงผลเท่านั้น
ส่วนย่อยนี้วัดเวลานับจากที่ได้รับไบต์แรกของการตอบกลับ HTML (TTFB) จนถึงเวลาที่เบราว์เซอร์เริ่มส่งคำขอรูปภาพ LCP เป็นเวลาหลายปีที่เราได้มุ่งเน้นที่เวลาในการดาวน์โหลดรูปภาพ LCP แต่มักละเลยเวลาที่สูญเปล่าไปก่อนที่จะมีการบอกให้เบราว์เซอร์เริ่มดาวน์โหลด
เว็บไซต์ค่ามัธยฐานที่มี LCP ไม่ดีใช้เวลารอเริ่มดาวน์โหลดรูปภาพ LCP นานกว่าการดาวน์โหลดจริงเกือบ 4 เท่า โดยรอ 1.3 วินาทีระหว่าง TTFB กับคำขอรูปภาพ นั่นคือมากกว่าครึ่งหนึ่งของงบประมาณ LCP 2.5 วินาทีที่ใช้ไปในส่วนย่อยเดียว
เชนทรัพยากร Dependency เป็นสาเหตุที่พบบ่อยของความล่าช้าในการโหลด ในทางที่ง่ายกว่านั้นคือหน้าเว็บที่โหลดสไตล์ชีต ซึ่งหลังจากเบราว์เซอร์จัดวางเลย์เอาต์แล้ว ก็จะตั้งค่ารูปภาพพื้นหลังซึ่งจะกลายเป็น LCP ขั้นตอนทั้งหมดเหล่านี้ต้องเกิดขึ้นก่อนที่เบราว์เซอร์จะรู้ตัวว่าต้องเริ่มดาวน์โหลดรูปภาพ LCP
เมื่อใช้ข้อมูลการ Crawl สาธารณะของ HTTP Archive ซึ่งบันทึกเชน "ผู้เริ่ม" ของคำขอเครือข่ายจากเอกสาร HTML ไปยังรูปภาพ LCP คุณจะเห็นว่าความยาวของเชนคำขอมีความสัมพันธ์อย่างชัดเจนกับ LCP ที่ช้าลง
สิ่งสำคัญคือต้องแจ้งให้เบราว์เซอร์ทราบโดยเร็วที่สุดว่า LCP จะเป็นอะไร เพื่อให้เบราว์เซอร์เริ่มโหลดได้ แม้ว่าจะยังไม่มีตําแหน่งสำหรับ LCP ในเลย์เอาต์ของหน้าก็ตาม มีเครื่องมือ 2-3 อย่างที่ใช้ดำเนินการนี้ได้ เช่น แท็ก <img> แบบคลาสสิกใน HTML เพื่อให้เครื่องมือสแกนแบบโหลดล่วงหน้าพบแท็กดังกล่าวได้อย่างรวดเร็วและเริ่มดาวน์โหลด หรือแท็ก <link rel="preload"> (หรือส่วนหัว HTTP) สำหรับรูปภาพที่จะไม่ได้เป็น <img>
นอกจากนี้ ยังช่วยเบราว์เซอร์ในการกำหนดว่าควรจัดลำดับความสำคัญของทรัพยากรใด กรณีนี้จะเกิดขึ้นได้เมื่อหน้าเว็บส่งคําขอจํานวนมากระหว่างการโหลดหน้า เนื่องจากเบราว์เซอร์มักจะไม่ทราบว่าองค์ประกอบ LCP จะเป็นอะไรจนกว่าทรัพยากรจํานวนมากเหล่านั้นจะโหลดและเลย์เอาต์เกิดขึ้น การกำกับเนื้อหาองค์ประกอบ LCP ที่เป็นไปได้ด้วยแอตทริบิวต์ fetchpriority="high" (และตรวจสอบว่าหลีกเลี่ยง loading="lazy") จะช่วยให้เบราว์เซอร์เริ่มโหลดทรัพยากรทันที
อ่านคําแนะนําเพิ่มเติมเกี่ยวกับการเพิ่มประสิทธิภาพเวลาในการโหลด
ความล่าช้าในการแสดงผล
เวลาในการแสดงผลจะวัดเวลาตั้งแต่ที่เบราว์เซอร์โหลดรูปภาพ LCP และพร้อมใช้งานแล้ว แต่เกิดความล่าช้าก่อนที่จะแสดงบนหน้าจอด้วยเหตุผลบางอย่าง บางครั้งนี่อาจเป็นงานที่ใช้เวลานานซึ่งบล็อกเธรดหลักเมื่อรูปภาพพร้อมแล้ว ในบางกรณีอาจเป็นตัวเลือก UI เพื่อแสดงองค์ประกอบที่ซ่อนอยู่
สำหรับต้นทางทั่วไปบนเว็บ ดูเหมือนว่าโอกาสที่จะเกิดความล่าช้าในการแสดงผลจะน้อยมาก แต่ในระหว่างการเพิ่มประสิทธิภาพ คุณอาจสร้างความล่าช้าในการแสดงผลจากเวลาที่ใช้ในการแสดงผลส่วนย่อยอื่นๆ ก่อนหน้านี้ได้ ตัวอย่างเช่น หากหน้าเว็บเริ่มโหลดรูปภาพ LCP ล่วงหน้าเพื่อให้พร้อมใช้งานอย่างรวดเร็ว ก็จะไม่มีการรอโหลดนานอีกต่อไป แต่หากหน้าเว็บยังไม่พร้อมแสดงรูปภาพ เช่น จากสไตล์ชีตขนาดใหญ่ที่บล็อกการแสดงผล หรือแอปการแสดงผลฝั่งไคลเอ็นต์ที่ต้องโหลด JavaScript ทั้งหมดให้เสร็จก่อนจึงจะแสดงอะไรได้ LCP จะยังคงช้ากว่าที่ควรจะเป็น และเวลารอก็จะแสดงเป็นเวลาในการรอแสดงผล ด้วยเหตุนี้ การแสดงผลฝั่งเซิร์ฟเวอร์หรือ HTML แบบคงที่จึงมักมีข้อได้เปรียบในด้าน LCP
หากเนื้อหาของคุณได้รับผลกระทบ โปรดอ่านคําแนะนําเพิ่มเติมเกี่ยวกับการเพิ่มประสิทธิภาพเวลาในการแสดงผล
ตรวจสอบส่วนย่อยทั้งหมดเหล่านั้น
เป็นที่แน่ชัดแล้วว่าหากต้องการเพิ่มประสิทธิภาพ LCP อย่างมีประสิทธิภาพ นักพัฒนาซอฟต์แวร์ต้องพิจารณาการโหลดหน้าเว็บโดยรวม ไม่ใช่แค่มุ่งเน้นที่การเพิ่มประสิทธิภาพรูปภาพ ตรวจสอบทุกส่วนของเวลาในการตอบสนองของ LCP เนื่องจากมีโอกาสในการปรับปรุงได้มากกว่า
สำหรับการรวบรวมข้อมูลนี้ในสนาม การบิลด์การระบุแหล่งที่มาของไลบรารี web-vitals จะระบุเวลาของส่วนย่อย LCP รายงานประสบการณ์ของผู้ใช้ Chrome (CrUX) ยังไม่มีข้อมูลทั้งหมดนี้ แต่มีรายการ TTFB และ LCP ซึ่งถือเป็นจุดเริ่มต้น เราหวังว่าจะรวมข้อมูลที่ใช้สําหรับโพสต์นี้ไว้ใน CrUX ในอนาคต โปรดติดตามข่าวสารเพิ่มเติมเกี่ยวกับเรื่องนี้
หากต้องการทดสอบส่วนย่อยของ LCP ในเครื่อง ให้ลองใช้ส่วนขยาย Web Vitals หรือข้อมูลโค้ด JavaScript ในบทความนี้ นอกจากนี้ Lighthouse ยังแสดงรายละเอียดในการตรวจสอบ "องค์ประกอบ Largest Contentful Paint" ด้วย ดูคําแนะนําเพิ่มเติมเกี่ยวกับ LCP ในส่วนย่อยในแผงประสิทธิภาพของเครื่องมือสําหรับนักพัฒนาเว็บ ซึ่งจะพร้อมใช้งานเร็วๆ นี้