1 กันยายน 2568ไทย

เรียนรู้วิธีตรวจจับและกำจัด React Suspense waterfall คู่มือนี้ครอบคลุมการดึงข้อมูลแบบขนาน, Render-as-You-Fetch และกลยุทธ์ขั้นสูงเพื่อสร้างแอปที่เร็วขึ้นสำหรับผู้ใช้ทั่วโลก

React Suspense Waterfall: เจาะลึกการปรับปรุงประสิทธิภาพการโหลดข้อมูลแบบตามลำดับ

ในการแสวงหาประสบการณ์ผู้ใช้ที่ราบรื่นอย่างไม่หยุดยั้ง นักพัฒนา frontend กำลังต่อสู้กับศัตรูตัวฉกาจอยู่ตลอดเวลานั่นคือ: latency (ความหน่วง) สำหรับผู้ใช้ทั่วโลก ทุกมิลลิวินาทีมีความหมาย แอปพลิเคชันที่โหลดช้าไม่เพียงแต่สร้างความหงุดหงิดให้กับผู้ใช้เท่านั้น แต่ยังส่งผลกระทบโดยตรงต่อการมีส่วนร่วม, conversion และผลกำไรของบริษัท React ซึ่งมีสถาปัตยกรรมแบบคอมโพเนนต์และระบบนิเวศ ได้มอบเครื่องมืออันทรงพลังในการสร้าง UI ที่ซับซ้อน และหนึ่งในฟีเจอร์ที่ปฏิวัติวงการมากที่สุดคือ React Suspense

Suspense นำเสนอวิธีการจัดการกับการทำงานแบบอะซิงโครนัสในเชิงประกาศ (declarative) ซึ่งช่วยให้เราระบุสถานะการโหลดได้โดยตรงภายใน component tree ของเรา มันทำให้โค้ดสำหรับการดึงข้อมูล, การทำ code splitting และงานอะซิงโครนัสอื่นๆ ง่ายขึ้น อย่างไรก็ตาม พลังนี้มาพร้อมกับข้อควรพิจารณาด้านประสิทธิภาพชุดใหม่ ข้อผิดพลาดด้านประสิทธิภาพที่พบบ่อยและมักจะสังเกตได้ยากคือ "Suspense Waterfall" ซึ่งเป็นห่วงโซ่ของการโหลดข้อมูลแบบตามลำดับที่สามารถทำให้เวลาในการโหลดแอปพลิเคชันของคุณช้าลงอย่างมาก

คู่มือฉบับสมบูรณ์นี้ออกแบบมาสำหรับนักพัฒนา React ทั่วโลก เราจะวิเคราะห์ปรากฏการณ์ Suspense waterfall อย่างละเอียด สำรวจวิธีการตรวจจับ และนำเสนอการวิเคราะห์เชิงลึกเกี่ยวกับกลยุทธ์อันทรงพลังเพื่อกำจัดมัน เมื่ออ่านจบ คุณจะพร้อมที่จะเปลี่ยนแอปพลิเคชันของคุณจากลำดับของ request ที่ช้าและต้องพึ่งพากัน ไปสู่เครื่องมือดึงข้อมูลแบบขนานที่ได้รับการปรับปรุงประสิทธิภาพอย่างสูง มอบประสบการณ์ที่เหนือกว่าให้กับผู้ใช้ทุกหนทุกแห่ง

ทำความเข้าใจ React Suspense: ทบทวนอย่างรวดเร็ว

ก่อนที่เราจะเจาะลึกถึงปัญหา เรามาทบทวนแนวคิดหลักของ React Suspense กันสั้นๆ โดยหัวใจหลักของมัน Suspense ช่วยให้คอมโพเนนต์ของคุณ "รอ" บางสิ่งบางอย่างก่อนที่จะสามารถ render ได้ โดยที่คุณไม่ต้องเขียน logic การตรวจสอบเงื่อนไขที่ซับซ้อน (เช่น `if (isLoading) { ... }`)

เมื่อคอมโพเนนต์ที่อยู่ใน Suspense boundary ทำการ suspend (โดยการ throw promise) React จะดักจับมันและแสดง UI ที่เป็น `fallback` ที่ระบุไว้ เมื่อ promise ได้รับการ resolve แล้ว React จะ re-render คอมโพเนนต์นั้นพร้อมกับข้อมูล

ตัวอย่างง่ายๆ กับการดึงข้อมูลอาจมีลักษณะดังนี้:

// api.js - ยูทิลิตี้สำหรับครอบฟังก์ชัน fetch ของเรา
const cache = new Map();
export function fetchData(url) {
if (!cache.has(url)) {
cache.set(url, getData(url));
}
return cache.get(url);
}
async function getData(url) {
const res = await fetch(url);
if (res.ok) {
return res.json();
} else {
throw new Error('Failed to fetch');
}
}

และนี่คือคอมโพเนนต์ที่ใช้ hook ที่เข้ากันได้กับ Suspense:

// useData.js - hook ที่ throw promise
import { fetchData } from './api';
function useData(url) {
const data = fetchData(url);
if (data instanceof Promise) {
throw data; // นี่คือสิ่งที่กระตุ้นให้เกิด Suspense
}
return data;
}

สุดท้ายคือ component tree:

// MyComponent.js
import React, { Suspense } from 'react';
import { useData } from './useData';
function UserProfile() {
const user = useData('/api/user/123');
return <h1>Welcome, {user.name}</h1>;
}
function App() {
return (
<Suspense fallback={<h2>Loading user profile...</h2>}>
<UserProfile />
</Suspense>
);
}

วิธีนี้ทำงานได้อย่างสวยงามสำหรับการพึ่งพาข้อมูลเพียงหนึ่งเดียว ปัญหาจะเกิดขึ้นเมื่อเรามีการพึ่งพาข้อมูลที่ซ้อนกันหลายชั้น

"Waterfall" คืออะไร? เปิดโปงคอขวดด้านประสิทธิภาพ

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

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

React Suspense Waterfall คือการนำรูปแบบที่ไม่มีประสิทธิภาพและเป็นลำดับนี้มาใช้กับการดึงข้อมูลภายใน React component tree โดยทั่วไปจะเกิดขึ้นเมื่อ parent component ดึงข้อมูลแล้ว render child component ซึ่งในทางกลับกัน child component ก็จะดึงข้อมูลของตัวเองโดยใช้ค่าจาก parent

ตัวอย่าง Waterfall แบบคลาสสิก

ลองขยายตัวอย่างก่อนหน้านี้ของเรา เรามี `ProfilePage` ที่ดึงข้อมูลผู้ใช้ เมื่อได้ข้อมูลผู้ใช้แล้ว มันจะ render คอมโพเนนต์ `UserPosts` ซึ่งจะใช้ ID ของผู้ใช้เพื่อดึงโพสต์ของพวกเขา

// ก่อน: โครงสร้าง Waterfall ที่ชัดเจน
function ProfilePage({ userId }) {
// 1. network request แรกเริ่มต้นที่นี่
const user = useUserData(userId); // Component จะ suspend ที่นี่
return (
<div>
<h1>{user.name}</h1>
<p>{user.bio}</p>
<Suspense fallback={<h3>Loading posts...</h3>}>
// Component นี้จะไม่ mount เลยจนกว่า `user` จะพร้อมใช้งาน
<UserPosts userId={user.id} />
</Suspense>
</div>
);
}
function UserPosts({ userId }) {
// 2. network request ที่สองเริ่มต้นที่นี่, ต่อเมื่อ request แรกเสร็จสิ้นแล้วเท่านั้น
const posts = useUserPosts(userId); // Component จะ suspend อีกครั้ง
return (
<ul>
{posts.map(post => (<li key={post.id}>{post.title}</li>))}
</ul>
);
}

ลำดับของเหตุการณ์คือ:

`ProfilePage` render และเรียก `useUserData(userId)`
แอปพลิเคชัน suspend และแสดง fallback UI โดย network request สำหรับข้อมูลผู้ใช้อยู่ในระหว่างการดำเนินการ
request ข้อมูลผู้ใช้เสร็จสมบูรณ์ React ทำการ re-render `ProfilePage`
ตอนนี้ข้อมูล `user` พร้อมใช้งานแล้ว `UserPosts` จึงถูก render เป็นครั้งแรก
`UserPosts` เรียก `useUserPosts(userId)`
แอปพลิเคชัน suspend อีกครั้ง โดยแสดง fallback ด้านในว่า "Loading posts..." และ network request สำหรับโพสต์เริ่มทำงาน
request ข้อมูลโพสต์เสร็จสมบูรณ์ React ทำการ re-render `UserPosts` พร้อมกับข้อมูล

เวลาในการโหลดทั้งหมดคือ `Time(fetch user) + Time(fetch posts)` หากแต่ละ request ใช้เวลา 500ms ผู้ใช้จะต้องรอเป็นเวลาหนึ่งวินาทีเต็ม นี่คือ waterfall แบบคลาสสิก และเป็นปัญหาด้านประสิทธิภาพที่เราต้องแก้ไข

การตรวจจับ Suspense Waterfall ในแอปพลิเคชันของคุณ

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

1. การใช้ Browser Developer Tools

แท็บ Network ใน developer tools ของเบราว์เซอร์คือเพื่อนที่ดีที่สุดของคุณ นี่คือสิ่งที่คุณควรมองหา:

รูปแบบขั้นบันได (Stair-Step Pattern): เมื่อคุณโหลดหน้าที่มี waterfall คุณจะเห็นรูปแบบขั้นบันไดหรือแนวทแยงที่ชัดเจนในไทม์ไลน์ของ network request เวลาเริ่มต้นของ request หนึ่งจะสอดคล้องกับเวลาสิ้นสุดของ request ก่อนหน้าอย่างสมบูรณ์แบบ
การวิเคราะห์เวลา (Timing Analysis): ตรวจสอบคอลัมน์ "Waterfall" ในแท็บ Network คุณจะเห็นรายละเอียดของเวลาในแต่ละ request (waiting, content download) ห่วงโซ่ที่เป็นลำดับจะเห็นได้ชัดเจน หาก "เวลาเริ่มต้น" ของ Request B มากกว่า "เวลาสิ้นสุด" ของ Request A แสดงว่าคุณน่าจะมี waterfall

2. การใช้ React Developer Tools

ส่วนขยาย React Developer Tools เป็นสิ่งที่ขาดไม่ได้สำหรับการดีบักแอปพลิเคชัน React

Profiler: ใช้ Profiler เพื่อบันทึก performance trace ของ lifecycle การ render ของคอมโพเนนต์ของคุณ ในสถานการณ์ waterfall คุณจะเห็น parent component render, resolve ข้อมูลของมัน, แล้วกระตุ้นให้เกิดการ re-render ซึ่งจะทำให้ child component ทำการ mount และ suspend ตามมา ลำดับของการ render และ suspend นี้เป็นตัวบ่งชี้ที่ชัดเจน
แท็บ Components: React DevTools เวอร์ชันใหม่ๆ จะแสดงว่าคอมโพเนนต์ใดกำลัง suspend อยู่ การสังเกตว่า parent component หยุด suspend แล้วตามด้วย child component ที่ suspend ทันที สามารถช่วยคุณระบุแหล่งที่มาของ waterfall ได้

3. การวิเคราะห์โค้ดแบบสถิต (Static Code Analysis)

บางครั้ง คุณสามารถระบุ waterfall ที่อาจเกิดขึ้นได้เพียงแค่อ่านโค้ด มองหารูปแบบเหล่านี้:

การพึ่งพาข้อมูลที่ซ้อนกัน (Nested Data Dependencies): คอมโพเนนต์ที่ดึงข้อมูลและส่งผลลัพธ์ของการดึงนั้นเป็น prop ไปยัง child component ซึ่ง child component ก็ใช้ prop นั้นเพื่อดึงข้อมูลเพิ่มเติม นี่เป็นรูปแบบที่พบบ่อยที่สุด
Hook ที่ทำงานตามลำดับ (Sequential Hooks): คอมโพเนนต์เดียวที่ใช้ข้อมูลจาก hook ดึงข้อมูลตัวหนึ่งเพื่อเรียก hook ตัวที่สอง แม้ว่าจะไม่ใช่ waterfall แบบ parent-child อย่างเคร่งครัด แต่ก็สร้างคอขวดแบบตามลำดับเดียวกันภายในคอมโพเนนต์เดียว

กลยุทธ์ในการปรับปรุงประสิทธิภาพและกำจัด Waterfalls

เมื่อคุณระบุ waterfall ได้แล้ว ก็ถึงเวลาแก้ไข หลักการสำคัญของกลยุทธ์การปรับปรุงประสิทธิภาพทั้งหมดคือการเปลี่ยนจาก การดึงข้อมูลแบบตามลำดับ (sequential fetching) ไปเป็น การดึงข้อมูลแบบขนาน (parallel fetching) เราต้องการเริ่มต้น network request ที่จำเป็นทั้งหมดให้เร็วที่สุดเท่าที่จะเป็นไปได้และพร้อมกันทั้งหมด

กลยุทธ์ที่ 1: การดึงข้อมูลแบบขนานด้วย `Promise.all`

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

แนวคิด: แทนที่จะซ้อนการ fetch ให้เรียกใช้พวกมันใน parent component ร่วมหรือในระดับที่สูงขึ้นใน logic ของแอปพลิเคชันของคุณ ครอบพวกมันด้วย `Promise.all` แล้วส่งข้อมูลลงไปยังคอมโพเนนต์ที่ต้องการ

ลอง refactor ตัวอย่าง `ProfilePage` ของเรา เราสามารถสร้างคอมโพเนนต์ใหม่ `ProfilePageData` ที่ดึงทุกอย่างแบบขนาน

// api.js (แก้ไขเพื่อ expose ฟังก์ชัน fetch)
export async function fetchUser(userId) { ... }
export async function fetchPostsForUser(userId) { ... }

// ก่อน: The Waterfall
function ProfilePage({ userId }) {
const user = useUserData(userId); // Request 1
return <UserPosts userId={user.id} />; // Request 2 เริ่มทำงานหลังจาก Request 1 เสร็จสิ้น
}

// หลัง: การดึงข้อมูลแบบขนาน
// ยูทิลิตี้สร้าง Resource
function createProfileData(userId) {
const userPromise = fetchUser(userId);
const postsPromise = fetchPostsForUser(userId);
return {
user: wrapPromise(userPromise),
posts: wrapPromise(postsPromise),
};
}
// `wrapPromise` เป็น helper ที่ช่วยให้คอมโพเนนต์อ่านผลลัพธ์ของ promise
// ถ้า promise กำลัง pending มันจะ throw promise นั้น
// ถ้า promise ได้รับการ resolve มันจะคืนค่ากลับไป
// ถ้า promise ถูก reject มันจะ throw error
const resource = createProfileData('123');
function ProfilePage() {
const user = resource.user.read(); // อ่านข้อมูลหรือ suspend
return (
<div>
<h1>{user.name}</h1>
<Suspense fallback={<h3>Loading posts...</h3>}>
<UserPosts />
</Suspense>
</div>
);
}
function UserPosts() {
const posts = resource.posts.read(); // อ่านข้อมูลหรือ suspend
return <ul>...</ul>;
}

ในรูปแบบที่ปรับปรุงใหม่นี้ `createProfileData` จะถูกเรียกเพียงครั้งเดียว และมันจะเริ่ม request การดึงข้อมูลทั้งผู้ใช้และโพสต์พร้อมกันทั้งสองอย่างทันที เวลาในการโหลดทั้งหมดตอนนี้จะถูกกำหนดโดย request ที่ช้าที่สุดในสองตัว ไม่ใช่ผลรวมของทั้งสอง หากทั้งสองใช้เวลา 500ms เวลารอทั้งหมดจะอยู่ที่ประมาณ 500ms แทนที่จะเป็น 1000ms นี่เป็นการปรับปรุงที่ยิ่งใหญ่มาก

กลยุทธ์ที่ 2: การย้ายการดึงข้อมูลขึ้นไปยัง Parent Component ร่วม

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

แนวคิด: ระบุ parent component ร่วมสำหรับคอมโพเนนต์ทั้งหมดที่ต้องการข้อมูล ย้าย logic การดึงข้อมูลเข้าไปใน parent นั้น จากนั้น parent สามารถดำเนินการ fetch แบบขนานและส่งข้อมูลลงมาเป็น props ได้ วิธีนี้จะรวมศูนย์ logic การดึงข้อมูลและทำให้มั่นใจได้ว่ามันจะทำงานเร็วที่สุดเท่าที่จะเป็นไปได้

// ก่อน: Sibling ดึงข้อมูลอย่างอิสระ
function Dashboard() {
return (
<div>
<Suspense fallback={...}><UserInfo /></Suspense>
<Suspense fallback={...}><Notifications /></Suspense>
</div>
);
}
// UserInfo ดึงข้อมูลผู้ใช้, Notifications ดึงข้อมูลการแจ้งเตือน
// React *อาจจะ* render พวกมันตามลำดับ ทำให้เกิด waterfall เล็กน้อย

// หลัง: Parent ดึงข้อมูลทั้งหมดแบบขนาน
const dashboardResource = createDashboardResource();
function Dashboard() {
// คอมโพเนนต์นี้ไม่ดึงข้อมูล แค่ประสานงานการ render
return (
<div>
<Suspense fallback={...}>
<UserInfo resource={dashboardResource} />
<Notifications resource={dashboardResource} />
</Suspense>
</div>
);
}
function UserInfo({ resource }) {
const user = resource.user.read();
return <div>Welcome, {user.name}</div>;
}
function Notifications({ resource }) {
const notifications = resource.notifications.read();
return <div>You have {notifications.length} new notifications.</div>;
}

ด้วยการย้าย logic การดึงข้อมูลขึ้นไป เราจึงรับประกันได้ว่าจะมีการทำงานแบบขนานและมอบประสบการณ์การโหลดที่สอดคล้องกันเพียงครั้งเดียวสำหรับแดชบอร์ดทั้งหมด

กลยุทธ์ที่ 3: การใช้ไลบรารีการดึงข้อมูลที่มีแคช

การจัดการ promise ด้วยตนเองนั้นใช้ได้ผล แต่มันอาจจะยุ่งยากในแอปพลิเคชันขนาดใหญ่ นี่คือจุดที่ไลบรารีการดึงข้อมูลโดยเฉพาะอย่าง React Query (ปัจจุบันคือ TanStack Query), SWR, หรือ Relay เข้ามามีบทบาท ไลบรารีเหล่านี้ถูกออกแบบมาเพื่อแก้ปัญหาอย่าง waterfall โดยเฉพาะ

แนวคิด: ไลบรารีเหล่านี้จะดูแลแคชในระดับ global หรือ provider เมื่อคอมโพเนนต์ร้องขอข้อมูล ไลบรารีจะตรวจสอบแคชก่อน หากมีหลายคอมโพเนนต์ร้องขอข้อมูลเดียวกันพร้อมกัน ไลบรารีจะฉลาดพอที่จะรวม request เหล่านั้น (de-duplicate) และส่ง network request จริงเพียงครั้งเดียว

มันช่วยได้อย่างไร:

การรวม Request (Request Deduplication): หากทั้ง `ProfilePage` และ `UserPosts` ร้องขอข้อมูลผู้ใช้เดียวกัน (เช่น `useQuery(['user', userId])`) ไลบรารีจะส่ง network request เพียงครั้งเดียว
การแคช (Caching): หากข้อมูลมีอยู่ในแคชจาก request ก่อนหน้าแล้ว request ต่อๆ มาจะสามารถ resolve ได้ทันที ซึ่งเป็นการทำลาย waterfall ที่อาจเกิดขึ้น
เป็นแบบขนานโดยปริยาย (Parallel by Default): ธรรมชาติของ hook สนับสนุนให้คุณเรียก `useQuery` ที่ระดับบนสุดของคอมโพเนนต์ของคุณ เมื่อ React ทำการ render มันจะเรียกใช้ hook เหล่านี้เกือบจะพร้อมกันทั้งหมด ซึ่งนำไปสู่การ fetch แบบขนานโดยปริยาย

// ตัวอย่างด้วย React Query
function ProfilePage({ userId }) {
// hook นี้จะส่ง request ของมันทันทีที่ render
const { data: user } = useQuery(['user', userId], () => fetchUser(userId), { suspense: true });
return (
<div>
<h1>{user.name}</h1>
<Suspense fallback={<h3>Loading posts...</h3>}>
// แม้ว่าจะซ้อนกันอยู่ แต่ React Query มักจะ pre-fetch หรือดึงข้อมูลแบบขนานได้อย่างมีประสิทธิภาพ
<UserPosts userId={user.id} />
</Suspense>
</div>
);
}
function UserPosts({ userId }) {
const { data: posts } = useQuery(['posts', userId], () => fetchPostsForUser(userId), { suspense: true });
return <ul>...</ul>;
}

แม้ว่าโครงสร้างโค้ดอาจจะยังดูเหมือน waterfall แต่ไลบรารีอย่าง React Query มักจะฉลาดพอที่จะบรรเทาปัญหานี้ได้ เพื่อประสิทธิภาพที่ดียิ่งขึ้น คุณสามารถใช้ API สำหรับ pre-fetching ของพวกเขาเพื่อเริ่มโหลดข้อมูลอย่างชัดเจนก่อนที่คอมโพเนนต์จะ render ด้วยซ้ำ

กลยุทธ์ที่ 4: รูปแบบ Render-as-You-Fetch

นี่เป็นรูปแบบที่ล้ำหน้าและมีประสิทธิภาพสูงสุด ซึ่งทีม React สนับสนุนอย่างมาก มันพลิกโมเดลการดึงข้อมูลทั่วไปแบบกลับหัวกลับหาง

Fetch-on-Render (ปัญหา): Render คอมโพเนนต์ -> useEffect/hook เริ่มการ fetch (นำไปสู่ waterfall)
Fetch-then-Render: เริ่มการ fetch -> รอ -> render คอมโพเนนต์พร้อมข้อมูล (ดีขึ้น แต่ยังสามารถบล็อกการ render ได้)
Render-as-You-Fetch (ทางออก): เริ่มการ fetch -> เริ่ม render คอมโพเนนต์ทันที คอมโพเนนต์จะ suspend หากข้อมูลยังไม่พร้อม

แนวคิด: แยกการดึงข้อมูลออกจาก lifecycle ของคอมโพเนนต์โดยสิ้นเชิง คุณเริ่มต้น network request ในช่วงเวลาที่เร็วที่สุดเท่าที่จะเป็นไปได้ เช่น ในชั้นของ routing หรือใน event handler (เช่น การคลิกลิงก์) — ก่อนที่คอมโพเนนต์ที่ต้องการข้อมูลจะเริ่ม render ด้วยซ้ำ

// 1. เริ่มการ fetch ใน router หรือ event handler
import { createProfileData } from './api';
// เมื่อผู้ใช้คลิกลิงก์ไปยังหน้าโปรไฟล์:
function onProfileLinkClick(userId) {
const resource = createProfileData(userId);
navigateTo(`/profile/${userId}`, { state: { resource } });
}

// 2. คอมโพเนนต์หน้าเว็บได้รับ resource
function ProfilePage() {
// รับ resource ที่ได้เริ่มทำงานไปแล้ว
const resource = useLocation().state.resource;
return (
<Suspense fallback={<h1>Loading profile...</h1>}>
<ProfileDetails resource={resource} />
<ProfilePosts resource={resource} />
</Suspense>
);
}

// 3. Child components อ่านข้อมูลจาก resource
function ProfileDetails({ resource }) {
const user = resource.user.read(); // อ่านข้อมูลหรือ suspend
return <h1>{user.name}</h1>;
}
function ProfilePosts({ resource }) {
const posts = resource.posts.read(); // อ่านข้อมูลหรือ suspend
return <ul>...</ul>;
}

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

เปรียบเทียบกลยุทธ์การปรับปรุงประสิทธิภาพ: ควรเลือกแบบไหน?

การเลือกกลยุทธ์ที่เหมาะสมขึ้นอยู่กับความซับซ้อนและเป้าหมายด้านประสิทธิภาพของแอปพลิเคชันของคุณ

การดึงข้อมูลแบบขนาน (`Promise.all` / การจัดการด้วยตนเอง):
- ข้อดี: ไม่จำเป็นต้องใช้ไลบรารีภายนอก แนวคิดง่ายสำหรับความต้องการข้อมูลที่อยู่ใกล้กัน ควบคุมกระบวนการได้เต็มที่
- ข้อเสีย: อาจซับซ้อนในการจัดการ state, error และการแคชด้วยตนเอง ไม่สามารถขยายขนาดได้ดีหากไม่มีโครงสร้างที่มั่นคง
- เหมาะสำหรับ: กรณีการใช้งานง่ายๆ, แอปพลิเคชันขนาดเล็ก, หรือส่วนที่สำคัญต่อประสิทธิภาพซึ่งคุณต้องการหลีกเลี่ยง overhead ของไลบรารี
การย้ายการดึงข้อมูลขึ้นไป (Lifting Data Fetching):
- ข้อดี: ดีสำหรับการจัดระเบียบการไหลของข้อมูลใน component tree รวมศูนย์ logic การดึงข้อมูลสำหรับ view ที่เฉพาะเจาะจง
- ข้อเสีย: อาจนำไปสู่ prop drilling หรือต้องใช้โซลูชันการจัดการ state เพื่อส่งข้อมูลลงมา parent component อาจมีขนาดใหญ่เกินไป
- เหมาะสำหรับ: เมื่อ sibling component หลายตัวมีการพึ่งพาข้อมูลร่วมกันซึ่งสามารถดึงได้จาก parent ร่วมของพวกมัน
ไลบรารีการดึงข้อมูล (React Query, SWR):
- ข้อดี: เป็นโซลูชันที่แข็งแกร่งและเป็นมิตรกับนักพัฒนามากที่สุด จัดการการแคช, การรวม request, การ refetch ในเบื้องหลัง และสถานะ error ได้ทันที ลด boilerplate ได้อย่างมาก
- ข้อเสีย: เพิ่ม dependency ของไลบรารีเข้ามาในโปรเจกต์ของคุณ ต้องเรียนรู้ API เฉพาะของไลบรารีนั้นๆ
- เหมาะสำหรับ: แอปพลิเคชัน React สมัยใหม่ส่วนใหญ่ นี่ควรเป็นตัวเลือกเริ่มต้นสำหรับโปรเจกต์ใดๆ ที่มีความต้องการข้อมูลที่ไม่ใช่เรื่องเล็กน้อย
Render-as-You-Fetch:
- ข้อดี: เป็นรูปแบบที่มีประสิทธิภาพสูงสุด เพิ่มความเป็นขนานให้สูงสุดโดยการทำให้การโหลดโค้ดของคอมโพเนนต์และการดึงข้อมูลเกิดขึ้นพร้อมกัน
- ข้อเสีย: ต้องมีการเปลี่ยนแปลงแนวคิดอย่างมาก อาจต้องใช้ boilerplate มากขึ้นในการตั้งค่าหากไม่ได้ใช้เฟรมเวิร์กอย่าง Relay หรือ Next.js ที่มีรูปแบบนี้ในตัว
- เหมาะสำหรับ: แอปพลิเคชันที่ latency เป็นสิ่งสำคัญซึ่งทุกมิลลิวินาทีมีความหมาย เฟรมเวิร์กที่รวม routing เข้ากับการดึงข้อมูลเป็นสภาพแวดล้อมที่เหมาะสำหรับรูปแบบนี้

ข้อควรพิจารณาสำหรับผู้ใช้ทั่วโลกและแนวทางปฏิบัติที่ดีที่สุด

เมื่อสร้างแอปสำหรับผู้ใช้ทั่วโลก การกำจัด waterfall ไม่ใช่แค่เรื่องที่ดี แต่เป็นสิ่งจำเป็น

Latency ไม่สม่ำเสมอ: waterfall 200ms อาจแทบไม่สังเกตเห็นสำหรับผู้ใช้ที่อยู่ใกล้เซิร์ฟเวอร์ของคุณ แต่สำหรับผู้ใช้ในทวีปอื่นที่ใช้อินเทอร์เน็ตมือถือที่มี latency สูง waterfall เดียวกันนั้นอาจเพิ่มเวลาในการโหลดของพวกเขาไปอีกหลายวินาที การทำ request แบบขนานเป็นวิธีที่มีประสิทธิภาพที่สุดในการลดผลกระทบของ latency สูง
Code Splitting Waterfalls: Waterfalls ไม่ได้จำกัดอยู่แค่ข้อมูล รูปแบบที่พบบ่อยคือ `React.lazy()` โหลด bundle ของคอมโพเนนต์ ซึ่งจากนั้นก็ดึงข้อมูลของตัวเอง นี่คือ waterfall แบบ code -> data รูปแบบ Render-as-You-Fetch ช่วยแก้ปัญหานี้โดยการ preload ทั้งคอมโพเนนต์และข้อมูลของมันเมื่อผู้ใช้ทำการนำทาง
การจัดการ Error อย่างนุ่มนวล: เมื่อคุณดึงข้อมูลแบบขนาน คุณต้องพิจารณาความล้มเหลวบางส่วน จะเกิดอะไรขึ้นถ้าข้อมูลผู้ใช้โหลดได้ แต่โพสต์ล้มเหลว? UI ของคุณควรสามารถจัดการสิ่งนี้ได้อย่างนุ่มนวล อาจจะแสดงโปรไฟล์ผู้ใช้พร้อมข้อความแสดงข้อผิดพลาดในส่วนของโพสต์ ไลบรารีอย่าง React Query มีรูปแบบที่ชัดเจนสำหรับการจัดการสถานะ error ของแต่ละ query
Fallback ที่มีความหมาย: ใช้ prop `fallback` ของ `` เพื่อมอบประสบการณ์ผู้ใช้ที่ดีในขณะที่กำลังโหลดข้อมูล แทนที่จะใช้ spinner ทั่วไป ให้ใช้ skeleton loader ที่เลียนแบบรูปร่างของ UI สุดท้าย สิ่งนี้ช่วยปรับปรุงประสิทธิภาพที่รับรู้ได้และทำให้แอปพลิเคชันรู้สึกเร็วขึ้น แม้ว่าเครือข่ายจะช้าก็ตาม

สรุป

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

เราได้สำรวจกลยุทธ์อันทรงพลังหลายอย่าง ตั้งแต่การจัดการ promise ด้วยตนเองไปจนถึงรูปแบบ Render-as-You-Fetch ที่มีประสิทธิภาพสูง สำหรับแอปพลิเคชันสมัยใหม่ส่วนใหญ่ การใช้ไลบรารีการดึงข้อมูลโดยเฉพาะอย่าง TanStack Query หรือ SWR จะให้ความสมดุลที่ดีที่สุดระหว่างประสิทธิภาพ ประสบการณ์ของนักพัฒนา และฟีเจอร์ที่ทรงพลังเช่นการแคชและการรวม request

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