เพิ่มประสิทธิภาพการแสดงผลเนื้อหาขนาดใหญ่ที่สุด

คำแนะนำแบบทีละขั้นตอนเกี่ยวกับวิธีแจกแจง LCP และระบุประเด็นหลักที่ต้องปรับปรุง

Philip Walton

Barry Pollard

เผยแพร่เมื่อวันที่ 30 เม.ย. 2020

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

เพื่อให้ผู้ใช้ได้รับประสบการณ์การใช้งานที่ดี เว็บไซต์ควรพยายามมี LCP ไม่เกิน 2.5 วินาทีสำหรับการเข้าชมหน้าเว็บอย่างน้อย 75%

มีปัจจัยหลายอย่างที่อาจมีผลต่อความเร็วที่เบราว์เซอร์โหลดและแสดงผลหน้าเว็บ และความล่าช้าในแต่ละปัจจัยนั้นอาจมีผลกระทบอย่างมากต่อ LCP

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

ทำความเข้าใจเมตริก LCP

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

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

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

การใช้ข้อมูล CrUX LCP ใน PageSpeed Insights

PageSpeed Insights ให้สิทธิ์เข้าถึงข้อมูล CrUX ในส่วนด้านบนที่มีป้ายกำกับว่าดูประสบการณ์การใช้งานของผู้ใช้จริง สามารถดูข้อมูลเกี่ยวกับห้องทดลองที่ละเอียดยิ่งขึ้นได้ในส่วนด้านล่างซึ่งมีป้ายกำกับว่าวิเคราะห์ปัญหาด้านประสิทธิภาพ หากข้อมูล CrUX พร้อมใช้งานสําหรับเว็บไซต์ของคุณ ให้มุ่งเน้นที่ข้อมูลผู้ใช้จริงก่อนเสมอ

PageSpeed Insights จะแสดงข้อมูล CrUX ที่แตกต่างกันสูงสุด 4 รายการ ดังนี้

• ข้อมูลอุปกรณ์เคลื่อนที่สําหรับ URL นี้
• ข้อมูลเดสก์ท็อปสำหรับ URL นี้
• อินเทอร์เน็ตมือถือสำหรับต้นทางทั้งหมด
• ข้อมูลเดสก์ท็อปสำหรับต้นทางทั้งหมด

คุณสลับการตั้งค่าเหล่านี้ได้ในการควบคุมที่ด้านบนและด้านขวาบนของส่วนนี้ หาก URL มีข้อมูลไม่เพียงพอที่จะแสดงที่ระดับ URL แต่มีข้อมูลสําหรับต้นทาง PageSpeed Insights จะแสดงข้อมูลต้นทางเสมอ

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

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

การใช้เมตริกเสริมของ CrUX ใน PageSpeed Insights

ผู้ที่ต้องการเพิ่มประสิทธิภาพ LCP ควรใช้การวัดเวลา First Contentful Paint (FCP) และ Time to First Byte (TTFB) ด้วย ซึ่งเป็นเมตริกการวินิจฉัยที่ดีซึ่งให้ข้อมูลเชิงลึกที่เป็นประโยชน์เกี่ยวกับ LCP

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

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

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

ค่าต่างระหว่าง TTFB กับ FCP ที่มากอาจบ่งชี้ว่าเบราว์เซอร์ต้องดาวน์โหลดชิ้นงานที่บล็อกการแสดงผลจํานวนมาก หรืออาจเป็นสัญญาณว่าต้องดำเนินการหลายอย่างเพื่อแสดงผลเนื้อหาที่มีความหมาย โดยเป็นสัญญาณแบบคลาสสิกของเว็บไซต์ที่อาศัยการแสดงผลฝั่งไคลเอ็นต์อย่างมาก

ค่าต่างที่มากระหว่าง FCP กับ LCP บ่งชี้ว่าเบราว์เซอร์ไม่สามารถจัดลําดับความสําคัญของทรัพยากร LCP ได้ทันที (เช่น ข้อความหรือรูปภาพที่จัดการโดย JavaScript แทนที่จะอยู่ใน HTML เริ่มต้น) หรือเบราว์เซอร์กําลังทํางานอื่นๆ ให้เสร็จสิ้นก่อนที่จะแสดงเนื้อหา LCP ได้

การใช้ข้อมูล PageSpeed Insights Lighthouse

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

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

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

เราจะกล่าวถึงส่วนย่อยๆ ต่อไป

รายละเอียด LCP

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

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

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

1. เอกสาร HTML เริ่มต้น
2. ทรัพยากร LCP (หากมี)

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

หากต้องการระบุทรัพยากร LCP คุณสามารถใช้เครื่องมือสําหรับนักพัฒนาซอฟต์แวร์ (เช่น PageSpeed Insights ที่กล่าวถึงก่อนหน้านี้, เครื่องมือสําหรับนักพัฒนาเว็บใน Chrome หรือ WebPageTest) เพื่อระบุองค์ประกอบ LCP จากจุดนั้น คุณจะจับคู่ URL (อีกครั้งหากมี) ที่โหลดโดยองค์ประกอบใน Waterfall เครือข่ายของทรัพยากรทั้งหมดที่หน้าเว็บโหลดได้

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

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

เวลาที่ได้รับข้อมูลไบต์แรก (TTFB)

ระยะเวลาตั้งแต่ผู้ใช้เริ่มโหลดหน้าเว็บจนถึงเบราว์เซอร์ จะได้รับไบต์แรกของการตอบกลับเอกสาร HTML

ความล่าช้าในการโหลดทรัพยากร

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

ระยะเวลาในการโหลดทรัพยากร

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

ความล่าช้าในการแสดงผลองค์ประกอบ

เวลาที่ผ่านไประหว่างที่ทรัพยากร LCP โหลดเสร็จและองค์ประกอบ LCP แสดงผลอย่างสมบูรณ์

LCP ของทุกหน้าประกอบด้วยหมวดหมู่ย่อย 4 หมวดหมู่นี้ โดยไม่มีช่องว่างหรือทับซ้อนกัน และรวมกันเป็นเวลา LCP ทั้งหมด

หน้าเว็บแต่ละหน้าอาจมีค่า LCP ที่แบ่งออกเป็น 4 ส่วนย่อยเหล่านี้ ไม่มีการทับซ้อนหรือช่องว่างระหว่างกัน โดยเมื่อนำมารวมกันแล้วเป็นเวลา LCP เต็ม

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

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

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

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

เวลาของส่วนย่อยที่เหมาะสมที่สุด

ในการเพิ่มประสิทธิภาพส่วนย่อยแต่ละส่วนของ LCP คุณต้องทําความเข้าใจถึงรายละเอียดที่เหมาะสมของส่วนย่อยเหล่านี้ในหน้าที่เพิ่มประสิทธิภาพมาอย่างดี

จาก 4 ส่วนย่อย มี 2 ส่วนมีคำว่า "ล่าช้า" ในชื่อ สัญญาณเหล่านี้คือสัญญาณว่าคุณต้องการให้หาเวลาเหล่านี้ใกล้กับ 0 มากที่สุด อีก 2 ส่วนเกี่ยวข้องกับคำขอเครือข่าย ซึ่งตามธรรมชาติแล้วต้องใช้เวลา

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

วิธีที่ดีในการพิจารณารายละเอียดเวลา LCP มีดังนี้

• เวลา LCP ส่วนใหญ่ควรใช้เวลาโหลดเอกสาร HTML และแหล่งที่มา LCP
• ช่วงเวลาใดก็ตามก่อน LCP ที่ทรัพยากรรายการใดรายการหนึ่งจาก 2 รายการนี้ไม่โหลด จะถือเป็นโอกาสในการปรับปรุง

วิธีเพิ่มประสิทธิภาพแต่ละส่วน

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

ส่วน 4 ส่วนถัดไปจะแสดงคําแนะนําและแนวทางปฏิบัติแนะนําสําหรับวิธีเพิ่มประสิทธิภาพแต่ละส่วน รายการจะแสดงตามลําดับ โดยเริ่มจากการเพิ่มประสิทธิภาพที่มีแนวโน้มจะให้ผลลัพธ์สูงสุด

1. กำจัดความล่าช้าในการโหลดทรัพยากร

เป้าหมายในขั้นตอนนี้คือการดูแลให้ทรัพยากร LCP เริ่มโหลดโดยเร็วที่สุด แม้ว่าในทางทฤษฎี ทรัพยากรอาจเริ่มโหลดได้ทันทีหลังจาก TTFB แต่ในทางปฏิบัติมักจะมีความล่าช้าเกิดขึ้นก่อนที่เบราว์เซอร์จะเริ่มโหลดทรัพยากร

หลักการง่ายๆ คือทรัพยากร LCP ควรเริ่มโหลดพร้อมกันกับทรัพยากรแรกซึ่งหน้าเว็บนั้นโหลด หรือกล่าวอีกนัยหนึ่งคือ หากทรัพยากร LCP เริ่มโหลดหลังจากทรัพยากรแรก แสดงว่ามีโอกาสปรับปรุง

โดยทั่วไปแล้ว ปัจจัย 2 อย่างที่ส่งผลต่อความเร็วในการโหลดทรัพยากร LCP มีดังนี้

• เมื่อพบทรัพยากร
• ลำดับความสำคัญของทรัพยากรที่ระบุ

เพิ่มประสิทธิภาพเมื่อพบทรัพยากร

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

• องค์ประกอบ LCP คือองค์ประกอบ <img> และแอตทริบิวต์ src หรือ srcset ขององค์ประกอบนั้นอยู่ในมาร์กอัป HTML เริ่มต้น
• องค์ประกอบ LCP ต้องใช้ภาพพื้นหลัง CSS แต่ระบบจะโหลดรูปภาพนั้นล่วงหน้าโดยใช้ <link rel="preload"> ในมาร์กอัป HTML (หรือใช้ส่วนหัว Link)
• องค์ประกอบ LCP คือโหนดข้อความที่จำเป็นต้องใช้แบบอักษรเว็บในการแสดงผล และโหลดแบบอักษรโดยใช้ <link rel="preload"> ในมาร์กอัป HTML (หรือใช้ส่วนหัว Link)

ต่อไปนี้คือตัวอย่างบางส่วนที่ระบบไม่พบทรัพยากร LCP จากการสแกนการตอบกลับเอกสาร HTML

• องค์ประกอบ LCP คือ <img> ที่เพิ่มลงในหน้าเว็บแบบไดนามิกโดยใช้ JavaScript
• องค์ประกอบ LCP โหลดแบบ Lazy Loading ด้วยไลบรารี JavaScript ที่ซ่อนแอตทริบิวต์ src หรือ srcset (มักเป็น data-src หรือ data-srcset)
• องค์ประกอบ LCP ต้องใช้ภาพพื้นหลัง CSS

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

ทรัพยากร LCP ควรค้นพบได้จากแหล่งที่มาของ HTML เพื่อขจัดความล่าช้าในการโหลดทรัพยากรที่ไม่จำเป็น ในกรณีที่มีการอ้างอิงทรัพยากรจากไฟล์ JavaScript หรือ CSS ภายนอกเท่านั้น คุณควรโหลดทรัพยากร LCP ไว้ล่วงหน้าโดยมีลำดับความสำคัญในการดึงข้อมูลสูง เช่น

<!-- Load the stylesheet that will reference the LCP image. -->
<link rel="stylesheet" href="/path/to/styles.css">

<!-- Preload the LCP image with a high fetchpriority so it starts loading with the stylesheet. -->
<link rel="preload" fetchpriority="high" as="image" href="/path/to/hero-image.webp" type="image/webp">

เพิ่มประสิทธิภาพลําดับความสําคัญของทรัพยากร

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

เช่น คุณสามารถเลื่อนเวลารูปภาพ LCP โดยใช้ HTML ได้หากตั้งค่า loading="lazy" ในองค์ประกอบ <img> การใช้การโหลดแบบ Lazy Loading จะทำให้ทรัพยากรไม่โหลดจนกว่าเลย์เอาต์จะยืนยันว่ารูปภาพอยู่ในวิวพอร์ตแล้ว และอาจทำให้เริ่มโหลดช้ากว่าที่ควรจะเป็น

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

<img fetchpriority="high" src="/path/to/hero-image.webp">

คุณควรตั้งค่า fetchpriority="high" ในองค์ประกอบ <img> หากคิดว่าองค์ประกอบดังกล่าวมีแนวโน้มที่จะเป็นองค์ประกอบ LCP ของหน้า อย่างไรก็ตาม การตั้งค่าลำดับความสำคัญสูงให้กับรูปภาพมากกว่า 1-2 รูปจะทำให้การตั้งค่าลำดับความสำคัญไม่เป็นประโยชน์ในการลด LCP

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

<img fetchpriority="low" src="/path/to/carousel-slide-3.webp">

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

หลังจากเพิ่มประสิทธิภาพลําดับความสําคัญของทรัพยากร LCP และเวลาในการค้นพบแล้ว การแสดงโฆษณาสื่อกลางตามลำดับขั้นควรมีลักษณะดังนี้ (โดยทรัพยากร LCP จะเริ่มต้นในเวลาเดียวกับทรัพยากรแรก)

2. กำจัดความล่าช้าในการแสดงผลองค์ประกอบ

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

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

• การแสดงผลทั้งหน้าถูกบล็อกเนื่องจากสไตลชีตหรือสคริปต์แบบซิงค์ใน <head> ที่ยังคงโหลดอยู่
• ทรัพยากร LCP โหลดเสร็จแล้ว แต่ยังไม่ได้เพิ่มองค์ประกอบ LCP ลงใน DOM (กําลังรอให้โค้ด JavaScript โหลด)
• องค์ประกอบถูกซ่อนโดยโค้ดอื่น เช่น ไลบรารีการทดสอบ A/B ที่กําลังกําหนดว่าผู้ใช้ควรอยู่ในการทดสอบใด
• เทรดหลักถูกบล็อกเนื่องจากงานที่มีระยะเวลานาน และงานแสดงผลต้องรอจนกว่างานที่มีระยะเวลานานเหล่านั้นจะเสร็จสมบูรณ์

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

ลดการใช้หรือแทรกสไตล์ชีตการบล็อกการแสดงผล

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

ในการแก้ไขปัญหานี้ คุณมีตัวเลือกดังนี้

• แทรกสไตล์ชีตลงใน HTML เพื่อหลีกเลี่ยงคำขอเครือข่ายเพิ่มเติม หรือ
• ลดขนาดของสไตล์ชีต

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

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

คำแนะนำในการลดขนาดของสไตล์ชีตมีดังนี้

• นำ CSS ที่ไม่ได้ใช้ออก: ใช้ Chrome DevTools เพื่อค้นหากฎ CSS ที่ไม่ได้ใช้งานและอาจนำออก (หรือเลื่อนออกไป)
• เลื่อน CSS ที่ไม่สําคัญ: แยกชีตสไตล์ออกเป็นสไตล์ที่จําเป็นสําหรับการโหลดหน้าเว็บครั้งแรก แล้วแยกเป็นสไตล์ที่โหลดแบบเลื่อนได้
• ย่อและบีบอัด CSS: สำหรับรูปแบบที่สำคัญ ให้ลดขนาดการโอนให้ได้มากที่สุด

เลื่อน JavaScript ที่บล็อกการแสดงผลออกไปหรือแทรกในหน้า

คุณแทบไม่จําเป็นต้องเพิ่มสคริปต์แบบซิงค์ (สคริปต์ที่ไม่มีแอตทริบิวต์ async หรือ defer) ลงใน <head> ของหน้าเว็บ และการทำเช่นนั้นมักจะส่งผลเสียต่อประสิทธิภาพ

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

<head>
  <script src="/path/to/main.js"></script>
</head>

<head>
  <script>
    // Inline script contents directly in the HTML.
    // IMPORTANT: only do this for very small scripts.
  </script>
</head>

ใช้การแสดงผลฝั่งเซิร์ฟเวอร์

การแสดงผลฝั่งเซิร์ฟเวอร์ (SSR) คือกระบวนการเรียกใช้ตรรกะแอปพลิเคชันฝั่งไคลเอ็นต์บนเซิร์ฟเวอร์และตอบสนองต่อคําขอเอกสาร HTML ด้วยมาร์กอัป HTML แบบเต็ม

จากมุมมองการเพิ่มประสิทธิภาพ LCP SSR มีข้อดีหลักๆ 2 ข้อดังนี้

• ทรัพยากรรูปภาพจะค้นพบได้จากแหล่งที่มา HTML (ตามที่ได้อธิบายไว้ในขั้นตอนที่ 1 ก่อนหน้านี้)
• เนื้อหาของหน้าจะไม่ต้องส่งคำขอ JavaScript เพิ่มเติมก่อนจึงจะแสดงผลได้

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

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

แบ่งงานที่ใช้เวลานาน

แม้ว่าคุณจะทำตามคำแนะนำก่อนหน้านี้และโค้ด JavaScript ไม่บล็อกการแสดงผลหรือมีหน้าที่ในการแสดงผลองค์ประกอบ แต่โค้ดดังกล่าวก็ยังคงทำให้ LCP ล่าช้าได้

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

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

3. ลดระยะเวลาการโหลดทรัพยากร

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

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

ลดขนาดของทรัพยากร

ทรัพยากร LCP ของหน้าเว็บ (หากมี) จะเป็นรูปภาพหรือแบบอักษรของเว็บ คำแนะนำต่อไปนี้อธิบายรายละเอียดเกี่ยวกับวิธีลดขนาดของทั้ง 2 ส่วน

• แสดงขนาดรูปภาพที่เหมาะสมที่สุด
• ใช้รูปแบบรูปภาพที่ทันสมัย
• บีบอัดรูปภาพ
• ลดขนาดตัวอักษรของเว็บ

ลดระยะทางที่ต้องเดินทางของทรัพยากร

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

โดยเฉพาะ CDN รูปภาพมีประโยชน์อย่างยิ่งเพราะไม่เพียงลดระยะทางที่ต้องเดินทางของทรัพยากรเท่านั้น แต่ยังช่วยลดขนาดของทรัพยากรด้วย ซึ่งจะนำคำแนะนำการลดขนาดทั้งหมดที่เคยมีมาก่อนหน้านี้ให้คุณโดยอัตโนมัติ

ลดการช่วงชิงแบนด์วิดท์ของเครือข่าย

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

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

ลดเวลาของเครือข่ายอย่างสิ้นเชิง

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

หากทรัพยากร LCP เป็นแบบอักษรของเว็บ นอกจากการลดขนาดแบบอักษรของเว็บแล้ว คุณควรพิจารณาด้วยว่าจำเป็นต้องบล็อกการแสดงผลเมื่อโหลดทรัพยากรแบบอักษรของเว็บหรือไม่ หากคุณตั้งค่า font-display เป็นค่าอื่นที่ไม่ใช่ auto หรือ block ข้อความจะแสดงอยู่เสมอระหว่างการโหลด และ LCP จะไม่ถูกบล็อกในคําขอเครือข่ายเพิ่มเติม

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

4. ลดเวลาเป็นไบต์แรก

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

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

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

สำหรับแนวทางเฉพาะเกี่ยวกับการเพิ่มประสิทธิภาพ TTFB โปรดดูคู่มือ TTFB การเพิ่มประสิทธิภาพ

ตรวจสอบรายละเอียด LCP ใน JavaScript

ข้อมูลเวลาของส่วนย่อย LCP ทั้งหมดที่กล่าวถึงก่อนหน้านี้จะแสดงใน JavaScript ผ่าน API ประสิทธิภาพต่อไปนี้

• Largest Contentful Paint API
• Navigation Timing API
• Resource Timing API

ประโยชน์ของการคำนวณค่าเวลาเหล่านี้ใน JavaScript คือคุณสามารถส่งค่าไปยังผู้ให้บริการวิเคราะห์หรือบันทึกค่าไปยังเครื่องมือสำหรับนักพัฒนาซอฟต์แวร์ของคุณเพื่อช่วยในการแก้ไขข้อบกพร่องและเพิ่มประสิทธิภาพ

เช่น ภาพหน้าจอต่อไปนี้ใช้เมธอด performance.measure() จาก User Timing API เพื่อเพิ่มแถบลงในแทร็กเวลาในแผงประสิทธิภาพของเครื่องมือสำหรับนักพัฒนาเว็บใน Chrome

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

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

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

ภาพข้อมูลทั้ง 2 รายการนี้สร้างขึ้นด้วยโค้ดต่อไปนี้

const LCP_SUB_PARTS = [
  'Time to first byte',
  'Resource load delay',
  'Resource load duration',
  'Element render delay',
];

new PerformanceObserver((list) => {
  const lcpEntry = list.getEntries().at(-1);
  const navEntry = performance.getEntriesByType('navigation')[0];
  const lcpResEntry = performance
    .getEntriesByType('resource')
    .filter((e) => e.name === lcpEntry.url)[0];

  // Ignore LCP entries that aren't images to reduce DevTools noise.
  // Comment this line out if you want to include text entries.
  if (!lcpEntry.url) return;

  // Compute the start and end times of each LCP sub-part.
  // WARNING! If your LCP resource is loaded cross-origin, make sure to add
  // the `Timing-Allow-Origin` (TAO) header to get the most accurate results.
  const ttfb = navEntry.responseStart;
  const lcpRequestStart = Math.max(
    ttfb,
    // Prefer `requestStart` (if TOA is set), otherwise use `startTime`.
    lcpResEntry ? lcpResEntry.requestStart || lcpResEntry.startTime : 0
  );
  const lcpResponseEnd = Math.max(
    lcpRequestStart,
    lcpResEntry ? lcpResEntry.responseEnd : 0
  );
  const lcpRenderTime = Math.max(
    lcpResponseEnd,
    // Use LCP startTime (the final LCP time) because there are sometimes
    // slight differences between loadTime/renderTime and startTime
    // due to rounding precision.
    lcpEntry ? lcpEntry.startTime : 0
  );

  // Clear previous measures before making new ones.
  // Note: due to a bug, this doesn't work in Chrome DevTools.
  LCP_SUB_PARTS.forEach((part) => performance.clearMeasures(part));

  // Create measures for each LCP sub-part for easier
  // visualization in the Chrome DevTools Performance panel.
  const lcpSubPartMeasures = [
    performance.measure(LCP_SUB_PARTS[0], {
      start: 0,
      end: ttfb,
    }),
    performance.measure(LCP_SUB_PARTS[1], {
      start: ttfb,
      end: lcpRequestStart,
    }),
    performance.measure(LCP_SUB_PARTS[2], {
      start: lcpRequestStart,
      end: lcpResponseEnd,
    }),
    performance.measure(LCP_SUB_PARTS[3], {
      start: lcpResponseEnd,
      end: lcpRenderTime,
    }),
  ];

  // Log helpful debug information to the console.
  console.log('LCP value: ', lcpRenderTime);
  console.log('LCP element: ', lcpEntry.element, lcpEntry.url);
  console.table(
    lcpSubPartMeasures.map((measure) => ({
      'LCP sub-part': measure.name,
      'Time (ms)': measure.duration,
      '% of LCP': `${
        Math.round((1000 * measure.duration) / lcpRenderTime) / 10
      }%`,
    }))
  );
}).observe({type: 'largest-contentful-paint', buffered: true});

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

ตรวจสอบรายละเอียด LCP โดยใช้เครื่องมือสำหรับนักพัฒนาเว็บใน Chrome

เครื่องมือสำหรับนักพัฒนาเว็บใน Chrome จะบันทึกเวลา LCP, องค์ประกอบ LCP และส่วนย่อยทั้ง 4 ส่วนแบบเรียลไทม์เพื่อให้คุณดูรายละเอียดนี้ได้

สรุป

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

การเพิ่มประสิทธิภาพ LCP โดยสรุปได้ใน 4 ขั้นตอนดังนี้

1. ตรวจสอบว่าทรัพยากร LCP เริ่มโหลดโดยเร็วที่สุด
2. ตรวจสอบว่าองค์ประกอบ LCP แสดงผลได้ทันทีที่ทรัพยากรโหลดเสร็จ
3. ลดเวลาในการโหลดทรัพยากร LCP มากที่สุดโดยไม่ลดคุณภาพ
4. ส่งเอกสาร HTML เริ่มต้นโดยเร็วที่สุด

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