ทำให้ JavaScript เร็วขึ้นด้วยการประมวลผลขนาน: เลือก Web Workers, Workers Pool หรือปรับ Server อย่างไร

ดูแบบสรุปเร็ว

• ใช้ Web Workers เมื่อมีงานคำนวณหนักที่ไม่จำเป็นต้องแตะ DOM โดยตรง
• ใช้ workers pool เมื่องานเข้ามาหลายรายการและต้องจำกัดจำนวนงานที่รันพร้อมกัน
• พิจารณาเซิร์ฟเวอร์หรือ cloud เมื่องานข้อมูลใหญ่ ส่งถ่ายข้อมูลบ่อย หรือควรประมวลผลรวมศูนย์

แนวทาง	เหมาะกับงาน	ความซับซ้อนในการทำ	ต้นทุนที่ควรประเมิน	สิ่งที่ต้องวัดผล
Web Workers	คำนวณข้อมูล แปลงไฟล์ วิเคราะห์ข้อมูล เข้ารหัส	ปานกลาง	เวลาทีมพัฒนา การออกแบบ message passing	เวลาที่ main thread ถูกใช้งาน การตอบสนองของ UI
Workers pool	งานหนักหลายชิ้นที่เกิดซ้ำหรือเข้าคิวต่อเนื่อง	ปานกลางถึงสูง	การจัดคิว การคืน Worker การจัดการข้อผิดพลาด	เวลารอคิว งานที่รันพร้อมกัน และ overhead
WebAssembly	งานคำนวณที่ต้องการประสิทธิภาพสูงตามลักษณะงาน	สูง	การพัฒนา การทดสอบ และการดูแลโค้ด	เวลา compute เทียบกับค่าใช้จ่ายในการรวมระบบ
ประมวลผลบนเซิร์ฟเวอร์	งานใหญ่ งานรวมศูนย์ งานที่ควรควบคุมทรัพยากรจากส่วนกลาง	ปานกลางถึงสูง	cloud, server, monitoring และการรับส่งข้อมูล	เวลาเครือข่าย ภาระเซิร์ฟเวอร์ และประสบการณ์ผู้ใช้

คำตอบสั้น ๆ: งานแบบไหนควรแยกออกจาก main thread

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

สัญญาณว่า JavaScript กำลังทำให้หน้าเว็บหน่วง

สัญญาณที่ควรตรวจสอบคือการกดปุ่มแล้ว UI ตอบสนองช้า การเลื่อนหน้าไม่ลื่น การกรอกข้อมูลแล้วมีอาการค้าง หรือแดชบอร์ดสะดุดระหว่างคำนวณและอัปเดตกราฟ อาการเหล่านี้ไม่ได้ยืนยันว่า Worker คือคำตอบเสมอไป แต่เป็นเหตุผลที่ดีในการเปิด performance profiling เพื่อดูว่า main thread ใช้เวลากับฟังก์ชันใด

ทีมไม่ควรรีบเพิ่มสเปกเซิร์ฟเวอร์หรือซื้อเครื่องมือมอนิเตอร์เพียงเพราะหน้าเว็บช้า หากคอขวดเกิดจาก JavaScript ฝั่งผู้ใช้ การเพิ่มทรัพยากรฝั่งเซิร์ฟเวอร์อาจไม่แก้ปัญหาการตอบสนองของ UI ได้ตรงจุด

งานที่ได้ประโยชน์จากการประมวลผลขนาน

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

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

งานที่ไม่ควรย้ายไป Worker โดยอัตโนมัติ

งานที่ต้องเปลี่ยน DOM หรือควบคุม UI โดยตรงไม่ควรถูกย้ายไป Worker โดยคาดหวังว่าจะทำงานแทนหน้าหลักได้ เพราะ Worker เข้าถึง DOM โดยตรงไม่ได้ การย้ายงานเล็กมากไปมาอาจไม่คุ้มเช่นกัน เนื่องจากการส่งข้อความระหว่าง main thread กับ Worker มีต้นทุน

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

เปรียบเทียบ Web Workers, workers pool, WebAssembly และการประมวลผลบนเซิร์ฟเวอร์

ไม่มีแนวทางเดียวที่เหมาะกับทุกเว็บ การเลือกควรดูพร้อมกันทั้ง ลักษณะงาน ปริมาณข้อมูล ความถี่ อุปกรณ์ผู้ใช้ ต้นทุนพัฒนา และต้นทุนดูแลรักษา Web Workers ช่วยย้ายงานคำนวณออกจาก main thread ส่วน workers pool ช่วยควบคุมการใช้ Worker หลายตัว ขณะที่ WebAssembly เป็นอีกทางเลือกสำหรับงานคำนวณตามความเหมาะสม และการประมวลผลบนเซิร์ฟเวอร์อาจเหมาะกับงานที่ต้องรวมศูนย์หรือใช้ทรัพยากรนอกอุปกรณ์ผู้ใช้

ตารางเทียบความเร็ว ความซับซ้อน และต้นทุนดูแลรักษา

คำว่า “เร็วกว่า” ต้องแยกเป็นสองเรื่อง คือ main thread ว่างขึ้นหรือไม่ และเวลารวมของงานดีขึ้นหรือไม่ Web Workers อาจทำให้ UI ตอบสนองดีขึ้น แต่หากมีค่าใช้จ่ายในการส่งข้อความสูง งานรวมอาจไม่ได้เร็วขึ้นอย่างที่คาดไว้ จึงควรวัดทั้งช่วงก่อนส่งงาน ระหว่างประมวลผล และตอนรับผลกลับมา

workers pool เพิ่มความสามารถในการจัดการงานหลายรายการ แต่ต้องแลกกับโค้ดจัดคิว สถานะงาน การคืน Worker และการรับมือข้อผิดพลาด ทีมที่ดูแลเองควรประเมินเวลา implement และภาระบำรุงรักษาระยะยาว ควบคู่กับค่าใช้จ่ายของเครื่องมือ monitoring ที่ใช้ติดตามปัญหาในระบบจริง

เลือกตามปริมาณข้อมูล ความถี่ของงาน และอุปกรณ์ผู้ใช้

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

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

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

ขั้นตอนแยกงาน JavaScript ให้ทำงานขนานอย่างปลอดภัย

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

ระบุ bottleneck ด้วย Performance profiling

เริ่มเก็บข้อมูลจาก performance profiling ในสถานการณ์ที่ใกล้เคียงการใช้งานจริง ดูว่าเวลาส่วนใหญ่ถูกใช้กับฟังก์ชันคำนวณ การจัดการข้อมูล การ render หรือการรอเครือข่าย จากนั้นเลือกเฉพาะส่วนที่เป็นงานคำนวณหนักและแยกขอบเขตได้ชัดเจน

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

ออกแบบ message passing และข้อมูลที่ส่งระหว่างเธรด

Worker ติดต่อกับหน้าเว็บผ่านการส่งข้อความ ดังนั้นควรออกแบบ message ให้มีหน้าที่ชัดเจน เช่น เริ่มงาน ส่งความคืบหน้า ส่งผลลัพธ์ แจ้งข้อผิดพลาด หรือยกเลิกงาน หลีกเลี่ยงการส่ง state ทั้งก้อนทุกครั้งที่มีการเปลี่ยนแปลงเล็กน้อย

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

ใช้ workers pool เพื่อควบคุมจำนวนงานพร้อมกัน

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

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

ข้อผิดพลาดที่ทำให้ใช้ Worker แล้วช้าลง

Worker ไม่ใช่ปุ่มเพิ่มความเร็วอัตโนมัติ จุดที่พลาดบ่อยเกิดจาก overhead ของการสร้าง Worker การส่งข้อมูล และการขาดการจัดการวงจรชีวิตของงาน

สร้าง Worker บ่อยเกินไปและส่ง payload ใหญ่เกินจำเป็น

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

อย่ามองเฉพาะเวลา compute ใน Worker ต้องดูเวลาตั้งแต่ส่งข้อมูลไปจนรับผลลัพธ์กลับด้วย การทำ profiling ของเส้นทางทั้งหมดช่วยให้เห็นว่าควรปรับโค้ด ลดข้อมูล หรือเปลี่ยนสถาปัตยกรรมไปฝั่งเซิร์ฟเวอร์

คาดหวังให้ Worker แก้ปัญหา DOM และ UI โดยตรง

Worker ไม่เข้าถึง DOM โดยตรง จึงไม่สามารถรับหน้าที่อัปเดตปุ่ม ตาราง หรือกราฟแทน main thread ได้โดยตรง หน้าหลักยังต้องรับผลลัพธ์และจัดการ UI เอง การออกแบบที่เหมาะสมคือให้ Worker ทำเฉพาะงานคำนวณ แล้วส่งข้อมูลผลลัพธ์กลับมาในรูปแบบที่อัปเดตหน้าจอได้อย่างมีประสิทธิภาพ

ไม่จัดการ fallback, error และการยกเลิกงาน

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

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

แนวทางตามประเภทเว็บไซต์และงบประมาณทีม

การลงทุนควรเริ่มจากผลกระทบต่อผู้ใช้และความพร้อมของทีม ไม่ใช่เลือกสถาปัตยกรรมที่ซับซ้อนที่สุด ทีมขนาดเล็กอาจได้ผลมากจากการแก้ bottleneck จุดเดียว ขณะที่ระบบซับซ้อนอาจต้องประเมินทั้งโค้ด เครื่องมือ monitoring และโครงสร้างพื้นฐานร่วมกัน

เว็บคอนเทนต์หรือร้านค้าออนไลน์ที่ต้องรักษา UX บนมือถือ

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

เริ่มจาก profiling หน้าและขั้นตอนที่ผู้ใช้ใช้งานจริงก่อน ถ้าปัญหาอยู่ที่ทรัพยากรจากเครือข่ายหรือฝั่งระบบหลังบ้าน การใช้ Worker อย่างเดียวอาจไม่ตอบโจทย์ ต้องแยกสาเหตุให้ชัดก่อนเพิ่มค่าใช้จ่ายด้าน cloud หรือบริการวัดประสิทธิภาพ

แดชบอร์ดและระบบ B2B ที่มีการคำนวณหรือกราฟข้อมูลหนัก

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

หากมีคำขอจำนวนมากหรือผู้ใช้เปลี่ยนเงื่อนไขติดต่อกัน ให้มีการยกเลิกงานเก่าที่ไม่จำเป็น และจัดลำดับงานใน pool อย่างชัดเจน สำหรับองค์กรที่มีระบบหลายส่วน การขอประเมินจากผู้เชี่ยวชาญด้าน Web Performance อาจช่วยตรวจจุดเชื่อมระหว่าง frontend, monitoring และ backend ได้ แต่ควรกำหนดขอบเขตงานและข้อมูลที่ต้องการให้ชัดก่อน

ระบบแปลงไฟล์หรือวิเคราะห์ข้อมูลที่ควรเปรียบเทียบกับ cloud/server

ระบบแปลงไฟล์ วิเคราะห์ข้อมูล หรือเข้ารหัสควรเปรียบเทียบสองทางเลือกอย่างจริงจัง คือทำบนอุปกรณ์ผู้ใช้ด้วย Worker หรือส่งไปประมวลผลบน server/cloud ฝั่งผู้ใช้ช่วยลดภาระการคำนวณบนเซิร์ฟเวอร์ในบางกรณี แต่ต้องคำนึงถึงอุปกรณ์และเบราว์เซอร์ที่หลากหลาย

ส่วนฝั่งเซิร์ฟเวอร์ช่วยรวมศูนย์การประมวลผลและควบคุมทรัพยากรได้ตามรูปแบบระบบ แต่มีต้นทุนโครงสร้างพื้นฐาน การรับส่งข้อมูล และการติดตามประสิทธิภาพที่ต้องประเมิน ค่าใช้จ่ายจริงของ cloud, CDN, server หรือผู้รับจ้างพัฒนาแตกต่างตามผู้ให้บริการและขอบเขตงาน จึงควรขอรายละเอียดเงื่อนไขก่อนเลือก

เกณฑ์เลือกและสรุปเปรียบเทียบก่อนลงทุน

ก่อนตัดสินใจ ให้ตรวจสอบ ตำแหน่งของ bottleneck ว่าอยู่ที่ main thread, การส่งข้อมูล, เครือข่าย หรือเซิร์ฟเวอร์ ตรวจสอบ ชนิดและขนาดของข้อมูล ที่ต้องส่งระหว่างเธรด ตรวจสอบ ความถี่และจำนวนงานพร้อมกัน รวมถึงพฤติกรรมบนอุปกรณ์ผู้ใช้จริง

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

หากกำลังเลือกเครื่องมือ monitoring, บริการ cloud หรือผู้รับจ้างด้าน Web Performance ให้ตรวจสอบค่า profiling และขอบเขตงานก่อนเลือกเครื่องมือหรือผู้รับจ้าง โดยดูรายละเอียดเงื่อนไขและความสามารถบนหน้าข้อมูลอย่างเป็นทางการของแต่ละบริการ

สรุปท้ายบทความ

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

workers pool เหมาะกับงานหลายรายการที่ต้องควบคุมจำนวนการประมวลผลพร้อมกัน ขณะที่งานบางประเภทควรเปรียบเทียบกับ WebAssembly หรือการประมวลผลฝั่งเซิร์ฟเวอร์

วิธีที่ปลอดภัยที่สุดคือเริ่มจาก profiling ออกแบบการส่งข้อมูลอย่างประหยัด และวัดผลก่อนสรุปว่าการลงทุนด้านโค้ด เครื่องมือ หรือโครงสร้างพื้นฐานคุ้มค่าหรือไม่

ข้อมูลที่ควรรู้เพิ่มเติม

1. Worker ทำงานแยกจาก main thread แต่ต้องส่งข้อความเพื่อรับงานและคืนผลลัพธ์

2. Worker ไม่สามารถเข้าถึง DOM โดยตรง งานอัปเดต UI ยังต้องจัดการบนหน้าหลัก

3. Transferable objects อาจช่วยลดต้นทุนการคัดลอกข้อมูลบางชนิดได้เมื่อเหมาะกับ flow ของระบบ

4. การสร้าง Worker มากเกินความจำเป็นอาจเพิ่ม overhead แทนที่จะทำให้ระบบเร็วขึ้น

ข้อควรตรวจสอบสำคัญ

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

คำถามที่พบบ่อย

Q1. Web Workers ช่วยให้เว็บไซต์โหลดเร็วขึ้นทุกกรณีหรือไม่?

A1. ไม่เสมอไป Web Workers ช่วยแยกงาน JavaScript ที่หนักออกจาก main thread ได้ แต่ยังมีต้นทุนการส่งข้อความและการส่งข้อมูลระหว่างเธรด หากปัญหาอยู่ที่เครือข่าย เซิร์ฟเวอร์ หรือทรัพยากรอื่น การใช้ Worker อาจไม่แก้ปัญหาตรงจุด ควรวัดผลด้วย performance profiling ก่อนและหลังปรับ

Q2. ควรสร้าง Worker กี่ตัวสำหรับงาน JavaScript ที่คำนวณหนัก?

A2. ไม่มีจำนวนตายตัว เพราะขึ้นกับชนิดงาน สเปกอุปกรณ์ผู้ใช้ จำนวนคอร์ ข้อจำกัดของเบราว์เซอร์ และจำนวนงานจริง การสร้างมากเกินไปอาจเพิ่ม overhead ได้ ควรทดสอบกับข้อมูลและอุปกรณ์ที่ใกล้เคียงผู้ใช้จริง และใช้ workers pool หากมีงานต่อเนื่องหลายรายการ

Q3. ระหว่างปรับ Web Workers กับเพิ่มสเปกเซิร์ฟเวอร์ แบบไหนคุ้มกว่าสำหรับระบบองค์กร?

A3. ขึ้นกับตำแหน่งของคอขวด หาก main thread ฝั่งผู้ใช้ติดงานคำนวณ การปรับด้วย Web Workers อาจตรงปัญหากว่า แต่ถ้างานควรประมวลผลรวมศูนย์หรือมีข้อจำกัดด้านอุปกรณ์ผู้ใช้ การเพิ่มทรัพยากรฝั่งเซิร์ฟเวอร์หรือใช้ cloud อาจเหมาะกว่า ควรเทียบเวลาและต้นทุนของทีมภายใน ค่าเครื่องมือ monitoring ค่าโครงสร้างพื้นฐาน และผลจาก profiling ก่อนเลือกแนวทาง