ขอแนะนำ scheduler.yield(): API ใหม่ล่าสุดของ Chrome สำหรับการเพิ่มประสิทธิภาพ INP

ไม่ต้องสงสัยเลยว่า Google ให้ความสำคัญกับการตอบสนองในปี 2023

จนถึงตอนนี้ พวกเขา:

• ย้ายการโต้ตอบไปยัง Next Paint จากการทดลองไปเป็นรอดำเนินการ
• ประกาศว่า INP จะแทนที่ First Input Delay เป็นเมตริก Core Web Vital ใหม่สำหรับการตอบสนองในเดือนมีนาคม 2024
• เริ่มแจ้งปัญหา INP ใน Search Console และส่งอีเมลไปยังเว็บไซต์ที่ขาดเกณฑ์สำหรับการตอบสนองที่ดี

ขณะนี้ทีมงาน Chrome ประกาศว่าพวกเขากำลังทดลองใช้ Origin สำหรับ API ตัวกำหนดเวลาใหม่ – scheduler.yield()

scheduler.yield() คาดว่าจะช่วยให้นักพัฒนาปรับปรุงการตอบสนองของไซต์ของตนได้ โดยมอบวิธีที่ง่ายและดีกว่าในการควบคุมกลับไปยังเธรดหลัก

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

สรุปสั้นๆ เกี่ยวกับงานที่ยาวนานและหัวข้อหลัก

หากคุณทราบดีว่างานที่ต้องใช้เวลานานและหัวข้อหลักคืออะไร คุณสามารถข้ามส่วนนี้ได้ หากไม่ เราขอแนะนำให้คุณอ่านสรุปสั้นๆ นี้ เนื่องจากเป็นพื้นฐานในการทำความเข้าใจ scheduler.yield() และวิธีการนำไปใช้

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

หัวข้อหลักคือส่วนที่เบราว์เซอร์ทำงานส่วนใหญ่

ขออภัย เธรดหลักสามารถประมวลผลได้ครั้งละหนึ่งงานเท่านั้นและหากงานใช้เวลาดำเนินการมากกว่า 50ms ก็ถือว่าเป็นงานที่ใช้เวลานาน

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

งานที่ใช้เวลานานเป็นสาเหตุหลักของการตอบสนองของเพจที่ไม่ดี เนื่องจากจะทำให้เบราว์เซอร์ตอบสนองต่ออินพุตของผู้ใช้ได้ล่าช้า นอกจากนี้ JavaScript ซึ่งมีโมเดล run-to-completion เป็นตัวการหลักในการบล็อกเธรดหลัก

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

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

คุณสามารถแบ่งงานที่ยาวนานได้โดยการยอมจำนนต่องานอย่างชัดเจน

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

น่าเสียดายที่กลยุทธ์การให้ผลตอบแทนในปัจจุบันยังไม่สมบูรณ์แบบ...

ทำไมต้อง scheduler.yield(): ปัญหาเกี่ยวกับกลยุทธ์การให้ผลตอบแทนในปัจจุบัน

การยอมทำตามหัวข้อหลักไม่ใช่แนวคิดใหม่ นักพัฒนาซอฟต์แวร์ใช้กลยุทธ์การให้ผลตอบแทนที่แตกต่างกันเพื่อแบ่งงานที่ยาวนานมาระยะหนึ่งแล้ว:

1. setTimeout ()

setTimeout() ช่วยให้คุณสามารถกำหนดเวลางานให้ทำงานหลังจากการหน่วงเวลาที่ระบุหรือตามช่วงเวลาที่สม่ำเสมอ วิธีนี้จะเลื่อนการดำเนินการโทรกลับออกไปเป็นงานที่แยกต่างหาก แม้ว่าคุณจะระบุการหมดเวลาเป็น 0 ก็ตาม วิธีการนี้จะมีผลเมื่อคุณมีหลายฟังก์ชันที่ควรรันทีละฟังก์ชัน

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

2. ขอ IdleCallback()

requestIdleCallback() ช่วยให้คุณสามารถกำหนดเวลาให้งานทำงานในช่วงที่ไม่มีการใช้งานที่เบราว์เซอร์อาจมี มีประโยชน์สำหรับการดำเนินงานที่ไม่เร่งด่วนโดยไม่ส่งผลกระทบต่อประสบการณ์ผู้ใช้

ข้อเสียเปรียบ: requestIdleCallback() จัดตารางเวลางานด้วยลำดับความสำคัญต่ำสุดที่เป็นไปได้ ซึ่งหมายความว่าหากเธรดหลักหนาแน่น งานตามกำหนดเวลาอาจไม่สามารถทำงานได้

3. isInputPending()

isInputPending() สามารถดำเนินการได้ตลอดเวลาเพื่อตรวจสอบว่าผู้ใช้พยายามมีส่วนร่วมกับองค์ประกอบบนเพจหรือไม่ หากเป็นเช่นนั้น ฟังก์ชันจะส่งกลับค่าจริง; ถ้าไม่เช่นนั้นก็จะส่งกลับfalse

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

ข้อเสียเปรียบ: isInputPending() อาจไม่คืนค่าจริงทันทีหลังจากที่ผู้ใช้ป้อนข้อมูล เนื่องจากระบบปฏิบัติการต้องใช้เวลาในการบอกเบราว์เซอร์ว่าการโต้ตอบเกิดขึ้น ซึ่งหมายความว่าโค้ดอื่นอาจเริ่มทำงานแล้ว

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

แต่ข้อเสียที่สำคัญที่สุดก็คือ:

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

เหตุใดจึงเป็นปัญหา?

มันเป็นคำตอบสามเท่า:

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

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

แนะนำ scheduler.yield()

ความน่าตื่นเต้นเกี่ยวกับ Chrome ที่กำลังทดลองใช้ Origin สำหรับ scheduler.yield() เป็นเพราะเป็น API ตัวกำหนดเวลาที่จัดการกับข้อเสียทั้งหมดของกลยุทธ์ที่ให้ผลตอบแทนอื่นๆ

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

ดังนั้นสิ่งที่เกินจริงเกี่ยวกับscheduler.yield() คืออะไร ?

สำหรับผู้เริ่มต้น scheduler.yield() เป็นฟังก์ชันผลตอบแทนเฉพาะ ตัวอย่างเช่น setTimeout() ใช้เพื่อแบ่งงานที่ยาวนานและยอมจำนนต่อเธรดหลัก แต่มีผลข้างเคียงของฟังก์ชันมากกว่าตัวเลือกเริ่มต้น

ประการที่สอง scheduler.yield() จะส่งงานที่เหลือไปที่ด้านหน้าของคิว ซึ่งหมายความว่างานที่คุณต้องการดำเนินการต่อทันทีหลังจากที่ยอมจำนนจะไม่ทำให้งานจากแหล่งอื่นเสียไป

พูดง่ายๆ:

scheduler.yield() มอบสิ่งที่ดีที่สุดให้กับคุณทั้งสองอย่าง คุณสามารถยอมปรับปรุงการตอบสนองของไซต์และคะแนน INP ของคุณได้ และรับรองว่างานที่คุณต้องการทำให้เสร็จหลังจากการให้ผลจะไม่ล่าช้า

วิธีลองใช้ Scheduler API ใหม่

ตั้งแต่ Chrome 115 เป็นต้นไป คุณจะทดสอบ scheduler.yield ได้ด้วยตัวเอง

หากต้องการทดลองกับ API ใหม่ เพียงทำตามคำแนะนำของ Google:

1. หากคุณต้องการทดลองใช้ scheduler.yield ในเครื่อง ให้พิมพ์และป้อน chrome://flags ในแถบที่อยู่ของ Chrome และเลือกเปิดใช้งานจากเมนูแบบเลื่อนลงในส่วนคุณลักษณะแพลตฟอร์มเว็บทดลอง ซึ่งจะทำให้ scheduler.yield (และคุณลักษณะทดลองอื่นๆ) พร้อมใช้งานในอินสแตนซ์ Chrome ของคุณเท่านั้น
   
2. หากคุณต้องการเปิดใช้งาน scheduler.yield สำหรับผู้ใช้ Chromium จริงในต้นทางที่เข้าถึงได้แบบสาธารณะ คุณจะต้องลงชื่อสมัครทดลองใช้ต้นทางของ scheduler.yield วิธีนี้ช่วยให้คุณสามารถทดลองใช้คุณลักษณะที่เสนอได้อย่างปลอดภัยในช่วงเวลาที่กำหนด และให้ข้อมูลเชิงลึกอันมีค่าแก่ทีม Chrome เกี่ยวกับวิธีการใช้คุณลักษณะเหล่านั้นในภาคสนาม หากต้องการข้อมูลเพิ่มเติมเกี่ยวกับวิธีการทำงานของ Origin Trial โปรดอ่านคู่มือนี้

เมื่อคุณทดสอบแล้ว คุณยังสามารถให้ข้อเสนอแนะว่าจะปรับปรุงได้อย่างไร

การทดสอบที่ปลอดภัย!

NitroPack สามารถช่วยปลดบล็อกเธรดหลักได้อย่างไร

การแบ่งงานยาวออกเป็นชิ้นเล็กๆ ถือเป็นสิ่งสำคัญในการมอบประสบการณ์ที่รวดเร็วแก่ผู้ใช้

แต่จะดีกว่าไหมหากคุณสามารถเพิ่มประสิทธิภาพ JavaScript จำนวนมากล่วงหน้าได้

นั่นคือสิ่งที่ NitroPack เข้ามา

ด้วย คุณสมบัติประสิทธิภาพเว็บขั้นสูงมากกว่า 35 รายการ NitroPack ช่วยให้ เว็บไซต์กว่า 180,000 แห่งทั่วโลก ได้รับประสบการณ์ผู้ใช้ที่ยอดเยี่ยม Core Web Vitals และอัตรา Conversion

ข้อดีที่สำคัญที่สุดประการหนึ่งของ NitroPack คือวิธีการจัดการการทำงานของ JavaScript

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

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

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

ปรับปรุงการตอบสนองของไซต์ของคุณทันที รับ NitroPack ฟรี →