วิธีแก้ปัญหา LCP ช้าจากรูปภาพ

แก้ไขปัญหาความเร็ว Largest Contentful Paint (LCP) ที่ช้าของรูปภาพใน 4 ขั้นตอน: ปรับขนาดให้เท่ากับขนาดที่แสดงจริง แปลงเป็น WebP หรือ AVIF, ทำการพรีโหลด และตั้งค่า fetchpriority เป็น high 2 ขั้นตอนแรกจะช่วยเพิ่มประสิทธิภาพได้มากที่สุดและไม่ต้องแก้ไขโค้ด HTML ของหน้าเว็บเลย

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

LCP วัดค่าจากอะไร

LCP บันทึกเวลาที่องค์ประกอบที่มองเห็นได้ขนาดใหญ่ที่สุดใช้ในการเรนเดอร์ โดยวัดตั้งแต่เริ่มต้นโหลดหน้าเว็บ Google กำหนดว่า 2.5 วินาทีหรือน้อยกว่านั้นถือว่าดี, ระหว่าง 2.5 ถึง 4 วินาทีต้องปรับปรุง และมากกว่า 4 วินาทีถือว่าแย่

องค์ประกอบที่วัดมักจะเป็นรูปภาพ บางครั้งอาจเป็นข้อความหัวข้อ และเป็นสิ่งที่มองเห็นได้โดยไม่ต้องเลื่อนหน้าจอ องค์ประกอบนี้อาจเปลี่ยนแปลงไปตามอุปกรณ์ เนื่องจากรูปภาพฮีโร่ที่โดดเด่นในหน้าจอเดสก์ท็อปอาจอยู่ต่ำกว่าขอบหน้าจอ (Below the fold) บนมือถือ

การค้นหาองค์ประกอบที่เป็นต้นเหตุ

เรียกใช้งาน Lighthouse และดูที่รายการองค์ประกอบ Largest Contentful Paint ซึ่งจะระบุชื่อองค์ประกอบที่กำลังวัดอย่างแม่นยำ การเดาจะทำให้เสียเวลา เนื่องจากบ่อยครั้งองค์ประกอบนั้นไม่ใช่สิ่งที่เราคาดคิดไว้

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

แก้ไขรูปภาพตามลำดับความสำคัญ

เพื่อปรับปรุง LCP ของรูปภาพ ให้ทำตาม 6 ขั้นตอนนี้ตามลำดับ

1. ปรับขนาดรูปภาพให้เท่ากับขนาดที่ใหญ่ที่สุดที่จะแสดงผล โดยคูณสองสำหรับหน้าจอความหนาแน่นสูง
2. แปลงเป็น WebP หรือ AVIF หากรูปภาพมีขนาดใหญ่และเป็นภาพถ่าย
3. บีบอัดให้มีขนาดเป้าหมายต่ำกว่า 200 KB สำหรับรูปภาพฮีโร่ ซึ่งสามารถทำได้ที่ความกว้างเต็มหน้าจอในดีไซน์ส่วนใหญ่
4. เพิ่มแอตทริบิวต์ width และ height เพื่อให้เบราว์เซอร์จองพื้นที่ไว้และป้องกันการเลื่อนหลุดของเลย์เอาต์ (Layout Shift)
5. พรีโหลด (Preload) รูปภาพในส่วน head ของหน้า เพื่อให้เบราว์เซอร์เริ่มดึงข้อมูลทันที
6. ตั้งค่า fetchpriority เป็น high ที่องค์ประกอบรูปภาพ เพื่อบอกเบราว์เซอร์ว่าไฟล์นี้มีความสำคัญสูงสุด

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

ทำไมการปรับขนาดถึงดีกว่าการบีบอัด

ขนาด (Dimensions) เป็นตัวกำหนดขนาดไฟล์ส่วนใหญ่ ดังนั้นการปรับขนาดจึงช่วยลดน้ำหนักไฟล์ได้มากกว่าการตั้งค่าคุณภาพใดๆ ภาพถ่ายขนาด 4000 พิกเซลที่แสดงผลที่ขนาด 1200 พิกเซล มีข้อมูลพิกเซลมากกว่าที่หน้าจอจะแสดงผลได้ถึง 11 เท่า

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

Preload และ fetchpriority

การพรีโหลด (Preloading) จะบอกให้เบราว์เซอร์ดึงข้อมูลรูปภาพฮีโร่ก่อนที่จะแยกวิเคราะห์ (Parsing) หน้าเว็บเสร็จสิ้น ซึ่งโดยปกติจะช่วยประหยัดเวลาได้ 200 ถึง 500 มิลลิวินาที การตั้งค่านี้สำคัญเนื่องจากเบราว์เซอร์มักจะค้นพบรูปภาพช้าในกระบวนการแยกวิเคราะห์

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

ข้อผิดพลาดที่ทำให้ LCP แย่ลง

• การใช้ Lazy Loading กับรูปภาพฮีโร่ การทำ Lazy Loading จะเป็นการหน่วงไฟล์ที่คุณต้องการใช้งานก่อนเป็นอันดับแรก ให้ใช้เฉพาะกับรูปภาพที่อยู่ต่ำกว่าขอบหน้าจอเท่านั้น
• การโหลดรูปภาพผ่าน JavaScript รูปภาพที่แทรกด้วยสคริปต์จะไม่สามารถเริ่มดาวน์โหลดได้จนกว่าสคริปต์จะทำงานเสร็จ
• การใช้ภาพพื้นหลัง CSS (CSS Background Image) ภาพพื้นหลังจะถูกค้นพบช้ากว่าแท็ก img และไม่สามารถกำหนดลำดับความสำคัญได้ง่าย
• การพรีโหลดรูปภาพหลายรูป การแข่งขันกันของลำดับความสำคัญจะทำให้ข้อดีหายไปทั้งหมด
• การละเว้นการระบุ width และ height การเลื่อนหลุดของเลย์เอาต์ (Layout Shift) จะสร้างปัญหาให้กับการวัดผลส่วนอื่นในขณะที่ส่วนนี้ดีขึ้น

เมื่อองค์ประกอบ LCP เป็นข้อความ

LCP ที่เป็นข้อความมักจะถูกหน่วงเวลาด้วยเว็บฟอนต์ (Web Fonts) มากกว่าตัวข้อความเอง เบราว์เซอร์มีคำศัพท์พร้อมทันทีแต่ต้องรอไฟล์ฟอนต์ก่อนจึงจะเรนเดอร์ได้

ตั้งค่า font-display เป็น swap เพื่อให้ข้อความเรนเดอร์ด้วยฟอนต์สำรองและเปลี่ยนเมื่อเว็บฟอนต์โหลดเสร็จ พรีโหลดไฟล์ฟอนต์ที่สำคัญที่สุดเพียงไฟล์เดียว และจำกัดชุดตัวอักษร (Subset) เฉพาะตัวอักษรที่หน้าเว็บของคุณใช้งานจริง ซึ่งมักจะช่วยลดขนาดฟอนต์จาก 200 KB เหลือไม่ถึง 30 KB การเสิร์ฟฟอนต์จากโดเมนของคุณเองช่วยตัดการเชื่อมต่อกับบุคคลที่สามออกไปได้อีกหนึ่งช่องทาง

เวลาตอบสนองของเซิร์ฟเวอร์เป็นตัวกำหนดขีดจำกัด

LCP ไม่สามารถเร็วไปกว่าเวลาที่เซิร์ฟเวอร์ของคุณใช้ในการส่งไบต์แรกกลับมาได้ (Time to First Byte) ดังนั้นเซิร์ฟเวอร์ที่ช้าจึงเป็นตัวจำกัดการปรับปรุงอื่นๆ ทั้งหมด ควรตั้งเป้าหมายให้น้อยกว่า 600 มิลลิวินาทีสำหรับไบต์แรก

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

สคริปต์ของบุคคลที่สามก็ทำให้รูปภาพช้าเช่นกัน

เครื่องมือวิเคราะห์, แบนเนอร์ขอความยินยอม (Consent banners), วิดเจ็ตแชท และสคริปต์โฆษณา จะแย่งแบนด์วิดท์และเวลาประมวลผลกับรูปภาพฮีโร่ของคุณ รูปภาพที่ปรับแต่งมาอย่างสมบูรณ์แบบก็ยังคงเรนเดอร์ช้าได้หากมีสคริปต์ 12 ตัวโหลดนำหน้ามัน

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

การทดสอบการเปลี่ยนแปลงอย่างถูกต้อง

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

ตรวจสอบว่าเบราว์เซอร์ได้รับไฟล์ที่มีขนาด็เล็กลงจริง เปิดเครื่องมือสำหรับนักพัฒนา (Developer Tools), สลับไปที่แท็บ Network, กรองด้วยรูปภาพ และรีโหลดหน้าเว็บ ขนาดที่ถ่ายโอนและรูปแบบจะปรากฏในรายการ หน้าเว็บที่ยังคงเสิร์ฟไฟล์เก่ามักจะหมายความว่ามีชั้นแคชที่เก็บเวอร์ชันก่อนหน้าไว้ ไม่ใช่ว่าการปรับแต่งล้มเหลว

รักษาความเร็ว LCP ให้คงหลังจากแก้ไขแล้ว

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

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

การเตรียมรูปภาพฮีโร่ให้เสร็จในครั้งเดียว

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

ตั้งค่าความกว้างและเป้าหมาย KB เพียงครั้งเดียว วางรูปภาพลงไป และทุกไฟล์จะออกมาตรงตามที่กำหนด สามารถรันได้สูงสุด 500 รูปต่อครั้ง ทำงานภายในเบราว์เซอร์ของคุณบนโปรเซสเซอร์ของคุณเองทั้งหมด ไม่มีฃการอัปโหลด ดังนั้นสินทรัพย์ที่อยู่ระหว่างการเตรียมการ, หน้าแคมเปญที่ยังไม่เผยแพร่ และงานของลูกค้าจะยังคงอยู่ในเครื่องของคุณในขณะที่คลังภาพทั้งหมดถูกเตรียมพร้อม