ปัญหาการเติมข้อมูลฝั่งไคลเอนต์ทั้งหมด

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

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

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

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

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

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

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

การทำให้โต้ตอบได้เฉพาะส่วน (ผ่าน Suspense) ทำให้ React ทำให้องค์ประกอบต่าง ๆ โต้ตอบได้ตามลำดับความสำคัญ การโต้ตอบของผู้ใช้จะเรียกใช้การทำให้โต้ตอบได้ขององค์ประกอบที่เกี่ยวข้องทันที วิธีนี้ช่วยเพิ่มการตอบสนอง แต่ยังคงทำงานอยู่ภายในโครงสร้าง React เดียวกัน องค์ประกอบทั้งหมดในโครงสร้างจะถูกทำให้โต้ตอบได้ในท้ายที่สุด

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

การศึกษาจากทีมประสิทธิภาพเว็บแสดงให้เห็นว่าเวลาในการแยกวิเคราะห์และเรียกใช้ JavaScript เป็นต้นทุนหลักบนอุปกรณ์มือถือ ชุด JavaScript ขนาด 300kb ใช้เวลา 2-3 วินาทีในการแยกวิเคราะห์บนโทรศัพท์ Android ระดับค่ามัธยฐาน การลด JavaScript ที่ส่งไปยังเบราว์เซอร์ให้ประโยชน์ด้านประสิทธิภาพอย่างมาก เมื่อเทียบกับการปรับปรุงใด ๆ ภายใน React

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

การทำให้หน้าโต้ตอบได้ของ React มีความสัมพันธ์กับเวลาจนพร้อมให้โต้ตอบ (TTI) อย่างไร

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