คำแนะนำทีละขั้นตอนเกี่ยวกับวิธีจำแนก LCP และระบุส่วนสำคัญที่ควรปรับปรุง
การแสดงผลเนื้อหาขนาดใหญ่ที่สุด (LCP) เป็น 1 ใน 3 เมตริกของ Core Web Vitals และแสดงให้เห็นความเร็วที่เนื้อหาหลักของหน้าเว็บโหลด กล่าวคือ 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 ข้อต่อไปนี้
- เอกสาร HTML เริ่มต้น
- ทรัพยากร 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 หมวดหมู่ย่อยนี้ ไม่มีช่องว่างหรือการซ้อนทับ ระหว่าง 2 สิ่งนี้ จากนั้นจะรวมเวลา 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 และเวลาในการค้นหาแล้ว Waterfall ของเครือข่ายควรมีลักษณะดังนี้ (โดยทรัพยากร 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 ที่ไม่สำคัญ: แบ่งสไตล์ชีตออกเป็นรูปแบบที่จำเป็นสำหรับการโหลดหน้าเว็บเริ่มต้น จากนั้นใช้รูปแบบที่โหลดแบบ Lazy Loading
- ย่อและบีบอัด 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 นั้น มีข้อได้เปรียบหลักๆ 2 ข้อของ SSR ดังนี้
- ทรัพยากรรูปภาพจะค้นพบได้จากแหล่งที่มา 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 ทำงานช้าสำหรับเว็บไซต์ที่โหลดเร็ว คือผู้เข้าชมที่มาถึงโดยการเปลี่ยนเส้นทางหลายครั้ง เช่น จากโฆษณาหรือลิงก์แบบย่อ ลดจำนวนการเปลี่ยนเส้นทางที่ผู้เข้าชมจะต้องรออยู่เสมอ
สาเหตุที่พบบ่อยอีกอย่างหนึ่งคือเมื่อไม่สามารถใช้เนื้อหาที่แคชไว้จากเซิร์ฟเวอร์ CDN Edge ได้ และต้องส่งคำขอทั้งหมดกลับไปที่เซิร์ฟเวอร์ต้นทาง กรณีนี้อาจเกิดขึ้นได้หากผู้เข้าชมใช้พารามิเตอร์ของ URL ที่ไม่ซ้ำสำหรับการวิเคราะห์ แม้ว่าไม่ได้ทำให้หน้าเว็บต่างกันก็ตาม
สำหรับแนวทางเฉพาะเกี่ยวกับการเพิ่มประสิทธิภาพ TTFB โปรดดูคู่มือ TTFB การเพิ่มประสิทธิภาพ
ตรวจสอบรายละเอียด LCP ใน JavaScript
ข้อมูลช่วงเวลาสำหรับส่วนย่อย LCP ทั้งหมดที่กล่าวถึงก่อนหน้านี้พร้อมให้คุณใช้งานใน JavaScript ผ่าน 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 โดยใช้ส่วนขยาย Web Vitals
ส่วนขยาย Web Vitals จะบันทึกเวลา LCP, องค์ประกอบ LCP และส่วนย่อยทั้ง 4 ส่วนนี้ในคอนโซลเพื่อให้คุณดูรายละเอียดนี้ได้อย่างง่ายดาย
สรุป
LCP มีความซับซ้อน และระยะเวลาอาจได้รับผลกระทบจากปัจจัยหลายประการ แต่หากคุณเห็นว่าการเพิ่มประสิทธิภาพ LCP คือการเพิ่มประสิทธิภาพภาระงานของทรัพยากร LCP เป็นหลัก สิ่งต่างๆ อาจช่วยลดความซับซ้อนได้อย่างมาก
การเพิ่มประสิทธิภาพ LCP โดยสรุปได้ใน 4 ขั้นตอนดังนี้
- ตรวจสอบว่าทรัพยากร LCP เริ่มโหลดโดยเร็วที่สุด
- ตรวจสอบว่าองค์ประกอบ LCP แสดงผลได้ทันทีที่ทรัพยากรโหลดเสร็จสิ้น
- ลดเวลาในการโหลดทรัพยากร LCP มากที่สุดโดยไม่ลดคุณภาพ
- ส่งเอกสาร HTML เริ่มต้นโดยเร็วที่สุด
หากทำตามขั้นตอนเหล่านี้ในหน้าเว็บได้ คุณก็ควรมั่นใจว่ามอบประสบการณ์การโหลดที่ดีที่สุดแก่ผู้ใช้และน่าจะเห็นตัวเลขนี้ในคะแนน LCP ในชีวิตจริงของคุณ