7 ทริคเร่งความเร็วเว็บด้วย Next.js App Router, Server Components และ Streaming

การพัฒนาเว็บด้วย Next.js App Router เปิดโอกาสให้เราสร้างประสบการณ์ที่เร็วขึ้นได้มาก โดยเฉพาะเมื่อใช้แนวคิดอย่าง Server Components, Streaming และ Suspense อย่างเหมาะสม หลายทีมอาจยังใช้ความสามารถเหล่านี้ไม่เต็มที่ ทั้งที่สามารถช่วยลดภาระฝั่ง client และทำให้ผู้ใช้รู้สึกว่าเว็บตอบสนองได้ไวขึ้นอย่างชัดเจน

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

1) แยกส่วนที่ต้อง interactive ออกจากส่วนที่มีไว้ให้อ่าน

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

แนวทางที่มีประสิทธิภาพคือทำให้ ส่วนใหญ่ของหน้าเป็น Server Component แล้วค่อยใช้ Client Component เฉพาะจุดที่จำเป็นจริง ๆ เช่น

• ปุ่มกด
• ฟอร์ม
• ตัวกรอง
• ส่วนที่มี state และ event interaction

ผลลัพธ์ที่ได้คือ

• ลดขนาด bundle ฝั่ง client
• ลด JavaScript ที่ผู้ใช้ต้องโหลด
• ทำให้ TTI (Time to Interactive) ดีขึ้นอย่างเห็นได้ชัด

2) ใช้ Streaming กับ Suspense เพื่อให้ผู้ใช้เห็นเนื้อหาได้ก่อน

แม้จะใช้ SSR แล้ว แต่ถ้ารอข้อมูลครบทุกก้อนก่อนค่อย render ผู้ใช้ก็ยังอาจเจอจอว่างหรือรอนานอยู่ดี

แนวคิดของ Streaming คือส่ง HTML ชุดแรกที่พร้อมออกไปก่อน แล้วค่อยส่งส่วนที่เหลือเพิ่มเติมเมื่อข้อมูลพร้อม โดยใช้ Suspense เป็นตัวแบ่งช่วงการแสดงผล

ตัวอย่างเช่น

• header และ hero section แสดงก่อน
• รายการข้อมูลขนาดใหญ่ค่อยตามมาทีหลัง
• บางส่วนของ dashboard โหลดแยกกันได้

แนวทางนี้เหมาะมากกับ

• หน้า feed
• dashboard
• หน้าสินค้า
• หน้าที่มีหลายส่วนและใช้ข้อมูลหลายแหล่ง

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

3) ใช้ Route-level loading และออกแบบ Loading ให้ใกล้เคียงของจริง

ใน Next.js App Router ไฟล์ loading ช่วยให้การเปลี่ยนหน้าเป็นไปอย่างลื่นไหลขึ้น เพราะระบบสามารถแสดง UI โครงร่างระหว่างรอข้อมูลได้ทันที

จุดที่หลายคนมองข้ามคือการทำ skeleton loading ให้ใกล้เคียงกับ layout จริงมากที่สุด เพราะจะช่วยลดปัญหา layout shift หรืออาการที่หน้าเว็บขยับไปมาเมื่อข้อมูลจริงโหลดเข้ามา

ประโยชน์ที่ได้คือ

• การเปลี่ยน route ดูสมูทขึ้น
• ผู้ใช้รับรู้ว่าเว็บตอบสนองเร็ว
• ลดความรู้สึกรอ แม้ข้อมูลจริงจะยังมาไม่ครบ

การออกแบบ loading ที่ดีจึงไม่ใช่แค่เรื่องความสวยงาม แต่เป็นส่วนหนึ่งของ performance perception โดยตรง

4) ย้ายการดึงข้อมูลไปใกล้ component ที่ใช้จริง

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

ทางเลือกที่ดีกว่าคือให้ แต่ละ Server Component ดึงข้อมูลของตัวเอง เท่าที่จำเป็น และใช้ Suspense คั่นตรงจุดที่อาจช้า

ข้อดีของแนวทางนี้คือ

• ทำ parallel fetching ได้ง่ายขึ้น
• ส่วนที่โหลดเร็วสามารถแสดงผลก่อน
• โค้ดแยกตามหน้าที่ของ component ชัดเจนขึ้น
• ลดการส่ง props ยาว ๆ ผ่านหลายชั้น

นี่เป็นแนวคิดที่ช่วยทั้งเรื่อง performance และ maintainability ไปพร้อมกัน

5) ใช้ cache ของ fetch ให้เหมาะกับลักษณะข้อมูล

เรื่อง cache เป็นอีกจุดที่หลายทีมตั้งค่าไม่เหมาะสม จนทำให้ระบบช้าหรือยิง API ซ้ำโดยไม่จำเป็น

หลักคิดง่าย ๆ คือ

• ถ้าข้อมูลแทบไม่เปลี่ยน ควรใช้ cache
• ถ้าข้อมูลต้องสดมาก ค่อยใช้แบบไม่ cache

สิ่งสำคัญคืออย่าใช้แนวทางเดียวกับทุก endpoint เพราะข้อมูลแต่ละประเภทมีลักษณะไม่เหมือนกัน เช่น

• ข้อมูลพื้นฐานของสินค้า อาจ cache ได้
• จำนวนคงเหลือหรือราคาแบบเรียลไทม์ อาจต้องสดกว่า

ทริคที่ช่วยได้มากคือการ แยก endpoint สำหรับข้อมูลสด ออกจาก endpoint สำหรับข้อมูลพื้นฐาน เพื่อควบคุมสมดุลระหว่างความเร็วและความสดของข้อมูลได้ง่ายขึ้น

6) ลดปัญหา Waterfall ด้วยการจัดลำดับการดึงข้อมูลใหม่

หลายหน้ามีการเรียก API หลายตัว และถ้าดึงข้อมูลแบบรอทีละตัว จะเกิดสิ่งที่เรียกว่า waterfall คือความช้าสะสมต่อกันเป็นทอด ๆ

แนวทางที่ควรทำคือ

• เรียก API พร้อมกันให้มากที่สุด
• ยอมให้เป็นลำดับเฉพาะกรณีที่ API หนึ่งต้องใช้ผลลัพธ์จากอีก API จริง ๆ
• ใช้ Suspense ช่วยแยกการแสดงผลตามส่วน

หลักสังเกตง่าย ๆ คือ ถ้า API B ไม่จำเป็นต้องรอ API A ก็ไม่ควรเขียนให้มันรอ เพราะจะทำให้เวลารวมช้าลงโดยไม่จำเป็น

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

7) ใช้ Server Actions เพื่อลดภาระฝั่ง client

หลายทีมยังคงจัดการฟอร์มแบบเต็มรูปแบบบน client ไม่ว่าจะเป็น

• จัดการ state
• validate
• เรียก API
• อัปเดตข้อมูลหลัง submit

แม้วิธีนี้จะทำงานได้ แต่ก็อาจทำให้ฝั่ง client แบกรับ JavaScript มากเกินไป

Server Actions ช่วยย้ายงานบางประเภทไปทำบน server ได้เหมาะสมกว่า เช่น

• การ submit ฟอร์ม
• การ mutate ข้อมูล
• การ revalidate

ข้อดีคือ

• ลด JavaScript ฝั่ง client
• ลดความเสี่ยงจากการจัดการ secret หรือ key ผิดที่
• ทำให้ flow หลัง submit ดูลื่นไหลและเป็นธรรมชาติมากขึ้น

สำหรับงานที่ไม่จำเป็นต้องให้ client จัดการเองทั้งหมด การใช้ Server Actions ถือเป็นอีกทางเลือกที่ช่วยเรื่อง performance ได้ดี

ตัวอย่างภาพรวมของการออกแบบหน้า Product

หากนำแนวคิดทั้งหมดมาปรับใช้กับหน้าสินค้า อาจจัดโครงสร้างได้ดังนี้

• ส่วนหัวและรูปหลัก render จาก server ได้ทันที
• รีวิวแยกเป็นอีกส่วนหนึ่ง แล้ว stream ตามมาทีหลัง
• ปุ่ม Add to cart ใช้เป็น Client Component เฉพาะจุด

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

เช็กลิสต์ก่อนปล่อยงานจริง

ก่อน deploy งาน ควรตรวจสอบประเด็นต่อไปนี้

• bundle JavaScript ที่ส่งไปให้ผู้ใช้จำเป็นจริงหรือไม่
• จุดที่ช้าสามารถแยกเป็นก้อนและครอบด้วย Suspense ได้หรือไม่
• ข้อมูลใดควร cache และข้อมูลใดควรสด
• มีจุดไหนที่ยังเกิด waterfall โดยไม่จำเป็นหรือไม่
• loading state ที่แสดงอยู่ใกล้เคียงกับหน้าจริงเพียงพอหรือยัง

สรุป

การทำเว็บให้เร็วขึ้นใน Next.js App Router ไม่จำเป็นต้องเริ่มจากการเปลี่ยนดีไซน์ครั้งใหญ่เสมอไป หลายครั้งเพียงแค่แยกความรับผิดชอบของ component ให้ดี ใช้ Server Components ให้มากขึ้น ใช้ Streaming และ Suspense อย่างถูกจุด รวมถึงจัดการ cache และ data fetching อย่างเหมาะสม ก็ช่วยให้หน้าเว็บตอบสนองดีขึ้นได้อย่างมาก

ทั้ง 7 ข้อนี้เป็นแนวทางที่นำไปใช้ได้จริง และหากทำครบถ้วน หลายหน้าบนเว็บจะเร็วขึ้นแบบที่ผู้ใช้รู้สึกได้ทันที