การวัดผลกระทบของการสตรีม: FCP, TTI และ LCP

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

เมื่อใช้ SSR แบบรอให้การแสดงผลทั้งหมดเสร็จสิ้นด้วย renderToString เบราว์เซอร์จะไม่ได้รับ HTML จนกว่าการแสดงผลทั้งหมดจะเสร็จสมบูรณ์ แต่เมื่อใช้การส่งข้อมูล เบราว์เซอร์จะได้รับโครงหน้าภายในเวลาไม่กี่มิลลิวินาทีหลังคำขอ — โครงร่างและเนื้อหาคงที่จะปรากฏเกือบจะทันที ทำให้ FCP ลดลงอย่างมาก

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

การปรับปรุงที่สำคัญคือการออกแบบหน้าให้กักองค์ประกอบ LCP — ส่วนเด่นหลัก หัวข้อหลัก และรูปภาพแนะนำ — ไว้นอกขอบเขต Suspense หากองค์ประกอบ LCP อยู่ภายในขอบเขต Suspense ที่กำลังรอข้อมูล การส่งข้อมูลจะไม่ช่วยปรับปรุง LCP จนกว่าข้อมูลนั้นจะแก้ไขเสร็จ

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

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

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

การวัดประสิทธิภาพที่มีความหมายควรเปรียบเทียบหน้าเดียวกันที่เรนเดอร์ด้วยสองวิธี ได้แก่ เปิดใช้การสตรีมของ Next.js RSC เทียบกับ SSR แบบซิงโครนัสตามแบบดั้งเดิม ใช้ WebPageTest กับเงื่อนไขเครือข่ายที่กำหนดตายตัว (เช่น Fast 3G และลดความเร็ว CPU ลง 4 เท่า) แล้วเปรียบเทียบตัวชี้วัด FCP, LCP และ TTI จากการทดสอบ 3 รอบเพื่อให้ได้ความเชื่อมั่นทางสถิติ

แท็บเครือข่ายของ Chrome DevTools มีเมนูแบบเลื่อนลง "Throttling" พร้อมค่าที่ตั้งไว้ล่วงหน้า เช่น Fast 3G และ Slow 4G โดย Fast 3G (1.6 Mbps, RTT 150 มิลลิวินาที) จะขยายความแตกต่างระหว่างหน้าที่ใช้การสตรีมกับหน้าที่ไม่ใช้การสตรีมให้เห็นเด่นชัดขึ้น เพราะทำให้เวลาในการดาวน์โหลดเอกสาร HTML ทั้งหมดนานขึ้น จึงมองเห็นประโยชน์จากการสตรีมทีละส่วนได้ชัดเจน

Interaction to Next Paint (INP) วัดเวลาตั้งแต่ผู้ใช้โต้ตอบใด ๆ จนถึงการวาดหน้าจอครั้งถัดไป โดย INP เข้ามาแทนที่ FID ในฐานะตัวชี้วัดหลักด้านประสบการณ์ผู้ใช้ในปี 2024 การสตรีมช่วยลด INP ด้วยการให้ความสำคัญกับการทำให้คอมโพเนนต์แบบโต้ตอบที่ผู้ใช้น่าจะใช้งานก่อนสามารถโต้ตอบได้ก่อน จึงลดเวลาที่การทำงานถูกบล็อกก่อนคอมโพเนนต์เหล่านั้นจะตอบสนองได้

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

การสตรีมของ React ช่วยปรับปรุงตัวชี้วัดประสิทธิภาพใดโดยตรงที่สุดสำหรับเนื้อหาที่อยู่เหนือส่วนที่ต้องเลื่อนหน้าจอ?

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