ติดตามสาเหตุของความล้มเหลวของ INP ย้อนกลับไปยังบรรทัดโค้ดในเจ็ดสาขา

คะแนน INP สีแดงไม่ได้หมายความว่าเป็นปัญหาด้านประสิทธิภาพ จนกว่าคุณจะรู้ว่าขั้นตอนใดในสามขั้นตอนนั้นใช้เวลามากที่สุด ทีมส่วนใหญ่ข้ามขั้นตอนนี้ไป ซื้อปลั๊กอินแคช หรือเลื่อนการทำงานของสคริปต์ และปล่อยให้คะแนนเปอร์เซ็นไทล์ที่ 75 ไม่ยอมขยับ คู่มือนี้คือแผนผังการตัดสินใจที่เราใช้แทน: เจ็ดสาขาที่จะนำคุณจากตัวเลขรายงาน UX ของ Chrome ที่ล้มเหลวไปยังตัวจัดการ สคริปต์ หรือแท็กของบุคคลที่สามที่รับผิดชอบ โดยมีเกณฑ์ที่กำหนดไว้ในแต่ละทางแยก คู่มือนี้เขียนขึ้นสำหรับหัวหน้าทีมพัฒนาส่วนหน้าและทีมเติบโตที่รับผิดชอบทั้งตัวเลขการแปลงและคะแนน Lighthouse

ช่องว่างนั้นมีอยู่จริง ในรายงาน Web Almanac ปี 2025 ระบุว่า 77% ของแหล่งกำเนิดสัญญาณมือถือมีค่า INP ที่ดี เมื่อเทียบกับ 97% บนเดสก์ท็อป และเพียงเท่านั้น 48% ของแหล่งที่มาของอุปกรณ์เคลื่อนที่ผ่านเกณฑ์ Core Web Vitals ทั้งสามข้อ (ไฟล์เก็บถาวร HTTPสิ่งที่ยังคงมีปัญหาบนอุปกรณ์มือถือส่วนใหญ่คือความล่าช้าในการโต้ตอบ ซึ่งส่วนใหญ่สามารถวินิจฉัยหาสาเหตุได้

สิ่งที่ INP วัด และสิ่งที่ INP เพิกเฉยอย่างเงียบๆ

Interaction to Next Paint รายงานว่ามีเวลาแฝงในการโต้ตอบหนึ่งครั้งต่อการเข้าชมหน้าเว็บหนึ่งครั้ง เปอร์เซ็นไทล์ที่ 75 ข้ามต้นกำเนิดของคุณ สิ่งที่ดีคือ 200 ms หรือน้อยกว่าจำเป็นต้องปรับปรุง คือ มากกว่า 200 มิลลิวินาที และไม่เกิน 500 มิลลิวินาที แย่ คือ มากกว่า 500 มิลลิวินาที (เว็บ.dev). มีสามสิ่งในคำจำกัดความนั้นที่ส่งผลต่อวิธีการแก้ไขข้อผิดพลาดของคุณ:

• นับเฉพาะการคลิก การแตะ และการกดปุ่มเท่านั้น การวางเมาส์เหนือวัตถุ การซูม และ การเลื่อนหน้าจอไม่ได้ถูกวัดผลดังนั้น การเลื่อนหน้าจอที่ไม่ราบรื่นอาจทำให้หน้าเว็บดูไม่สมบูรณ์ ในขณะที่ INP ยังคงเป็นสีเขียว
• ในหน้าเว็บที่มีการโต้ตอบจำนวนมาก INP ละเลยปฏิสัมพันธ์สูงสุดหนึ่งรายการทุกๆ 50 รายการดังนั้น ปฏิสัมพันธ์ที่ร้ายแรงและเกิดขึ้นไม่บ่อยนัก อาจซ่อนตัวอยู่บนหน้าเพจที่มีการมีส่วนร่วมสูง และปรากฏขึ้นบนหน้าเพจที่มีการมีส่วนร่วมต่ำ
• ทุกปฏิสัมพันธ์จะแตกออกเป็น ความล่าช้าในการป้อนข้อมูล (ก่อนที่ผู้ดูแลของคุณจะเริ่มทำงาน) ระยะเวลาการประมวลผล (ผู้ควบคุมของคุณกำลังทำงาน) และ ความล่าช้าในการนำเสนอ (หลังจากผู้ดูแลของคุณ ก่อนที่เฟรมจะถูกทาสี) ปัญหาทั้งสามนี้แทบไม่มีอะไรเหมือนกันเลยในแง่ของปัญหาทางวิศวกรรม (เว็บ.dev).

ประเด็นสุดท้ายคือหัวใจสำคัญของวิธีการทั้งหมด คุณไม่ได้กำลังดีบั๊ก "INP" แต่คุณกำลังดีบั๊กหนึ่งในสามขั้นตอน และแต่ละขั้นตอนมีวิธีแก้ไขที่แตกต่างกัน

สาขา 0: ตรวจสอบว่าหมายเลขนั้นถูกต้องก่อนป้อนรหัส

เปิด PageSpeed ​​Insights แล้วอ่านส่วนข้อมูลฟิลด์ ไม่ใช่คะแนนจากเครื่องมือทดสอบ เครื่องมือทดสอบไม่สามารถวัด INP ได้ เพราะ INP ต้องการผู้ใช้จริงกดปุ่มบางอย่าง หากต้นทางไม่มีข้อมูลฟิลด์ แสดงว่าคุณมีปัญหาเรื่องปริมาณการเข้าชม ไม่ใช่ปัญหาเรื่องประสิทธิภาพ และไม่มีอะไรด้านล่างที่เกี่ยวข้องในตอนนี้ จากนั้นแยกข้อมูลมือถือและเดสก์ท็อปออกจากกัน — ทั่วโลกมีความแตกต่างกัน 20 เปอร์เซ็นต์ในปี 2025 หากมือถือเป็นสีแดงและเดสก์ท็อปเป็นสีเขียว ให้หยุดการทดสอบบนแล็ปท็อปของคุณ

สาขาที่ 1: การทำงานที่ช้าลงเกิดขึ้นระหว่างการโหลดหรือหลังจากนั้น?

ติดตั้งอุปกรณ์ภาคสนามด้วย web-vitals การสร้างการระบุแหล่งที่มา เพียงสี่บรรทัดก็จะได้ข้อมูลแล้ว:

import {onINP} from 'web-vitals/attribution';
onINP(({value, rating, attribution}) => {
  navigator.sendBeacon('/rum', JSON.stringify({value, rating, attribution}));
});

อ่าน attribution.loadState ประการแรก หากปฏิสัมพันธ์ที่ไม่ดีส่วนใหญ่ก่อให้เกิดสถานะภาระ โหลด or โดม-อินเตอร์แอคทีฟผู้ใช้กำลังแตะหน้าจอในขณะที่สคริปต์ของคุณกำลังประเมินอยู่: นี่คือปัญหาการส่งมอบ ซึ่งแก้ไขได้แล้วที่ชุดไฟล์และตัวจัดการแท็ก ไม่ใช่ที่ตัวจัดการ หากการโต้ตอบที่ไม่ดีเกิดขึ้นกระจายไปทั่วหน้าเว็บที่โหลดเสร็จสมบูรณ์แล้ว ให้ไปที่สาขา 2

สาขาที่ 2: ส่วนย่อยใดเป็นเจ้าของเวลา?

เข้าสู่ระบบ inputDelay, processingDuration และ presentationDelay สำหรับทุกตัวอย่าง กฎการทำงานของเราคือ ส่วนย่อยจะเป็นเจ้าของปฏิสัมพันธ์เมื่อส่วนย่อยนั้นคำนึงถึง มากกว่า 50% ของ INP ทั้งหมดหากไม่มีกรณีใดที่เคลียร์ได้ถึง 50% ให้พิจารณาว่าเป็นกรณีความล่าช้าในการป้อนข้อมูลก่อน — โดยปกติแล้วความแออัดของเธรดหลักแบบกระจายจะเป็นสาเหตุที่ทำให้สองกรณีที่เหลือแย่ลง

สาขาที่ 3: ตั้งชื่อสคริปต์

โครงสร้างการระบุแหล่งที่มาจะแสดงรายการเฟรมแอนิเมชั่นแบบยาวควบคู่ไปกับตัวอย่าง INP แต่ละรายการ attribution.longestScript จะแสดงตัวเรียกใช้งาน ฟังก์ชัน และไฟล์ต้นฉบับสำหรับสคริปต์ที่แย่ที่สุดในปฏิสัมพันธ์นั้น totalScriptDuration รวบรวมทุกอย่างที่ใช้เวลามากกว่า 5 มิลลิวินาที นี่คือจุดที่คำพูดคลุมเครือว่า "React ช้า" กลายเป็นเส้นทางไฟล์ ตรวจสอบประเภทตัวเรียกใช้งาน: classic-script or module-script ชี้ให้เห็นถึงการประเมินเวลาในการโหลด ในขณะที่ user-callback or event-listener ชี้ไปยังบางสิ่งที่ทำงานหลังจากโหลดเสร็จ — ตัวสังเกตการณ์ ตัวจับเวลา ตัวรับฟังการวิเคราะห์ (เว็บ.dev).

สาขาที่ 4: เป็นของคุณหรือของบุคคลที่สาม?

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

สาขาที่ 5: จำลองปัญหาในห้องปฏิบัติการ จากนั้นแก้ไขโครงสร้าง

นำตัวเลือกจาก attribution.interactionTargetเปิด Chrome DevTools โดยตั้งค่าการจำกัดการใช้งาน CPU ให้ตรงกับอุปกรณ์ที่คุณใช้ และบันทึกการโต้ตอบ มองหากิจกรรมที่เกิดขึ้น ms 50เกณฑ์งานระยะยาว (เว็บ.dev) และแบ่งมันโดยการให้ผลผลิต

เรือ scheduler.yield() โดยมีกลไกสำรอง Chrome และ Edge รองรับตั้งแต่เวอร์ชัน 129 และ Firefox รองรับตั้งแต่เวอร์ชัน 142 แต่ Safari ไม่รองรับฟังก์ชันนี้ ทั้งบนเดสก์ท็อปและ iOSและ MDN ระบุว่ามีให้บริการในจำนวนจำกัด แทนที่จะเป็นแบบพื้นฐาน (MDN, ฉันสามารถใช้สำหรับกลุ่มผู้ชมชาวตุรกีหรือกลุ่มประเทศอ่าวที่มีผู้ใช้ iOS จำนวนมาก setTimeout การใช้แผนสำรองไม่ใช่ทางเลือก

สาขาที่ 6: วัดขนาดตลาดที่คุณขายสินค้าให้จริง ๆ

ค่าเฉลี่ย CrUX ทั่วโลกซ่อนตลาดที่จ่ายเงินให้คุณไว้ ชุดข้อมูล CrUX BigQuery เผยแพร่ตารางข้อมูลรายประเทศ — chrome-ux-report.country_tr.YYYYMM สำหรับประเทศตุรกี รูปแบบเดียวกันนี้ใช้กับรหัสประเทศสองตัวอักษรใดๆ ก็ได้ โดยจะมีการอัปเดตทุกเดือน พร้อมด้วยขนาดรูปทรงของอุปกรณ์และประเภทการเชื่อมต่อที่มีประสิทธิภาพ (Chrome สำหรับนักพัฒนาAPI สาธารณะของ CrUX ไม่เปิดเผยข้อมูลประเทศ ดังนั้นส่วนนี้จึงใช้งานได้เฉพาะบน BigQuery เท่านั้น

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

สาขาที่ 7: พิสูจน์ว่ามันเคลื่อนย้ายบางสิ่งบางอย่าง

ให้ถือว่าการแก้ไขนี้เป็นการทดลอง ไม่ใช่การนำไปใช้งานจริง Trendyolตลาดออนไลน์แห่งหนึ่งในตุรกี พบว่าข้อผิดพลาด INP บนมือถือที่ใช้เวลา 963 มิลลิวินาที เกิดจากงานที่ใช้เวลา 700-900 มิลลิวินาที ซึ่งเกิดจากฟังก์ชันเรียกกลับ IntersectionObserver ภายในคอมโพเนนต์ React และเลื่อนการอัปเดตสถานะออกไป scheduler.yield()และลดค่า INP ในเปอร์เซ็นไทล์ที่ 75 จากประมาณ 1,400 มิลลิวินาที เหลือประมาณ 650 มิลลิวินาที ภายในระยะเวลาหกเดือน การทดสอบ A/B แสดงให้เห็นว่า เพิ่มอัตราการคลิกเข้าชมหน้าสินค้าไปยังรายละเอียดสินค้า 1% ต่อครั้ง (เว็บ.dev). รถเมล์แดง ลดเวลาในการโหลดปฏิสัมพันธ์แบบ lazy-load จาก 870–900 มิลลิวินาที เหลือ 350–370 มิลลิวินาที ปรับปรุงปฏิสัมพันธ์การป้อนข้อความได้ 72% และรายงานผลลัพธ์ ยอดขายโดยรวมเพิ่มขึ้น 7% (เว็บ.dev).

โปรดสังเกตตัวเลขที่ถูกต้อง: 1% ไม่ใช่ 40% ซึ่งนำเรามาสู่ตัวเลขที่ควรแก้ไข

ตัวเลข 8.4% นั้นควรมีข้อควรระวังอยู่บ้าง

ตัวเลขที่ถูกอ้างถึงมากที่สุดในด้านนี้คือ การเพิ่มความเร็วบนมือถือ 0.1 วินาที จะช่วยเพิ่มอัตราการเปลี่ยนลูกค้าในธุรกิจค้าปลีกได้ 8.4% และในธุรกิจท่องเที่ยวได้ 10.1% ตัวเลขนี้มาจากงานวิจัยจริงที่จัดทำโดย 55 และ Deloitte โดยได้รับมอบหมายจาก Google ทำการศึกษาใน 37 แบรนด์ และมีจำนวนการเข้าชมมากกว่า 30 ล้านครั้ง (เว็บ.devแต่เป็นการวัดตัวชี้วัดการโหลด เช่น เวลาในการโหลดหน้าเว็บและความหน่วงของเซิร์ฟเวอร์ ไม่ใช่ INPข้อมูลครอบคลุม 30 วัน ณ สิ้นปี 2019 และไม่มีกลุ่มควบคุม ดังนั้นจึงเป็นเพียงความสัมพันธ์ที่สังเกตได้ ไม่ใช่ผลกระทบเชิงสาเหตุ ควรใช้ข้อมูลนี้เพื่อเปิดประเด็นการพูดคุยเรื่องงบประมาณ ไม่ใช่เพื่อคาดการณ์ผลตอบแทนจากการแก้ไขปัญหาความล่าช้าในการสื่อสาร

[ต้องการข้อมูลภายใน: ผลการทดสอบ Switas ก่อน/หลัง p75 INP และค่าเดลต้าของการเปลี่ยนแปลงจากโครงการของลูกค้า เพื่อใช้แทนกรณีศึกษาที่เผยแพร่ต่อสาธารณะด้วยหลักฐานจากแหล่งข้อมูลโดยตรง]

จุดที่แผนผังการตัดสินใจนี้ล้มเหลว

• ต้นทางที่มีปริมาณการจราจรน้อย ด้วยข้อมูลภาคสนามที่น้อยนิด ค่าเปอร์เซ็นไทล์ที่ 75 ถือเป็นสัญญาณรบกวน หากมีการโต้ตอบกับเทมเพลตประมาณ 1,000 ครั้งต่อสัปดาห์ ควรทำการวิเคราะห์ในห้องปฏิบัติการและยอมรับว่าคุณไม่สามารถตรวจสอบความสำเร็จใน CrUX ได้
• ผู้ใช้งาน Safari และ Firefox จะไม่ปรากฏตัว CrUX ใช้งานได้เฉพาะบน Chrome เท่านั้น หากรายได้ส่วนใหญ่ของคุณมาจาก iOS Safari ข้อมูล INP ของคุณอาจแสดงถึงกลุ่มประชากรที่คุณยังไม่ได้วัดผลอย่างครบถ้วน
• ปัญหาการเลื่อนหน้าจอที่ไม่ราบรื่นนั้นอยู่นอกขอบเขตการพิจารณา INP ไม่สนใจการเลื่อนหน้าจอ ดังนั้นโครงสร้างข้อมูลนี้จะไม่พบปัญหาในรายการที่มีการเลื่อนแบบไม่สิ้นสุด ซึ่งให้ความรู้สึกแย่มากแต่กลับผ่านการทดสอบได้
• มันค้นหาความล่าช้า ไม่ใช่ภาระด้านการออกแบบ การโต้ตอบนาน 180 มิลลิวินาทีบนแผงตัวกรองที่ซับซ้อนนั้นเป็นปัญหาด้าน UX ที่โครงสร้างนี้มองไม่เห็น

คำถามที่พบบ่อย

INP กับ First Input Delay เหมือนกันหรือไม่?
ไม่ FID วัดเฉพาะความล่าช้าก่อนที่ตัวจัดการการโต้ตอบครั้งแรกจะทำงานเท่านั้น INP ครอบคลุมความหน่วงทั้งหมดของการโต้ตอบที่เป็นตัวแทนตลอดการเยี่ยมชม รวมถึงการทำงานของตัวจัดการและการแสดงผลที่ตามมา

ทำไมคะแนน Lighthouse ของฉันถึงดูปกติดี ในขณะที่ INP เป็นสีแดง?
Lighthouse เป็นเครื่องมือในห้องปฏิบัติการและไม่สามารถวัด INP ได้ เนื่องจากไม่มีผู้ใช้จริงกดปุ่มใดๆ ตัวชี้วัดอื่นๆ เช่น Total Blocking Time มีความสัมพันธ์กันอย่างหลวมๆ ควรอ่านรายละเอียดในส่วนของ PageSpeed ​​Insights แทน

ต้องใช้เวลานานแค่ไหนกว่าจะมีการแก้ไขใน CrUX?
รายงานของ CrUX แสดงข้อมูลย้อนหลัง 28 วัน และตาราง BigQuery จะเผยแพร่ข้อมูลรายเดือน คาดว่าจะได้รับสัญญาณบางส่วนหลังจากประมาณสี่สัปดาห์ และข้อมูลที่ครบถ้วนหลังจากมีการเผยแพร่ข้อมูลรายเดือนสองครั้ง

ฉันสามารถแก้ไขไฟล์ INP โดยไม่ต้องแก้ไขเฟรมเวิร์กได้หรือไม่?
โดยส่วนใหญ่ก็ใช่ วิธีแก้ปัญหาของ Trendyol คือการใช้ yield ภายใน callback หนึ่งตัวใน React 16.9 โดยไม่ต้องอัปเกรด การเลื่อนการทำงานของแท็กจากภายนอกก็ไม่ขึ้นอยู่กับเฟรมเวิร์กเช่นกัน

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

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

ฉันควรปรับแต่ง INP เพื่อ SEO หรือเพื่อการแปลงผู้เข้าชมเป็นลูกค้าดี?
ตัดสินใจเพื่อการเปลี่ยนผู้เข้าชมเป็นลูกค้า ตัวชี้วัดสำคัญของเว็บไซต์ (Core Web Vitals) เป็นสัญญาณบ่งชี้อันดับ แต่กรณีศึกษาทางธุรกิจที่บันทึกไว้ — 1% ที่ Trendyol, 7% ที่ redBus — เป็นผลลัพธ์ด้านคุณภาพการโต้ตอบที่คุ้มค่ากับความพยายามอยู่แล้ว

เรียกใช้คำสั่งนี้บนหน้าประกาศขายของคุณเอง

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

แหล่งที่มา

• Interaction to Next Paint (INP) — web.dev
• ปรับปรุงการโต้ตอบให้เหมาะสมกับการวาดภาพครั้งต่อไป — web.dev
• ค้นหาปฏิสัมพันธ์ที่ช้าในภาคสนาม — web.dev
• เพิ่มประสิทธิภาพงานที่ใช้เวลานาน — web.dev
• ประสิทธิภาพ — Web Almanac 2025, HTTP Archive
• Trendyol ลด INP ลง 50% ได้อย่างไร — web.dev
• redBus ช่วยปรับปรุง INP และเพิ่มยอดขายได้ 7% อย่างไร — web.dev
• มิลลิวินาทีสร้างผลลัพธ์ได้มหาศาล — web.dev / 55 / Deloitte
• CrUX บน BigQuery — Chrome สำหรับนักพัฒนา
• ตัวกำหนดเวลา: yield() — MDN
• Scheduler API: อัตราผลตอบแทน — caniuse
• ไลบรารี JavaScript web-vitals — GoogleChrome/web-vitals