หน้าบทความที่มีภาพปกใหญ่ช่วยให้คนอ่านเห็นเรื่องที่จะเล่าได้เร็ว แต่ภาพเดียวกันก็อาจเป็นสิ่งที่หน้าต้องรอก่อนจะดูพร้อมอ่าน โดยเฉพาะเมื่อเปิดจากโทรศัพท์ที่เครือข่ายกับกำลังประมวลผลต่างจากเครื่องที่เราใช้ทำเว็บ
พอจะปรับความเร็ว หลายครั้งเราจึงเริ่มจากลดไฟล์รูป ซึ่งเป็นงานที่มีประโยชน์ แต่ยังมีคำถามก่อนหน้านั้นว่ารูปที่กำลังลดเป็นสิ่งที่กำหนด LCP ของหน้าจริงหรือไม่ และเบราว์เซอร์เริ่มรู้จักรูปนั้นตอนไหน
ถ้าแยกสองเรื่องนี้ได้ เราจะเลือกแก้ได้ตรงขึ้นครับ เพราะรูปที่ดาวน์โหลดไวแต่ถูกพบช้า กับรูปที่เริ่มโหลดเร็วแต่ไฟล์ใหญ่ เป็นคนละเหตุให้คนอ่านต้องรอ
LCP หรือ Largest Contentful Paint บอกจังหวะที่ภาพหรือกลุ่มข้อความขนาดใหญ่ที่สุดตามเกณฑ์ในพื้นที่มองเห็นถูกวาดขึ้น ระหว่างเปิดหน้าอาจมี candidate เปลี่ยนได้ จึงควรดูผลของรอบนั้นจากเครื่องมือ ไม่เดาว่าภาพปกต้องเป็นคำตอบเสมอ
ในจอที่ภาพกินพื้นที่มาก ภาพอาจเป็นตัวที่ต้องตามต่อ แต่ถ้าหน้าจอหรือการจัดวางเปลี่ยน กลุ่มข้อความก็อาจมีบทบาทแทนได้ เวลาทดสอบจึงควรจด viewport และสภาพการเปิดหน้าไว้ร่วมกับผล
ใช้รายงานหรือ Performance trace หา element ที่เกี่ยวข้อง แล้วเทียบ URL ของภาพกับ Network จะเริ่มเห็นว่าโหลดไฟล์ใดจริง บางเว็บมีภาพหลายขนาด มีการแปลงผ่านบริการภาพ หรือมีภาพใน carousel ซึ่งอาจทำให้ไฟล์ที่ตรวจในโฟลเดอร์ไม่ใช่ไฟล์ที่เบราว์เซอร์เลือก
ควรดูด้วยว่ารอบที่วัดเป็นการเปิด URL ใหม่หรือเปลี่ยนหน้าภายในแอป เพราะลำดับที่ได้ข้อมูลกับสถานะแคชอาจต่างกัน หากเปลี่ยนเส้นทางทดสอบไปมาระหว่างก่อนและหลังแก้ ก็จะเทียบผลได้ยากขึ้นตั้งแต่ต้น
สำหรับ LCP ที่เป็นภาพ ลองแยกช่วงตั้งแต่เริ่มเปิดหน้าเป็นเวลารอข้อมูลแรกของเอกสาร ช่วงก่อนเริ่มโหลดรูป ระยะดาวน์โหลดรูป และเวลาตั้งแต่รูปโหลดจบจน element ถูกวาด จะช่วยให้รู้ว่าควรตามส่วนใดต่อ
ถ้า URL ของภาพมาใน HTML ตั้งแต่แรก เบราว์เซอร์มีโอกาสค้นพบได้เร็วกว่าเส้นทางที่ต้องรอ JavaScript เริ่มทำงาน เรียก API แล้วจึงสร้างรูปขึ้นมา การลดไฟล์รูปจึงไม่ได้ตัดเวลารอข้อมูลก่อนที่คำขอภาพจะเริ่ม
ในอีกกรณี ไฟล์โหลดจบแล้วแต่ยังไม่เห็นภาพ เพราะหน้ารอเงื่อนไขบางอย่างหรือมีงานบน main thread ก็ควรดูการวาดต่อ ลดขนาดไฟล์อย่างเดียวอาจเปลี่ยนเวลาช่วงหนึ่งโดยยังไม่เลื่อนเวลาที่คนอ่านเห็นภาพจริง
แผนภาพในบทนี้เป็นการแยกหน้าที่ของเวลา ไม่ใช่ waterfall จากผลวัดของเว็บใด เวลานำไปใช้ให้เก็บ trace ของหน้าจริง แล้วชี้ช่วงที่พบพร้อมเงื่อนไข ไม่กำหนดว่าทุกเว็บต้องมีคอขวดตรงเดียวกัน
ถ้าภาพอยู่ในพื้นที่แรกที่คนเห็นและเกี่ยวกับ LCP ก็ควรตรวจว่าไม่ได้ถูกเลื่อนโหลดด้วย lazy loading โดยไม่ตั้งใจ ส่วนภาพแทรกที่อยู่ไกลลงไปยังสามารถพิจารณาเลื่อนโหลดตามตำแหน่งได้ ทั้งสองกลุ่มมีความเร่งด่วนต่างกัน
ตัวอย่าง HTML สมมติสำหรับภาพหลักที่รู้ขนาดแล้วอาจเป็นแบบนี้ โดยยังต้องปรับแหล่งภาพกับวิธีเลือกขนาดให้ตรงกับหน้า:
<img
src="/images/article-cover.webp"
width="1200"
height="675"
alt="แผนผังส่วนประกอบของระบบ"
fetchpriority="high"
style="width:100%;height:auto"
>
fetchpriority เป็นคำใบ้ให้เบราว์เซอร์พิจารณาลำดับความสำคัญ ไม่ใช่คำสั่งรับประกันเวลาที่ภาพจะมา จึงควรใช้กับทรัพยากรสำคัญที่ตรวจแล้ว การให้ high กับภาพจำนวนมากก็ไม่ช่วยอธิบายว่าไฟล์ใดควรได้ทางก่อนจริง
ถ้าต้องใช้ preload ให้ตรวจว่าคำขอนั้นตรงกับไฟล์ที่ <img> จะเลือก โดยเฉพาะเมื่อมี responsive images ไม่เช่นนั้นอาจโหลดของที่ไม่ได้ใช้เพิ่ม และยังต้องรอไฟล์ที่หน้าเลือกจริงอยู่ดี ควรดู Network หลังแก้เพื่อยืนยันว่าการคาดการณ์ตรงกับพฤติกรรม
ขนาดพิกเซลควรสัมพันธ์กับพื้นที่ที่แสดงและความละเอียดหน้าจอ ไม่ส่งไฟล์ต้นฉบับขนาดใหญ่มากให้ทุกเครื่องแล้วหวังว่า CSS ที่ย่อภาพจะลดข้อมูลดาวน์โหลดให้ด้วย เพราะ CSS จัดพื้นที่ได้แต่ไม่ได้ทำให้ไฟล์ที่ขอเล็กลงเอง
การเลือก WebP หรือ AVIF ควรทดลองกับภาพชนิดนั้นและดูความคมร่วมกับน้ำหนัก โดยเฉพาะ diagram ที่มีตัวหนังสือหรือเส้นบาง การบีบจนข้อความอ่านไม่ออกอาจลดข้อมูลได้แต่ทำให้ภาพหมดหน้าที่อธิบาย
สำหรับหน้าที่มีหลายภาพ ควรระบุว่าภาพใดเป็นภาพแรกจริง ไม่รีบโหลดทุก slide ด้วยความสำคัญเท่ากันเพียงเพราะอยู่ใน component เดียวกัน และต้องมีขนาดหรืออัตราส่วนรองรับตั้งแต่ก่อนภาพมาเพื่อไม่ให้หน้าเปลี่ยนตำแหน่งตามหลัง
กำหนด URL อุปกรณ์จำลอง เครือข่าย และสถานะแคชให้เหมือนกัน แล้วเก็บหลายรอบก่อนเปลี่ยนจุดเดียว เช่น ทดลองแก้การค้นพบรูปก่อนค่อยเปลี่ยนไฟล์ จะได้รู้ว่าสิ่งที่เห็นเกี่ยวกับส่วนใด ไม่รวมการแก้หลายเรื่องแล้วสรุปจากคะแนนรอบเดียว
ในบันทึกควรมีทั้ง LCP element, URL ที่โหลดจริง และช่วงเวลาที่กำลังสนใจ พร้อมผลที่คนอ่านเห็น หากภาพหลักยังไม่มาแต่ skeleton ขึ้นไว ก็ต้องรักษาคำถามเดิมว่าคนอ่านได้เนื้อหาสำคัญเมื่อไร ไม่ย้ายเป้าหมายไปดูเพียงจังหวะที่มีอะไรก็ได้ปรากฏขึ้น
เมื่อมีข้อมูลผู้ใช้จริงค่อยดูว่าปัญหาที่พบใน lab สอดคล้องกับกลุ่มการใช้งานใด รวมถึงแยกข้อมูลของ URL กับทั้งเว็บไซต์ให้ชัด การทดสอบบนเครื่องเราช่วยหาสาเหตุได้ แต่ยังไม่ได้บอกสัดส่วนคนอ่านทั้งหมดที่เจออาการเดียวกัน
เก็บไฟล์ต้นฉบับกับค่าการแปลงภาพไว้ด้วย เมื่อภายหลังเปลี่ยนขนาดกรอบหรือพบว่าตัวหนังสือในภาพไม่คม จะได้สร้างไฟล์ใหม่จากต้นทางเดิมและเทียบคุณภาพได้ โดยไม่ต้องบีบไฟล์ที่ผ่านการบีบมาแล้วซ้ำอีกครั้ง
ภาพปกที่เปิดช้าควรถูกตรวจตั้งแต่เป็น LCP element จริงหรือไม่ ถูกค้นพบตอนไหน โหลดนานเพียงใด และยังรออะไรหลังโหลดจบ เมื่อเห็นช่วงที่เป็นปัญหาแล้วจึงเลือกปรับทางส่งภาพ ลำดับโหลด หรือขนาดไฟล์ พร้อมเทียบผลภายใต้เงื่อนไขเดิม จะได้ทำให้ภาพช่วยพาเข้าเรื่องโดยไม่เพิ่มเวลารอเกินหน้าที่ของมันครับ