เว็บช้าแบบไหน ดูจาก LCP INP หรือ CLS

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

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

Core Web Vitals ใช้ LCP, INP และ CLS มองประสบการณ์ต่างด้านกันครับ บทนี้จะชวนจับคู่ตัวชี้วัดกับสิ่งที่คนใช้เจอ ก่อนกลับไปเลือกเครื่องมือและการทดสอบที่ตอบเรื่องนั้นได้จริง

รอเนื้อหาหลักขึ้น ลองเริ่มจาก LCP

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

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

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

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

กดแล้วรอหน้าตอบ ลองดู INP

Interaction to Next Paint หรือ INP เกี่ยวกับการตอบสนองต่อปฏิสัมพันธ์ที่เข้าเกณฑ์ตลอดการอยู่ในหน้า ตั้งแต่ช่วงรอให้เหตุการณ์ถูกจัดการ งานของตัวจัดการ ไปจนถึงการแสดงผลถัดไป จึงไม่ใช่เพียงเวลาที่ฟังก์ชันหนึ่งใช้ทำงานตามที่เราใส่นาฬิกาจับไว้ในโค้ด

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

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

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

กำลังอ่านหรือกำลังกดแล้วหน้าขยับ ดู CLS

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

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

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

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

สามตัวนี้ช่วยเลือกทางตรวจ ไม่ได้แทนกัน

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

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

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

อ่านข้อมูลรวมให้ตรงกลุ่มผู้ใช้

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

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

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

เริ่มแก้จากอาการที่ทำซ้ำได้

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

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

สรุป

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