บทความขยับตอนรูปขึ้น แก้จากพื้นที่ว่างก่อนดีไหม

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

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

CLS หรือ Cumulative Layout Shift ช่วยประเมินความไม่มั่นคงแบบนั้น แต่การแก้ยังต้องตามไปถึงสาเหตุของการขยับ ไม่ใช่เพียงซ่อน element ที่ถูกชี้ในรายงาน

สิ่งที่ขยับอาจอยู่คนละจุดกับต้นเหตุ

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

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

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

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

บอกอัตราส่วนของรูปตั้งแต่ยังไม่เห็นไฟล์

ถ้ารู้ขนาดภาพ ควรส่ง width กับ height ไปกับ <img> เพื่อให้เบราว์เซอร์มีอัตราส่วนสำหรับจัดพื้นที่ก่อนรูปโหลด และยังใช้ CSS ให้รูปย่อขยายตามพื้นที่บทความได้ตามปกติ

ตัวอย่างสมมติของภาพอัตราส่วน 16:9:

<img
  src="/images/system-diagram.webp"
  width="1200"
  height="675"
  alt="แผนผังส่วนประกอบของระบบ"
  loading="lazy"
  style="max-width:100%;height:auto"
>

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

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

ตรวจทางเดินตั้งแต่ไฟล์ต้นฉบับถึง HTML

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

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

หลังแก้ให้ดู HTML ที่คนอ่านได้รับจริงด้วย บางครั้ง preview ในตัวแก้ไขมีกรอบรูป แต่หน้าเผยแพร่ใช้ renderer อีกตัว หากตรวจเพียง preview ก็อาจไม่พบว่าค่าขนาดหายไปในขั้นแปลงหรือถูกกรองออกก่อนแสดง

ฟอนต์กับส่วนที่โหลดทีหลังก็เปลี่ยนพื้นที่ได้

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

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

ส่วนอย่างกล่องแนะนำเนื้อหา แบนเนอร์ และ embed ก็ควรมีพื้นที่ที่สอดคล้องกับสิ่งที่จะมา หากยังไม่รู้ขนาดแน่นอน ควรคิดตำแหน่งแทรกและพฤติกรรมเปลี่ยนขนาด ไม่เพิ่มของไว้เหนือสิ่งที่คนกำลังอ่านโดยไม่มีจังหวะรองรับ

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

ตรวจหลังเริ่มอ่านด้วย ไม่จบที่โหลดหน้าแรก

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

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

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

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

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

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