การแสดงผลเนื้อหาขนาดใหญ่ที่สุด (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 ต่ำ p75 TTFB ที่มีความเร็ว 2,270 มิลลิวินาทีเพียงอย่างเดียวจะการันตีว่า LCP ของ p75 จะเร็วกว่า p75 ที่ "ดี" ไม่ได้ ตามเกณฑ์ แม้แต่เปอร์เซ็นต์ที่ลดลงปานกลางของเวลาดังกล่าวก็จะช่วยให้ LCP เพิ่มขึ้นอย่างมาก
คุณอาจไม่สามารถเอาชนะฟิสิกส์ได้ แต่มีสิ่งที่ทำได้ ตัวอย่างเช่น หากผู้ใช้ของคุณมักอยู่ในตำแหน่งที่แตกต่างจากเซิร์ฟเวอร์ของคุณอย่างมาก CDN จะทำให้เนื้อหาของคุณอยู่ใกล้มากขึ้น
โปรดดูข้อมูลเพิ่มเติมในคู่มือการเพิ่มประสิทธิภาพ TTFB
ความล่าช้าของการโหลดทรัพยากร ซึ่งเป็นสาเหตุของปัญหา LCP ที่ช้าซึ่งถูกมองข้าม
หากปรับปรุง TTFB ได้ แต่การปรับปรุงใดๆ มีข้อจำกัดตามหลักฟิสิกส์ ความล่าช้าของการโหลดทรัพยากรอาจถูกลบออกได้ ในทางปฏิบัติแล้วจะผูกพันกับสถาปัตยกรรมการแสดงผลของคุณเท่านั้น
ส่วนย่อยนี้วัดเวลาตั้งแต่ไบต์แรกของการตอบสนอง HTML (TTFB) จนถึงเวลาที่เบราว์เซอร์เริ่มคำขอรูปภาพ LCP เรามุ่งเน้นที่ระยะเวลาที่ใช้ในการดาวน์โหลดรูปภาพ LCP มาเป็นเวลาหลายปี แต่เรามักไม่ใส่ใจเรื่องเวลาที่เสียไปก่อนที่เบราว์เซอร์จะบอกให้เริ่มดาวน์โหลด
เว็บไซต์ค่ามัธยฐานที่มี LCP ต่ำใช้เวลารอเกือบ 4 เท่าของการรอเริ่มดาวน์โหลดรูปภาพ LCP เหมือนกับการดาวน์โหลดจริง โดยรอ 1.3 วินาทีระหว่าง TTFB กับคำขอรูปภาพ หมายความว่ากว่าครึ่งของงบประมาณ LCP 2.5 วินาทีได้หายไปในส่วนย่อยเดียว
ห่วงโซ่การขึ้นต่อกันเป็นสาเหตุที่พบบ่อยของความล่าช้าในการโหลดที่นาน ด้านที่ง่ายขึ้นคือหน้าเว็บที่โหลดสไตล์ชีต ซึ่งหลังจากที่เบราว์เซอร์ทำเลย์เอาต์แล้ว ระบบจะตั้งค่าภาพพื้นหลังซึ่งสุดท้ายแล้วจะเป็น LCP ขั้นตอนทั้งหมดต้องเกิดขึ้นก่อนที่เบราว์เซอร์จะรู้ว่าเริ่มดาวน์โหลดอิมเมจ LCP ด้วยซ้ำ
การใช้ข้อมูลการ Crawl สาธารณะของ HTTP Archive ซึ่งจะบันทึก "ผู้เริ่ม" ห่วงโซ่คำขอเครือข่ายจากเอกสาร HTML ไปยังรูปภาพ LCP คุณจะเห็นความสัมพันธ์ที่ชัดเจนระหว่างความยาวของห่วงโซ่คำขอกับ LCP ที่ช้ากว่า
สิ่งสำคัญคือต้องแจ้งให้เบราว์เซอร์ทราบโดยเร็วที่สุดว่า LCP จะเป็นอย่างไรเพื่อให้เริ่มโหลดได้แม้ว่าจะมีที่ว่างสำหรับเบราว์เซอร์ในเลย์เอาต์ของหน้าเว็บก็ตาม มีเครื่องมือบางอย่างที่ช่วยให้ดำเนินการนี้ได้ เช่น แท็ก <img> แบบคลาสสิกใน HTML เพื่อให้เครื่องสแกนการโหลดล่วงหน้าค้นหาได้อย่างรวดเร็วและเริ่มดาวน์โหลด หรือใช้แท็ก <link rel="preload"> (หรือส่วนหัว HTTP) สำหรับรูปภาพที่ไม่ใช่ <img>
สิ่งสำคัญอีกอย่างคือช่วยเบราว์เซอร์ในการเลือกทรัพยากรที่จะจัดลำดับความสำคัญ โดยเฉพาะอย่างยิ่งหากหน้าเว็บส่งคําขอจำนวนมากระหว่างการโหลดหน้าเว็บ เนื่องจากเบราว์เซอร์มักไม่ทราบองค์ประกอบ LCP จนกระทั่งทรัพยากรจํานวนมากโหลดและมีการจัดเลย์เอาต์แล้ว การใส่คำอธิบายประกอบองค์ประกอบ LCP ที่เป็นไปได้ด้วยแอตทริบิวต์ fetchpriority="high" (และตรวจสอบว่าหลีกเลี่ยง loading="lazy") จะช่วยให้เบราว์เซอร์เริ่มโหลดทรัพยากรทันทีอย่างชัดเจน
อ่านคำแนะนำเพิ่มเติมเกี่ยวกับการเพิ่มประสิทธิภาพระยะเวลาโหลด
ความล่าช้าในการแสดงผล
ความล่าช้าในการแสดงผลจะวัดระยะเวลานับจากที่เบราว์เซอร์โหลดรูปภาพ LCP และพร้อมแล้ว แต่เกิดความล่าช้าก่อนที่รูปภาพจะแสดงบนหน้าจอด้วยเหตุผลบางอย่าง บางครั้งนี่เป็นงานที่ใช้เวลานานซึ่งบล็อกเทรดหลักเมื่อรูปภาพพร้อมแล้ว ในกรณีอื่นๆ อาจเป็นตัวเลือก UI เพื่อแสดงองค์ประกอบที่ซ่อนอยู่
ต้นทางทั่วไปบนเว็บไม่มีโอกาสที่จะเกิดความล่าช้าในการแสดงผลมากนัก แต่ระหว่างการเพิ่มประสิทธิภาพ บางครั้งคุณอาจสร้างความล่าช้าในการแสดงผลออกไปจากเวลาที่ใช้ก่อนหน้านี้ในส่วนย่อยอื่นๆ ตัวอย่างเช่น หากหน้าเว็บเริ่มโหลดรูปภาพ LCP ล่วงหน้าเพื่อให้พร้อมใช้งานอย่างรวดเร็ว จะไม่มีการหน่วงเวลาการโหลดนานๆ แต่หากหน้าเว็บไม่พร้อมที่จะแสดงรูปภาพ เช่น จากสไตล์ชีตขนาดใหญ่ที่บล็อกการแสดงผลหรือแอปแสดงผลฝั่งไคลเอ็นต์ที่ต้องโหลด JavaScript ทั้งหมดให้เสร็จก่อนที่จะแสดงข้อมูล LCP จะยังช้ากว่าที่ควรจะเป็น และตอนนี้เวลาที่ใช้จะแสดงเป็นการหน่วงเวลาในการแสดงผล นี่จึงเป็นเหตุผลที่การแสดงผลฝั่งเซิร์ฟเวอร์หรือ HTML แบบคงที่มักมีข้อดีในแง่ของ LCP
หากเนื้อหาของคุณเองได้รับผลกระทบ โปรดอ่านคำแนะนำเพิ่มเติมเกี่ยวกับการเพิ่มประสิทธิภาพระยะเวลาก่อนที่จะเกิดการแสดงผล
ตรวจสอบส่วนย่อยทั้งหมด
เห็นได้ชัดว่าการเพิ่มประสิทธิภาพ LCP ได้อย่างมีประสิทธิภาพนั้น นักพัฒนาแอปจะต้องดูการโหลดหน้าเว็บแบบองค์รวม ไม่ใช่แค่มุ่งเน้นที่การเพิ่มประสิทธิภาพรูปภาพ หมั่นตรวจสอบ LCP ทุกๆ ส่วนเนื่องจากมีโอกาสมากขึ้นในการปรับปรุง
รูปแบบการระบุแหล่งที่มาของไลบรารีเว็บวิทัลจะรวมการกําหนดเวลาสําหรับส่วนย่อย LCP เพื่อรวบรวมข้อมูลนี้ในช่องด้วย รายงานประสบการณ์ของผู้ใช้ Chrome (CrUX) ยังไม่รวมข้อมูลทั้งหมดนี้ แต่มีรายการสำหรับ TTFB และ LCP จึงเป็นจุดเริ่มต้น เราหวังว่าจะรวมข้อมูลที่ใช้สำหรับโพสต์นี้ไว้ใน CrUX ในอนาคต โปรดติดตามข่าวสารเพิ่มเติมเกี่ยวกับเรื่องนี้
สำหรับการทดสอบส่วนย่อย LCP ในเครื่อง ให้ลองใช้ส่วนขยาย Web Vitals หรือข้อมูลโค้ด JavaScript ในบทความนี้ Lighthouse ยังมีรายละเอียดใน "องค์ประกอบ Largest Contentful Paint" ด้วย การตรวจสอบ ดูคำแนะนำเพิ่มเติมเกี่ยวกับส่วนย่อยของ LCP ได้ในแผงประสิทธิภาพของเครื่องมือสำหรับนักพัฒนาเว็บเร็วๆ นี้