กดปุ่มแล้วเหมือนค้าง ลองไล่จาก INP

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

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

INP หรือ Interaction to Next Paint ช่วยมองการตอบสนองในมุมนี้ แต่ถ้าจะใช้แก้ปัญหา เราต้องมี interaction ที่เกิดอาการให้ตามต่อด้วย ไม่หยุดที่ค่ารวมเพียงตัวเดียว

เริ่มจากการกระทำที่ทำให้คนรู้สึกค้าง

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

INP พิจารณาความหน่วงของ interaction ที่เข้าเกณฑ์ตลอดการเยี่ยมหน้า และเลือกค่าที่สะท้อน interaction ช้าในรอบนั้นตามวิธีคำนวณ จึงไม่ใช่ค่าเฉลี่ยของทุกการกด และไม่ใช่เวลารอให้ธุรกรรมฝั่งเซิร์ฟเวอร์ทั้งหมดสำเร็จ

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

อย่าสับสนกับ Total Blocking Time ที่อาจเห็นในรายงานโหลดหน้า แม้ใช้ช่วยหางานที่ขวางการตอบสนองได้ แต่ไม่ใช่ INP จาก interaction เดียวกัน การนำค่าหนึ่งไปเปลี่ยนชื่อเป็นอีกค่าจะทำให้หลักฐานไม่ตรงคำถาม

ช่วงก่อน handler เริ่มก็อาจกินเวลาไปมากแล้ว

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

ถ้าดูเฉพาะเวลารันฟังก์ชัน onClick อาจพบว่าโค้ดสั้นมาก แต่คนใช้ยังรออยู่ เพราะความหน่วงเกิดก่อนโค้ดส่วนนี้เริ่ม การเปิด trace แล้วเทียบจุดเริ่ม interaction กับงานที่ทับช่วงเวลานั้นจะช่วยแยกเหตุออกมา

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

ภายใน callback มีงานใดต้องเสร็จก่อนให้เห็นผล

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

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

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

ถ้างานเป็นการคำนวณที่แยกออกจาก DOM ได้ อาจพิจารณา Web Worker ส่วนงานที่ยังอยู่บน main thread ควรดูว่าลดปริมาณ แบ่งทำ หรือไม่ต้องทำซ้ำบางส่วนได้หรือเปล่า ทางเลือกควรมาจากงานใน trace ไม่ใช้ worker เป็นคำตอบเดียวให้ทุกปุ่ม

โค้ดจบแล้ว แต่ภาพถัดไปยังต้องจัดหน้า

หลัง callback ทำงาน เบราว์เซอร์ยังอาจต้องคำนวณ style จัด layout และวาดหน้า หากการกดทำให้เปลี่ยนรายการหรือส่วนประกอบจำนวนมาก เวลาช่วงนี้ก็มีผลต่อจังหวะที่คนเห็น feedback ด้วย

จึงควรตรวจว่าการเปลี่ยนสถานะเล็กๆ ทำให้ส่วนที่ไม่เกี่ยวข้องถูกสร้างใหม่หรือจัดหน้าใหม่มากแค่ไหน รวมถึงงานที่อ่านตำแหน่งแล้วเขียน DOM สลับกัน ซึ่งอาจทำให้ต้องคำนวณ layout ซ้ำในจังหวะเดียวกัน

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

แยก feedback ออกจากเวลางานทั้งหมดโดยยังสื่อความจริง

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

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

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

เก็บหลักฐานให้เทียบ interaction เดิมได้

บันทึกอุปกรณ์ viewport เงื่อนไข CPU และลำดับการกด พร้อม trace ก่อนและหลังแก้ แล้วดูว่าช่วง input delay, processing หรือ presentation ส่วนใดเปลี่ยนจริง ทำหลายรอบภายใต้เงื่อนไขเดิมเพื่อลดการตัดสินจากจังหวะที่เครื่องว่างพอดี

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

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

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