Client​-​side​ ​Rendering​,​ ​Server​-​side​ ​Rendering​ ​และ​ ​Static​ ​Generation​ ​ต่าง​กัน​อย่างไร

CSR, SSR และ SSG เป็นวิธีจัดว่า HTML ของหน้าถูกสร้างเมื่อใดและที่ใด CSR ให้ Browser สร้างเนื้อหาหลักด้วย JavaScript SSR ให้ Server สร้าง HTML เมื่อมีคำขอ ส่วน SSG สร้างหน้าไว้ล่วงหน้าตอน Build หรือรอบสร้างใหม่ตามระบบที่ใช้ หนึ่งเว็บไซต์อาจใช้หลายวิธีร่วมกัน ไม่จำเป็นต้องเลือกแบบเดียวทุกหน้า

ผลต่อผู้ใช้และระบบ

CSR อาจเหมาะกับหน้าที่โต้ตอบสูง แต่ต้องดูเวลาโหลด JavaScript และข้อมูลก่อนเห็นเนื้อหา SSR ช่วยส่ง HTML ที่มีข้อมูลตอนร้องขอ แต่ใช้ทรัพยากร Server และต้องจัดการ Cache กับสิทธิ์ SSG เหมาะกับข้อมูลที่เปลี่ยนไม่บ่อยและแจกจ่ายซ้ำได้ แต่ต้องมีวิธีอัปเดตเมื่อข้อมูลเปลี่ยน การมี HTML เร็วไม่ได้แปลว่าการโต้ตอบพร้อมทันที ต้องตรวจช่วง hydration และข้อมูลที่ดึงเพิ่มด้วย

ภาพที่ 1: วิธี Rendering ต่างกันที่จุดสร้างหน้าและรอบอัปเดตข้อมูล ไม่ใช่เพียงชื่อ Framework

ตัวอย่างสมมติ

หน้าบทความที่ปรับเดือนละครั้งอาจสร้างไว้ล่วงหน้า หน้ารายละเอียดบัญชีที่เปลี่ยนตามผู้ใช้ต้องอ่านข้อมูลพร้อมสิทธิ์ในแต่ละคำขอ ส่วนฟอร์มที่มีการโต้ตอบมากอาจใช้โค้ดฝั่ง Browser เพิ่มในหน้าเดียวกัน ตัวอย่างนี้แสดงว่าการเลือกระดับหน้าและส่วนประกอบให้ตรงข้อมูลสำคัญกว่าป้าย CSR หรือ SSR ทั้งระบบ

วิธีตัดสินใจและข้อจำกัด

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

ใช้ในรายงาน

วาดลำดับ Browser, Server และขั้น Build ของหน้าเดียวกันภายใต้สามทางเลือก แล้วให้เหตุผลจากความสดของข้อมูล สิทธิ์ และต้นทุนการดูแล หากอ้าง Next.js ควรระบุเวอร์ชัน เพราะรายละเอียดการ Cache และ Rendering อาจเปลี่ยนตามรุ่น

อ่าน Next.js คืออะไร และ Frontend Development หรือดู บริการเว็บไซต์ธุรกิจ

วิเคราะห์กรณีศึกษาเพื่อนำไปเขียนรายงาน

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

หลักฐานที่ควรแสดงคือ ตารางว่า HTML เกิดที่ Browser, Server ต่อ request หรือช่วง build ควรอธิบายสัญลักษณ์ คำย่อ หรือเงื่อนไขในหลักฐานนั้นให้ผู้อ่านที่ไม่อยู่ในทีมเข้าใจ และบอกว่ามันเชื่อมกับ Requirement ข้อใด ถ้ามีหลายทางเลือก ให้ระบุเหตุผลที่เลือกทางหนึ่งและผลกระทบต่อผู้ใช้ ทีมพัฒนา หรือผู้ดูแลระบบ แทนการเขียนเพียงว่าใช้แนวทางที่ “ดีที่สุด” โดยไม่มีเกณฑ์เปรียบเทียบ

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

แหล่งข้อมูลประกอบ

• Next.js Learn: Static and Dynamic Rendering — จุดสร้างและรอบอัปเดตหน้า
• Next.js: Server and Client Components — การประกอบงานฝั่ง Server และ Browser