สำรวจผลกระทบด้านประสิทธิภาพของการใช้ Frontend Presentation API สำหรับแอปพลิเคชันหลายหน้าจอ โดยเน้นที่การจัดการโอเวอร์เฮดและกลยุทธ์การเพิ่มประสิทธิภาพสำหรับผู้ใช้งานทั่วโลก
ผลกระทบต่อประสิทธิภาพของ Frontend Presentation API: โอเวอร์เฮดในการประมวลผลหลายหน้าจอ
Frontend Presentation API เป็นเครื่องมือที่ทรงพลังในการขยายเว็บแอปพลิเคชันไปยังหลายหน้าจอ ความสามารถนี้เปิดประตูสู่ประสบการณ์ผู้ใช้รูปแบบใหม่ๆ เช่น การนำเสนอแบบโต้ตอบ แดชบอร์ดสำหรับการทำงานร่วมกัน และสถานการณ์การเล่นเกมที่ดียิ่งขึ้น อย่างไรก็ตาม การใช้ Presentation API อย่างมีประสิทธิภาพจำเป็นต้องพิจารณาถึงผลกระทบด้านประสิทธิภาพอย่างรอบคอบ โดยเฉพาะอย่างยิ่งเกี่ยวกับโอเวอร์เฮดในการประมวลผลหลายหน้าจอ บทความนี้จะเจาะลึกถึงความท้าทายด้านประสิทธิภาพที่เกี่ยวข้องกับแอปพลิเคชันหลายหน้าจอที่สร้างขึ้นโดยใช้ Presentation API พร้อมเสนอแนวทางปฏิบัติสำหรับการเพิ่มประสิทธิภาพและแนวทางปฏิบัติที่ดีที่สุดสำหรับนักพัฒนาทั่วโลก
ทำความเข้าใจ Frontend Presentation API
Presentation API ช่วยให้เว็บแอปพลิเคชันสามารถควบคุมการนำเสนอบนหน้าจอที่สองได้ เช่น โปรเจคเตอร์ จอภาพภายนอก หรือสมาร์ททีวี โดยประกอบด้วยสองส่วนหลัก:
- คำขอการนำเสนอ (Presentation Request): เริ่มต้นการร้องขอหน้าจอสำหรับการนำเสนอ
- การเชื่อมต่อการนำเสนอ (Presentation Connection): สร้างและจัดการการเชื่อมต่อระหว่างหน้าเว็บที่นำเสนอและหน้าจอการนำเสนอ
เมื่อการนำเสนอเริ่มต้นขึ้น เบราว์เซอร์จะจัดการการสื่อสารระหว่างหน้าจอหลักและหน้าจอรอง การสื่อสารนี้ก่อให้เกิดโอเวอร์เฮด ซึ่งอาจมีความสำคัญมากขึ้นเมื่อความซับซ้อนของการนำเสนอและจำนวนหน้าจอเพิ่มขึ้น
ผลกระทบด้านประสิทธิภาพของการประมวลผลหลายหน้าจอ
มีหลายปัจจัยที่ส่งผลต่อโอเวอร์เฮดด้านประสิทธิภาพที่เกี่ยวข้องกับการประมวลผลหลายหน้าจอโดยใช้ Presentation API:
1. โอเวอร์เฮดในการเชื่อมต่อ (Connection Overhead)
การสร้างและรักษาการเชื่อมต่อระหว่างหน้าหลักกับหน้าจอการนำเสนอนั้นทำให้เกิดความหน่วง (latency) ซึ่งรวมถึงเวลาที่ใช้ในการค้นหาจอแสดงผลที่พร้อมใช้งาน การเจรจาเพื่อเชื่อมต่อ และการซิงโครไนซ์ข้อมูลข้ามหน้าจอ ในสถานการณ์ที่มีจอแสดงผลหลายจอเชื่อมต่อกัน โอเวอร์เฮดนี้จะเพิ่มขึ้นเป็นทวีคูณ ซึ่งอาจนำไปสู่ความล่าช้าที่สังเกตได้
ตัวอย่าง: แอปพลิเคชันไวท์บอร์ดสำหรับการทำงานร่วมกันในการประชุมทีมระดับโลก การเชื่อมต่อกับหน้าจอของผู้เข้าร่วมหลายคนพร้อมกันอาจส่งผลให้เกิดความล่าช้าหากโอเวอร์เฮดการเชื่อมต่อไม่ได้รับการจัดการอย่างมีประสิทธิภาพ การเพิ่มประสิทธิภาพอาจรวมถึงการโหลดเนื้อหาแบบ lazy loading, การซิงค์เฉพาะข้อมูลที่จำเป็นต้องเปลี่ยนแปลง และการใช้รูปแบบการแปลงข้อมูล (serialization) ที่มีประสิทธิภาพ
2. โอเวอร์เฮดในการเรนเดอร์ (Rendering Overhead)
การเรนเดอร์เนื้อหาการนำเสนอบนหลายหน้าจอพร้อมกันต้องใช้พลังการประมวลผลอย่างมาก เบราว์เซอร์จำเป็นต้องจัดการไปป์ไลน์การเรนเดอร์สำหรับแต่ละจอแสดงผล ซึ่งเกี่ยวข้องกับการคำนวณเลย์เอาต์ การวาด (paint operations) และการผสมภาพ (compositing) หากเนื้อหาการนำเสนอมีความซับซ้อนหรือมีการอัปเดตบ่อยครั้ง โอเวอร์เฮดในการเรนเดอร์อาจกลายเป็นคอขวดได้
ตัวอย่าง: แดชบอร์ดแสดงภาพข้อมูลที่แสดงการวิเคราะห์แบบเรียลไทม์บนจอภาพหลายจอ การอัปเดตแผนภูมิและกราฟอย่างต่อเนื่องบนทุกหน้าจออาจทำให้ทรัพยากร CPU และ GPU ทำงานหนัก กลยุทธ์การเพิ่มประสิทธิภาพรวมถึงการใช้การเรนเดอร์บน canvas สำหรับกราฟิกที่ซับซ้อน, การใช้ requestAnimationFrame เพื่อให้แอนิเมชันราบรื่น และการจำกัดความถี่ในการอัปเดต (throttling) ให้อยู่ในระดับที่เหมาะสม
3. โอเวอร์เฮดในการสื่อสาร (Communication Overhead)
การแลกเปลี่ยนข้อมูลระหว่างหน้าหลักและหน้าจอการนำเสนอเพิ่มโอเวอร์เฮดในการสื่อสาร โอเวอร์เฮดนี้รวมถึงเวลาที่ใช้ในการแปลงข้อมูล (serialize), ส่งข้อมูลผ่านการเชื่อมต่อ และแปลงข้อมูลกลับ (deserialize) ที่ฝั่งรับ การลดปริมาณข้อมูลที่ถ่ายโอนและเพิ่มประสิทธิภาพโปรโตคอลการสื่อสารเป็นสิ่งสำคัญในการลดโอเวอร์เฮดนี้
ตัวอย่าง: แอปพลิเคชันเกมแบบโต้ตอบที่ต้องซิงโครไนซ์สถานะของเกมข้ามหน้าจอผู้เล่นหลายคน การส่งสถานะเกมทั้งหมดทุกครั้งที่มีการอัปเดตอาจไม่มีประสิทธิภาพ การเพิ่มประสิทธิภาพเกี่ยวข้องกับการส่งเฉพาะการเปลี่ยนแปลง (deltas) ในสถานะของเกม, การใช้โปรโตคอลแบบไบนารีสำหรับการแปลงข้อมูล และการใช้เทคนิคการบีบอัดเพื่อลดขนาดข้อมูล
4. โอเวอร์เฮดของหน่วยความจำ (Memory Overhead)
แต่ละหน้าจอการนำเสนอต้องการทรัพยากรของตัวเอง รวมถึงองค์ประกอบ DOM, พื้นผิว (textures) และทรัพย์สินอื่นๆ การจัดการทรัพยากรเหล่านี้อย่างมีประสิทธิภาพเป็นสิ่งจำเป็นเพื่อป้องกันการรั่วไหลของหน่วยความจำและการใช้หน่วยความจำที่มากเกินไป ในสถานการณ์ที่มีหน้าจอจำนวนมากหรือเนื้อหาการนำเสนอที่ซับซ้อน โอเวอร์เฮดของหน่วยความจำอาจกลายเป็นปัจจัยจำกัดได้
ตัวอย่าง: แอปพลิเคชันป้ายดิจิทัล (digital signage) ที่แสดงภาพและวิดีโอความละเอียดสูงบนจอแสดงผลหลายจอในห้างสรรพสินค้า แต่ละจอแสดงผลต้องการสำเนาของทรัพย์สิน ซึ่งอาจใช้หน่วยความจำจำนวนมาก กลยุทธ์การเพิ่มประสิทธิภาพรวมถึงการใช้เทคนิคการบีบอัดภาพและวิดีโอ, การใช้แคชสำหรับทรัพยากร และการใช้กลไกการเก็บขยะ (garbage collection) เพื่อปล่อยทรัพยากรที่ไม่ได้ใช้
5. โอเวอร์เฮดในการประมวลผล JavaScript (JavaScript Execution Overhead)
โค้ด JavaScript ที่ทำงานทั้งบนหน้าหลักและหน้าจอการนำเสนอมีส่วนทำให้เกิดโอเวอร์เฮดในการประมวลผลโดยรวม การลดเวลาการทำงานของฟังก์ชัน JavaScript, การหลีกเลี่ยงการคำนวณที่ไม่จำเป็น และการปรับปรุงโค้ดเพื่อประสิทธิภาพเป็นสิ่งสำคัญในการลดโอเวอร์เฮดนี้
ตัวอย่าง: แอปพลิเคชันสไลด์โชว์ที่มีการเปลี่ยนภาพและแอนิเมชันที่ซับซ้อนซึ่งสร้างด้วย JavaScript โค้ด JavaScript ที่ไม่มีประสิทธิภาพอาจทำให้สไลด์โชว์กระตุกหรือค้าง โดยเฉพาะบนอุปกรณ์ที่มีกำลังประมวลผลต่ำ การเพิ่มประสิทธิภาพรวมถึงการใช้ไลบรารีแอนิเมชันที่ปรับให้เหมาะสม, การหลีกเลี่ยงการดำเนินการที่บล็อกเธรดหลัก และการทำโปรไฟล์โค้ดเพื่อระบุคอขวดด้านประสิทธิภาพ
กลยุทธ์การเพิ่มประสิทธิภาพสำหรับแอปพลิเคชันหลายหน้าจอ
เพื่อลดผลกระทบด้านประสิทธิภาพของการประมวลผลหลายหน้าจอ ให้พิจารณากลยุทธ์การเพิ่มประสิทธิภาพต่อไปนี้:
1. เพิ่มประสิทธิภาพการจัดการการเชื่อมต่อ
- สร้างการเชื่อมต่อแบบ Lazy: ชะลอการสร้างการเชื่อมต่อไปยังหน้าจอการนำเสนอจนกว่าจะมีความจำเป็นต้องใช้จริงๆ
- นำการเชื่อมต่อที่มีอยู่กลับมาใช้ใหม่: นำการเชื่อมต่อที่มีอยู่กลับมาใช้ใหม่ทุกครั้งที่เป็นไปได้ แทนที่จะสร้างการเชื่อมต่อใหม่
- ลดเวลาในการเชื่อมต่อ: ลดเวลาที่ใช้ในการสร้างการเชื่อมต่อโดยการปรับปรุงกระบวนการค้นหาและเจรจา
ตัวอย่าง: แทนที่จะเชื่อมต่อกับหน้าจอการนำเสนอที่มีอยู่ทั้งหมดเมื่อแอปพลิเคชันเริ่มทำงาน ให้เชื่อมต่อเฉพาะหน้าจอที่ผู้ใช้เลือก หากผู้ใช้เปลี่ยนไปใช้หน้าจออื่น ให้นำการเชื่อมต่อที่มีอยู่กลับมาใช้ใหม่หากเป็นไปได้ หรือสร้างการเชื่อมต่อใหม่เมื่อจำเป็นเท่านั้น
2. เพิ่มประสิทธิภาพการเรนเดอร์
- ใช้การเร่งความเร็วด้วยฮาร์ดแวร์: ใช้ประโยชน์จากการเร่งความเร็วด้วยฮาร์ดแวร์สำหรับการเรนเดอร์ทุกครั้งที่เป็นไปได้
- ลดการจัดการ DOM: ลดการจัดการ DOM โดยใช้เทคนิคต่างๆ เช่น virtual DOM หรือ shadow DOM
- ปรับปรุงทรัพย์สินภาพและวิดีโอ: ใช้รูปแบบภาพและวิดีโอที่บีบอัดและปรับความละเอียดให้เหมาะสมกับจอแสดงผลเป้าหมาย
- ใช้แคช: แคชทรัพย์สินที่ใช้บ่อยเพื่อลดความจำเป็นในการดาวน์โหลดซ้ำ
ตัวอย่าง: ใช้ CSS transforms และ transitions แทนแอนิเมชันที่ใช้ JavaScript เพื่อใช้ประโยชน์จากการเร่งความเร็วด้วยฮาร์ดแวร์ ใช้รูปแบบภาพ WebP หรือ AVIF เพื่อการบีบอัดที่ดีขึ้นและขนาดไฟล์ที่เล็กลง ใช้ service worker เพื่อแคชทรัพย์สินคงที่และลดการร้องขอเครือข่าย
3. เพิ่มประสิทธิภาพโปรโตคอลการสื่อสาร
- ลดการถ่ายโอนข้อมูล: ส่งเฉพาะข้อมูลที่จำเป็นระหว่างหน้าหลักและหน้าจอการนำเสนอ
- ใช้โปรโตคอลแบบไบนารี: ใช้โปรโตคอลแบบไบนารีเช่น Protocol Buffers หรือ MessagePack เพื่อการแปลงข้อมูลที่มีประสิทธิภาพ
- ใช้การบีบอัด: บีบอัดข้อมูลก่อนส่งเพื่อลดขนาด
- รวมการอัปเดตข้อมูลเป็นชุด: รวมการอัปเดตข้อมูลหลายรายการเป็นข้อความเดียวเพื่อลดจำนวนข้อความที่ส่ง
ตัวอย่าง: แทนที่จะส่งสถานะทั้งหมดของคอมโพเนนต์ UI ทุกครั้งที่มีการอัปเดต ให้ส่งเฉพาะการเปลี่ยนแปลง (deltas) ในสถานะ ใช้การบีบอัด gzip หรือ Brotli เพื่อลดขนาดของข้อมูลที่ส่งผ่านเครือข่าย รวมการอัปเดต UI หลายรายการไว้ใน callback ของ requestAnimationFrame เดียวเพื่อลดจำนวนการอัปเดตการเรนเดอร์
4. เพิ่มประสิทธิภาพการจัดการหน่วยความจำ
- ปล่อยทรัพยากรที่ไม่ได้ใช้: ปล่อยทรัพยากรที่ไม่ได้ใช้อย่างรวดเร็วเพื่อป้องกันการรั่วไหลของหน่วยความจำ
- ใช้ Object Pooling: ใช้ object pooling เพื่อนำอ็อบเจกต์กลับมาใช้ใหม่แทนที่จะสร้างใหม่
- ใช้กลไก Garbage Collection: ใช้กลไกการเก็บขยะเพื่อเรียกคืนหน่วยความจำที่ถูกครอบครองโดยอ็อบเจกต์ที่ไม่ได้ใช้
- ตรวจสอบการใช้หน่วยความจำ: ตรวจสอบการใช้หน่วยความจำเพื่อระบุการรั่วไหลของหน่วยความจำที่อาจเกิดขึ้นและการใช้หน่วยความจำที่มากเกินไป
ตัวอย่าง: ใช้เมธอด `URL.revokeObjectURL()` เพื่อปล่อยหน่วยความจำที่ถูกครอบครองโดย Blob URLs สร้าง object pool แบบง่ายเพื่อนำอ็อบเจกต์ที่สร้างบ่อยกลับมาใช้ใหม่ เช่น อ็อบเจกต์อนุภาคในระบบอนุภาค ใช้เครื่องมือโปรไฟล์หน่วยความจำของเบราว์เซอร์เพื่อระบุและแก้ไขการรั่วไหลของหน่วยความจำในแอปพลิเคชันของคุณ
5. เพิ่มประสิทธิภาพโค้ด JavaScript
- หลีกเลี่ยงการดำเนินการที่บล็อก: หลีกเลี่ยงการดำเนินการที่บล็อกในเธรดหลักเพื่อป้องกันไม่ให้ UI ค้าง
- ใช้ Web Workers: มอบหมายงานที่ต้องใช้การคำนวณมากให้กับ web workers เพื่อป้องกันการบล็อกเธรดหลัก
- ปรับปรุงอัลกอริทึม: ใช้อัลกอริทึมและโครงสร้างข้อมูลที่มีประสิทธิภาพเพื่อลดเวลาการทำงานของฟังก์ชัน JavaScript
- ทำโปรไฟล์โค้ด: ทำโปรไฟล์โค้ดของคุณเพื่อระบุคอขวดด้านประสิทธิภาพและปรับปรุง
ตัวอย่าง: ใช้ `setTimeout` หรือ `requestAnimationFrame` เพื่อแบ่งงานที่ใช้เวลานานออกเป็นส่วนเล็กๆ ใช้ web workers เพื่อทำงานที่ต้องใช้การคำนวณมาก เช่น การประมวลผลภาพหรือการวิเคราะห์ข้อมูลในเบื้องหลัง ใช้เครื่องมือโปรไฟล์ประสิทธิภาพของเบราว์เซอร์เพื่อระบุและปรับปรุงฟังก์ชัน JavaScript ที่ช้า
แนวทางปฏิบัติที่ดีที่สุดสำหรับนักพัฒนาทั่วโลก
เมื่อพัฒนาแอปพลิเคชันหลายหน้าจอสำหรับผู้ใช้งานทั่วโลก ให้พิจารณาแนวทางปฏิบัติที่ดีที่สุดต่อไปนี้:
- ทดสอบบนอุปกรณ์ที่หลากหลาย: ทดสอบแอปพลิเคชันของคุณบนอุปกรณ์ที่หลากหลายซึ่งมีขนาดหน้าจอ ความละเอียด และพลังการประมวลผลที่แตกต่างกัน เพื่อให้แน่ใจว่ามีประสิทธิภาพสูงสุดในทุกสถานการณ์
- ปรับให้เหมาะกับการเชื่อมต่อแบนด์วิดท์ต่ำ: ปรับปรุงแอปพลิเคชันของคุณสำหรับการเชื่อมต่อแบนด์วิดท์ต่ำเพื่อให้ผู้ใช้ที่มีอินเทอร์เน็ตจำกัดได้รับประสบการณ์ที่ราบรื่น พิจารณาเทคนิคการสตรีมแบบปรับได้สำหรับเนื้อหาสื่อ
- พิจารณาการแปลเป็นภาษาท้องถิ่น (Localization): แปลส่วนติดต่อผู้ใช้ของแอปพลิเคชันเพื่อรองรับหลายภาษาและภูมิภาค ใช้ไลบรารีการทำให้เป็นสากล (i18n) เพื่อจัดการการแปลอย่างมีประสิทธิภาพ
- การเข้าถึงได้ (Accessibility): ออกแบบโดยคำนึงถึงการเข้าถึงได้เพื่อสนับสนุนผู้ใช้ที่มีความพิการ ใช้แอตทริบิวต์ ARIA และให้ข้อความทางเลือกสำหรับรูปภาพ
- ความเข้ากันได้ข้ามเบราว์เซอร์: ตรวจสอบให้แน่ใจว่าแอปพลิเคชันของคุณทำงานได้อย่างราบรื่นในเบราว์เซอร์และแพลตฟอร์มต่างๆ ใช้ feature detection หรือ polyfills เพื่อให้การสนับสนุนเบราว์เซอร์รุ่นเก่า
- การตรวจสอบประสิทธิภาพ: ใช้การตรวจสอบประสิทธิภาพเพื่อติดตามตัวชี้วัดสำคัญ เช่น เวลาในการโหลดหน้าเว็บ เวลาในการเรนเดอร์ และการใช้หน่วยความจำ ใช้เครื่องมือเช่น Google Analytics หรือ New Relic เพื่อรวบรวมและวิเคราะห์ข้อมูลประสิทธิภาพ
- เครือข่ายการจัดส่งเนื้อหา (CDN): ใช้เครือข่ายการจัดส่งเนื้อหา (CDN) เพื่อกระจายทรัพย์สินของแอปพลิเคชันของคุณไปยังเซิร์ฟเวอร์หลายแห่งทั่วโลก ซึ่งจะช่วยลดความหน่วงและปรับปรุงเวลาในการโหลดสำหรับผู้ใช้ในตำแหน่งทางภูมิศาสตร์ต่างๆ ได้อย่างมาก บริการเช่น Cloudflare, Amazon CloudFront และ Akamai เป็นที่นิยมใช้กันอย่างแพร่หลาย
- เลือกเฟรมเวิร์ก/ไลบรารีที่เหมาะสม: เลือกเฟรมเวิร์กหรือไลบรารีฟรอนต์เอนด์ที่ปรับให้เหมาะสมกับประสิทธิภาพและรองรับการพัฒนาหลายหน้าจอ React, Angular และ Vue.js เป็นตัวเลือกยอดนิยม ซึ่งแต่ละตัวมีจุดแข็งและจุดอ่อนของตัวเอง พิจารณาการนำ virtual DOM ไปใช้และความสามารถในการเรนเดอร์ของเฟรมเวิร์ก
- การปรับปรุงแบบก้าวหน้า (Progressive Enhancement): ใช้การปรับปรุงแบบก้าวหน้าเพื่อมอบประสบการณ์พื้นฐานสำหรับผู้ใช้ทุกคน โดยไม่คำนึงถึงความสามารถของเบราว์เซอร์หรือสภาพเครือข่าย ค่อยๆ ปรับปรุงประสบการณ์สำหรับผู้ใช้ที่มีเบราว์เซอร์ขั้นสูงและการเชื่อมต่อที่เร็วขึ้น
ตัวอย่างการใช้งานจริง
นี่คือตัวอย่างการใช้งานจริงของแอปพลิเคชันหลายหน้าจอและข้อควรพิจารณาด้านประสิทธิภาพที่เกี่ยวข้อง:
- การนำเสนอแบบโต้ตอบ: ผู้นำเสนอแสดงสไลด์บนโปรเจคเตอร์ในขณะที่ดูบันทึกและควบคุมการนำเสนอบนหน้าจอแล็ปท็อปของตนเอง
- ไวท์บอร์ดสำหรับการทำงานร่วมกัน: ผู้ใช้หลายคนวาดและทำงานร่วมกันบนไวท์บอร์ดที่ใช้ร่วมกันซึ่งแสดงบนหน้าจอขนาดใหญ่
- แอปพลิเคชันเกม: เกมจะแสดงผลข้ามหน้าจอหลายจอ ทำให้ได้รับประสบการณ์การเล่นเกมที่สมจริง
- ป้ายดิจิทัล (Digital Signage): ข้อมูลและโฆษณาจะแสดงบนหน้าจอหลายจอในที่สาธารณะ
- แพลตฟอร์มการซื้อขาย: ข้อมูลทางการเงินจะแสดงบนจอภาพหลายจอ ช่วยให้ผู้ค้าสามารถติดตามแนวโน้มของตลาดและดำเนินการซื้อขายได้อย่างมีประสิทธิภาพ พิจารณาการอัปเดตที่มีความหน่วงต่ำและการเรนเดอร์ที่ปรับให้เหมาะสมสำหรับข้อมูลแบบเรียลไทม์
สรุป
Frontend Presentation API มอบความเป็นไปได้ที่น่าตื่นเต้นสำหรับการสร้างแอปพลิเคชันหลายหน้าจอที่เป็นนวัตกรรมใหม่ อย่างไรก็ตาม สิ่งสำคัญคือต้องเข้าใจผลกระทบด้านประสิทธิภาพของการประมวลผลหลายหน้าจอและใช้กลยุทธ์การเพิ่มประสิทธิภาพที่เหมาะสม ด้วยการจัดการโอเวอร์เฮดในการเชื่อมต่อ, ประสิทธิภาพการเรนเดอร์, โปรโตคอลการสื่อสาร, การจัดการหน่วยความจำ และโค้ด JavaScript อย่างรอบคอบ นักพัฒนาสามารถสร้างแอปพลิเคชันหลายหน้าจอที่มีประสิทธิภาพสูงซึ่งมอบประสบการณ์ผู้ใช้ที่ราบรื่นสำหรับผู้ใช้งานทั่วโลก อย่าลืมทดสอบอย่างละเอียดบนอุปกรณ์และสภาพเครือข่ายที่หลากหลายเพื่อให้แน่ใจว่ามีประสิทธิภาพและการเข้าถึงที่ดีที่สุดสำหรับผู้ใช้ทุกคน ไม่ว่าพวกเขาจะอยู่ที่ไหนหรือมีความสามารถทางเทคนิคอย่างไร