Next.js Secret Sauce: ทำเว็บเร็วขึ้นแบบเห็นผลด้วย Server Actions และ Streaming

หลายทีมอัปเกรดมาใช้ Next.js รุ่นใหม่แล้ว แต่ยังคงพัฒนาเว็บในรูปแบบเดิม คือผลักงานจำนวนมากไปไว้ฝั่ง client จนเกิดปัญหา bundle ใหญ่ โหลดช้า และต้องรอ API ตอบกลับก่อนผู้ใช้จึงจะเริ่มเห็นหน้าเว็บจริง ๆ

หากต้องการให้เว็บ “เร็วแบบรู้สึกได้” แนวคิดที่ควรให้ความสำคัญมีอยู่ 2 เรื่องหลัก คือ Server Actions และ Streaming เพราะทั้งคู่ช่วยลดความหน่วงที่ผู้ใช้สัมผัสได้โดยตรง และทำให้โครงสร้างแอปสะอาดขึ้นในเวลาเดียวกัน

Server Actions คืออะไร และทำไมถึงช่วยให้พัฒนาเร็วขึ้น

ก่อนมี Server Actions การทำฟอร์มหนึ่งฟอร์มมักต้องผ่านหลายชั้น เช่น

• ฝั่ง client ส่ง fetch ไปยัง API route
• API route เรียก service หรือฐานข้อมูล
• ส่งผลลัพธ์กลับมาที่ client เพื่ออัปเดต state

แนวทางนี้ทำงานได้ แต่มีต้นทุนแฝงทั้งในแง่การพัฒนาและการดูแลระบบ โดยเฉพาะเวลาที่ต้องดีบัก เพราะข้อมูลไหลผ่านหลายไฟล์ หลายจุด และหลาย endpoint

Server Actions เข้ามาเปลี่ยนวิธีคิด โดยเปิดให้เราเรียกฟังก์ชันฝั่งเซิร์ฟเวอร์ได้โดยตรงจากฟอร์มหรือจากการกระทำบางอย่างในแอป ทำให้ขั้นตอนสั้นลงและชัดเจนขึ้นมาก

ข้อดีของ Server Actions

• ลด boilerplate ของ API route ในงาน CRUD ขนาดเล็ก
• ลดการส่งข้อมูลไปกลับโดยไม่จำเป็น
• รวม validation และการเขียนข้อมูลลงฐานข้อมูลไว้ในที่เดียว
• เพิ่มความปลอดภัย เพราะ secret และ logic สำคัญไม่ต้องถูกส่งไปอยู่ฝั่ง client

อีกจุดที่มีประโยชน์มากแต่คนมักมองข้าม คือการจัดการ cache และ revalidate ได้อย่างเป็นธรรมชาติ เช่น เมื่อเพิ่มข้อมูลสำเร็จ ก็สามารถสั่งรีเฟรชหน้าหรือส่วนที่เกี่ยวข้องให้แสดงข้อมูลล่าสุดได้ทันที โดยไม่ต้องคอยไล่เขียน invalidate logic ไว้หลายตำแหน่ง

Streaming ทำให้ผู้ใช้เห็นหน้าเร็วขึ้น แม้ข้อมูลยังมาไม่ครบ

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

Streaming แก้ปัญหานี้ด้วยการอนุญาตให้เซิร์ฟเวอร์ส่ง HTML ออกมาเป็นส่วน ๆ ได้ เมื่อส่วนไหนพร้อมก่อนก็แสดงก่อน ส่วนที่ยังต้องรอฐานข้อมูลหรือ API ก็สามารถแสดง fallback ระหว่างนั้นได้

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

เปรียบเทียบแบบเข้าใจง่าย

Streaming ก็เหมือนการเสิร์ฟอาหารเป็นจาน ๆ

• จานที่พร้อมก่อน ก็ยกมาเสิร์ฟก่อน
• จานที่ยังทำไม่เสร็จ ก็ทยอยตามมา

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

จุดที่เหมาะกับการใช้ Streaming

Streaming จะเห็นผลดีมากในหน้าที่มีข้อมูลหลายแหล่งหรือมีบางส่วนที่ใช้เวลานานกว่าส่วนอื่น เช่น

• Dashboard ที่มีหลายการ์ดและหลายกราฟ
• หน้าสินค้าที่มีข้อมูลรีวิว คำแนะนำ และสต็อกจากหลายระบบ
• หน้าแรกที่มีส่วนของบทความล่าสุดหรือข้อมูลจากบริการภายนอก

ในกรณีเหล่านี้ การแสดงส่วนที่พร้อมก่อนสามารถลดความรู้สึกว่าหน้าเว็บช้าได้อย่างมีประสิทธิภาพ

วิธีเริ่มใช้ในโปรเจกต์เล็กแบบทำวันนี้เห็นผล

ไม่จำเป็นต้องยกเครื่องทั้งระบบในครั้งเดียว หากต้องการทดลองแบบเสี่ยงน้อย สามารถเริ่มทีละขั้นได้ดังนี้

1. แยกส่วนที่ไม่จำเป็นต้อง interactive ออกจาก client

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

• header
• list
• summary

ส่วนเหล่านี้มักสามารถย้ายไปเป็น Server Component ได้ เพื่อลด JavaScript ที่ต้องโหลดฝั่ง client

2. เลือกฟอร์ม 1 จุดมาเปลี่ยนเป็น Server Action

ตัวอย่างที่เหมาะสำหรับเริ่มต้น เช่น

• เพิ่มรายการ todo
• สมัคร newsletter
• บันทึกโปรไฟล์

ฟอร์มลักษณะนี้มักเป็นงานเขียนข้อมูลตรงไปยังระบบหลังบ้าน และได้ประโยชน์จาก Server Actions อย่างชัดเจน

3. ใส่ Streaming ด้วย Suspense ในส่วนที่ช้าที่สุด

ลองเลือกเพียง 1 จุดที่ใช้เวลานานที่สุดก่อน เช่น

• กล่อง “รายการล่าสุด”
• ส่วนที่ต้อง query หนัก
• โมดูลที่ดึงข้อมูลจากระบบภายนอก

การใส่ Suspense ให้ fallback ที่เหมาะสม จะช่วยให้หน้าไม่หยุดรอทั้งก้อน

ข้อควรระวังที่พบบ่อย

แม้ทั้งสองแนวทางจะทรงพลัง แต่ก็มีข้อจำกัดที่ควรเข้าใจตั้งแต่ต้น

แยก server และ client ให้ชัดเจน

อย่านำสิ่งที่ต้องพึ่ง browser เช่น window หรือ localStorage ไปใช้ในฝั่ง server หากจำเป็นต้องใช้จริง ควรแยกออกเป็น Client Component อย่างชัดเจน

Server Actions ไม่ได้แทนทุกอย่าง

Server Actions เหมาะมากกับงานที่เกี่ยวข้องกับการเขียนข้อมูล หรือ logic ที่ควรอยู่ในพื้นที่ปลอดภัยของเซิร์ฟเวอร์ แต่หากระบบต้องการ realtime สูงมาก อาจยังต้องใช้เทคโนโลยีเสริม เช่น WebSocket หรือ Server-Sent Events

Streaming ไม่ได้แก้ทุกปัญหาความช้า

Streaming ช่วยเรื่อง perceived performance หรือความรู้สึกว่าระบบตอบสนองเร็วขึ้น แต่ถ้า query ช้าเกินไปจริง ๆ ต้นเหตุหลักก็ยังต้องกลับไปแก้ที่ฐานข้อมูล การออกแบบ query หรือระบบ cache

สัญญาณว่าโปรเจกต์ของคุณควรใช้ Server Actions และ Streaming

หากโปรเจกต์มีลักษณะต่อไปนี้ ควรพิจารณาใช้สองแนวทางนี้อย่างจริงจัง

• มีฟอร์มจำนวนมาก และมี API route แนว CRUD ซ้ำ ๆ
• หน้าเว็บต้องรอหลาย endpoint ก่อนจะแสดงผลได้
• ต้องการลด JavaScript ฝั่ง client แต่ยังคง UX ที่ดี

เมื่อเห็นสัญญาณเหล่านี้ การปรับโครงสร้างบางส่วนให้ใช้ Server Actions และ Streaming มักให้ผลลัพธ์ที่คุ้มค่า

ทำไมสองอย่างนี้ถึงทำงานร่วมกันได้ดี

Server Actions ช่วยให้การจัดการข้อมูลจากฝั่งเซิร์ฟเวอร์ง่ายขึ้น ปลอดภัยขึ้น และลดโค้ดส่วนเกิน ขณะที่ Streaming ช่วยให้ผู้ใช้ไม่ต้องรอทุกอย่างเสร็จก่อนจึงค่อยเริ่มเห็นหน้าเว็บ

เมื่อใช้ร่วมกัน ผลที่ได้คือ

• แอปเบาขึ้น
• โหลดเร็วขึ้น
• โค้ดสะอาดขึ้น
• ประสบการณ์ผู้ใช้ดีขึ้นทั้งในเชิงตัวเลขและความรู้สึก

สรุป

Server Actions ช่วยให้การพัฒนาใน Next.js ตรงประเด็นขึ้น ลดขั้นตอนที่ไม่จำเป็น และเพิ่มความปลอดภัยในการจัดการข้อมูล ส่วน Streaming ช่วยให้หน้าเว็บแสดงผลได้ไวขึ้นด้วยการทยอยส่งส่วนที่พร้อมก่อน

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