การเติมข้อมูลแบบค่อยเป็นค่อยไปด้วยการเติมข้อมูลแบบเลือกเฉพาะ

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

ก่อน React 18 การทำไฮเดรชันเป็นแบบ "ทั้งหมดหรือไม่ก็ไม่มีเลย" — React ต้องดาวน์โหลด JavaScript ทั้งหมดและทำไฮเดรชันให้แผนผังทั้งหมดเสร็จก่อนที่ส่วนใด ๆ ของหน้าจะโต้ตอบได้ React 18 แก้ข้อจำกัดนี้ โดยบางส่วนของแผนผังจะทำไฮเดรชันแยกกันเมื่อโค้ดและข้อมูลของส่วนนั้นพร้อมใช้งาน

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

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

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

การทำไฮเดรชันแบบเลือกลด Total Blocking Time (TBT) ซึ่งเป็นตัวชี้วัดสำคัญด้านประสิทธิภาพของการทำไฮเดรชัน ในแท็บประสิทธิภาพของ Chrome DevTools งานที่ใช้เวลานาน (งานที่ใช้เวลามากกว่า 50 มิลลิวินาที) จะถูกเน้นด้วยสีแดง ก่อนใช้การทำไฮเดรชันแบบเลือก คุณอาจเห็นงานที่ใช้เวลานานหนึ่งงานซึ่งกินเวลา 300 มิลลิวินาทีสำหรับการทำไฮเดรชันทั้งหมด หลังใช้ คุณจะเห็นงานขนาดเล็กหลายงานที่กระจายออกไปตามเวลา

รูปแบบที่ขัดขวางการทำไฮเดรชันแบบเลือกคือการนำเข้าคอมโพเนนต์ทั้งหมดไว้ที่ด้านบนสุดของแอป: import Footer from './Footer' วิธีนี้บังคับให้เบราว์เซอร์ดาวน์โหลด แยกวิเคราะห์ และเรียกใช้โค้ดของ Footer ก่อนที่การทำไฮเดรชันใด ๆ จะเริ่มขึ้น ให้แทนที่การนำเข้าคอมโพเนนต์ระดับบนสุดที่อยู่นอกพื้นที่มองเห็นด้วย React.lazy และการนำเข้าแบบไดนามิก

ใช้ const Footer = React.lazy(() => import('./Footer')) สำหรับคอมโพเนนต์ที่ปรากฏอยู่นอกพื้นที่แสดงผลเริ่มต้น ครอบคอมโพเนนต์เหล่านั้นด้วย Suspense และส่วนสำรองแบบเรียบง่าย เบราว์เซอร์จะลดลำดับความสำคัญในการดึงชุดโค้ดของ Footer จนกว่าการทำไฮเดรชันของเนื้อหาที่อยู่ในพื้นที่มองเห็นจะเสร็จ จึงช่วยปรับปรุง TBT ได้โดยอัตโนมัติ

การส่งข้อมูลและการทำไฮเดรชันแบบเลือกช่วยเสริมกัน: การส่งข้อมูลจะส่งชิ้นส่วน HTML เพื่อปรับปรุง FCP และ LCP ขณะที่การทำไฮเดรชันแบบเลือกจะประมวลผลชิ้นส่วน JavaScript เพื่อปรับปรุง TTI และ TBT ทั้งสองอย่างร่วมกันแก้ปัญหาทั้งด้าน "การแสดงเนื้อหาให้เร็ว" และ "การทำให้โต้ตอบได้เร็ว" ของประสิทธิภาพ

React Server Components ยกระดับการทำไฮเดรชันแบบเลือกให้ก้าวไปอีกขั้น โดยคอมโพเนนต์ฝั่งเซิร์ฟเวอร์จะไม่สร้าง JS สำหรับไคลเอนต์เลย มีเพียงคอมโพเนนต์ฝั่งไคลเอนต์ (ที่ระบุด้วย "use client") เท่านั้นที่ต้องทำไฮเดรชัน วิธีนี้ลดปริมาณ JavaScript ทั้งหมดที่ต้องทำไฮเดรชัน ทำให้การทำไฮเดรชันแบบเลือกมีประสิทธิภาพยิ่งขึ้น

รูปแบบที่ใช้ได้จริงคือใช้ renderToPipeableStream สำหรับส่ง HTML แบบต่อเนื่อง ครอบหน้าไว้ในการเรียก hydrateRoot ที่ระดับราก (แทน createRoot) เพื่อเปิดใช้โหมดไฮเดรชัน ใช้ React.lazy สำหรับทุกส่วนที่อยู่นอกพื้นที่มองเห็น และครอบแต่ละส่วนด้วยขอบเขต Suspense จากนั้น React จะจัดการส่วนที่เหลือให้โดยอัตโนมัติ

การโต้ตอบของผู้ใช้ส่งผลต่อลำดับความสำคัญของการทำไฮเดรชันแบบเลือกใน React 18 อย่างไร

การทำไฮเดรชันแบบเลือกทำให้ React ทำไฮเดรชันแผนผังคอมโพเนนต์ย่อยอย่างต่อเนื่องเมื่อ JavaScript ของส่วนนั้นมาถึง แทนที่จะรอชุดโค้ดทั้งหมด การโต้ตอบของผู้ใช้จะให้ความสำคัญกับการทำไฮเดรชันของแผนผังย่อยที่ผู้ใช้เลือก การใช้ React.lazy และการนำเข้าแบบไดนามิกสำหรับเนื้อหาที่อยู่นอกพื้นที่มองเห็นร่วมกับขอบเขต Suspense ทำให้เกิดรูปแบบการทำงานต่อเนื่องนี้ การทำไฮเดรชันแบบเลือกและ SSR แบบส่งข้อมูลต่อเนื่องเป็นเทคนิคที่ช่วยเสริมกัน ซึ่งร่วมกันแก้ปัญหาทั้งด้านการส่งเนื้อหาและประสิทธิภาพการโต้ตอบ