วิธีที่ Web Work และ Service Worker สามารถปรับปรุงประสิทธิภาพของเว็บไซต์ และเวลาที่ควรใช้ Web Worker เทียบกับ Service Worker
ภาพรวมนี้จะอธิบายว่า Web Worker และ Service Worker สามารถปรับปรุงประสิทธิภาพของเว็บไซต์อย่างไร และเมื่อใดที่ควรใช้ Web Worker เมื่อเทียบกับ Service Worker ลองดูวิดีโอที่เหลือของซีรีส์นี้เพื่อดูรูปแบบเฉพาะของการสื่อสารระหว่างหน้าต่างและ Service Worker
พนักงานจะปรับปรุงเว็บไซต์ของคุณได้อย่างไร
เบราว์เซอร์จะใช้เทรดเดียว (เทรดหลัก) เพื่อเรียกใช้ JavaScript ทั้งหมดในหน้าเว็บ รวมถึงทำงานต่างๆ เช่น แสดงผลหน้าเว็บและดำเนินการรวบรวมขยะ การเรียกใช้โค้ด JavaScript มากเกินไปอาจบล็อกเทรดหลัก ทำให้เบราว์เซอร์ทำงานเหล่านี้ล่าช้าและทำให้ผู้ใช้ได้รับประสบการณ์ที่ไม่ดี
ในการพัฒนาแอปพลิเคชัน iOS/Android รูปแบบทั่วไปที่ช่วยให้เทรดหลักของแอปยังคงตอบสนองต่อเหตุการณ์ของผู้ใช้ได้อย่างอิสระคือการลดการดำเนินการไปยังเทรดเพิ่มเติม อันที่จริง ใน Android เวอร์ชันล่าสุด การบล็อกเทรดหลักนานเกินไปทำให้แอปขัดข้อง
บนเว็บ JavaScript นั้นออกแบบจากแนวคิดของเทรดเดียว และขาดความสามารถที่จำเป็นต่อการใช้งานโมเดลชุดข้อความแบบมัลติเทรดอย่างที่แอปมี เช่น หน่วยความจำที่แชร์
แม้จะมีข้อจำกัดเหล่านี้ แต่รูปแบบที่คล้ายกันก็สร้างขึ้นในเว็บได้ด้วยการใช้สคริปต์เพื่อเรียกใช้สคริปต์ในเทรดเบื้องหลัง ซึ่งช่วยให้ทำงานต่างๆ ได้โดยไม่ต้องรบกวนเทรดหลัก ผู้ปฏิบัติงานเป็นขอบเขต JavaScript ทั้งหมดที่ทำงานในเทรดแยกต่างหากโดยไม่มีหน่วยความจำที่ใช้ร่วมกัน
ในโพสต์นี้ คุณจะได้เรียนรู้เกี่ยวกับผู้ปฏิบัติงาน 2 ประเภท (Web Worker และ Service Worker) ความเหมือนและความแตกต่าง และรูปแบบที่พบบ่อยที่สุดในการใช้ในเว็บไซต์ที่ใช้งานจริง
![แผนภาพแสดงลิงก์ 2 รายการระหว่างออบเจ็กต์ Window กับ Web Worker กับ Service Worker](https://web.dev/static/articles/workers-overview/image/diagram-showing-links-be-3f8d21126eb87.png?authuser=6&hl=th)
Web Worker และ Service Worker
ความคล้ายคลึง
โปรแกรมทำงานบนเว็บและโปรแกรมทำงานของบริการ เป็นผู้ปฏิบัติงาน 2 ประเภทที่พร้อมให้บริการสำหรับเว็บไซต์ สิ่งที่เหมือนกันก็คือ
- ทั้งคู่จะทำงานในเทรดรอง ซึ่งช่วยให้โค้ด JavaScript ทำงานได้โดยไม่ต้องบล็อกเทรดหลักและอินเทอร์เฟซผู้ใช้
- แต่ไม่มีสิทธิ์เข้าถึงออบเจ็กต์
Window
และDocument
จึงไม่สามารถโต้ตอบกับ DOM โดยตรง และมีสิทธิ์เข้าถึง API ของเบราว์เซอร์แบบจำกัด
ความแตกต่าง
บางคนอาจคิดว่าสิ่งส่วนใหญ่ที่มอบสิทธิ์ให้กับ Web Worker ได้นั้นอาจทำใน Service Worker ส่วน Service Worker ก็ได้เช่นกัน แต่สิ่งเหล่านั้นมีข้อแตกต่างสำคัญดังนี้
- Service Worker ต่างจาก Web Worker ตรงที่ให้คุณสกัดกั้นคำขอของเครือข่าย (ผ่านเหตุการณ์
fetch
) และรอรับเหตุการณ์ Push API ในเบื้องหลัง (ผ่านเหตุการณ์push
) - หน้าเว็บอาจสร้าง Web Work ขึ้นมาได้หลายคน แต่ Service Worker 1 ตัวจะควบคุมแท็บที่ใช้งานอยู่ทั้งหมดภายใต้ขอบเขตที่ลงทะเบียนไว้
- อายุการใช้งานของ Web Worker นั้นเชื่อมโยงกับแท็บที่เป็นอยู่เป็นอย่างดี ในขณะที่วงจรการทำงานของบริการจะไม่เกี่ยวข้องกับแท็บ ด้วยเหตุนี้ การปิดแท็บที่ Web Worker ทำงานอยู่จะเป็นการสิ้นสุดแท็บนั้น ขณะที่ Service Worker จะยังทำงานต่อได้ในพื้นหลัง แม้ว่าเว็บไซต์จะไม่ได้เปิดแท็บที่ใช้งานอยู่ไว้เลยก็ตาม
Use Case
ข้อแตกต่างระหว่างผู้ปฏิบัติงานทั้ง 2 ประเภทช่วยชี้ให้เห็นว่าบุคคลใดที่อาจต้องการใช้สถานการณ์ใดสถานการณ์หนึ่ง ดังนี้
กรณีการใช้งานสำหรับผู้ปฏิบัติงานบนเว็บมักเกี่ยวข้องกับการลดภาระงาน (เช่น การประมวลผลหนัก) ไปยังเทรดรอง เพื่อหลีกเลี่ยงการบล็อก UI
![แผนภาพที่แสดงลิงก์จากออบเจ็กต์ Window ไปยัง Web Worker](https://web.dev/static/articles/workers-overview/image/diagram-showing-link-th-27e9ed5676ba6.png?authuser=6&hl=th)
- ตัวอย่าง: ทีมที่สร้างวิดีโอเกม PROXX ต้องการปล่อยให้ชุดข้อความหลักใช้งานได้ฟรีที่สุดเพื่อดูแลการป้อนข้อมูลและภาพเคลื่อนไหวของผู้ใช้ ด้วยเหตุนี้ ทางทีมจึงใช้ Web Worker เพื่อเรียกใช้ตรรกะของเกมและการบำรุงรักษาสถานะในเทรดที่แยกต่างหาก
![ภาพหน้าจอของวิดีโอเกม PROXX](https://web.dev/static/articles/workers-overview/image/a-screenshot-the-videoga-d7cb8cb8a682c.png?authuser=6&hl=th)
งาน Service Worker มักเกี่ยวข้องกับการทำหน้าที่เป็นพร็อกซีเครือข่าย การจัดการงานในเบื้องหลัง และงานอื่นๆ เช่น การแคชและออฟไลน์
![ภาพหน้าจอของวิดีโอเกม PROXX](https://web.dev/static/articles/workers-overview/image/a-screenshot-the-videoga-e3257857d928d.png?authuser=6&hl=th)
ตัวอย่าง: ใน PWA ของพอดแคสต์ คุณอาจต้องอนุญาตให้ผู้ใช้ดาวน์โหลดตอนทั้งหมดไว้ฟังขณะออฟไลน์ โปรแกรมทำงานของบริการ (Service Worker) โดยเฉพาะอย่างยิ่ง Background Fetch API สามารถใช้ในจุดนั้นได้ ด้วยวิธีนี้ หากผู้ใช้ปิดแท็บขณะกำลังดาวน์โหลดตอน งานจะไม่ถูกขัดจังหวะ
![ภาพหน้าจอของ PWA สำหรับพอดแคสต์](https://web.dev/static/articles/workers-overview/image/a-screenshot-a-podcast-p-910200b097c52.png?authuser=6&hl=th)
เครื่องมือและห้องสมุด
คุณสามารถนำการสื่อสารในหน้าต่างและผู้ปฏิบัติงานได้โดยใช้ API ระดับต่ำลงมา โชคดีที่มีไลบรารีที่แยกกระบวนการดังกล่าว และพิจารณากรณีการใช้งานที่พบบ่อยที่สุด ในส่วนนี้ เราจะกล่าวถึงเครื่องมือ 2 ประเภทที่ดูแล Windows Worker สำหรับ Web Work และ Service Worker ตามลำดับ ได้แก่ Comlink และWorkbox
![ภาพหน้าจอของวิดีโอเกม PROXX](https://web.dev/static/articles/workers-overview/image/a-screenshot-the-videoga-1d6073255f591.png?authuser=6&hl=th)
ลิงก์คอมลิงก์
Comlink เป็นไลบรารี RPC ขนาดเล็ก (1.6 พันครั้ง) ที่ดูแลรายละเอียดมากมายเมื่อสร้างเว็บไซต์ที่ใช้ Web Workers ซึ่งมีการใช้ในเว็บไซต์อย่าง PROXX และ Squoosh สรุปแรงจูงใจและตัวอย่างโค้ดได้ที่นี่
Workbox
Workbox เป็นไลบรารียอดนิยมสำหรับการสร้างเว็บไซต์ที่ใช้ Service Worker โดยเป็นการรวมชุดแนวทางปฏิบัติแนะนำเกี่ยวกับสิ่งต่างๆ เช่น การแคช การออฟไลน์ การซิงค์ในเบื้องหลัง เป็นต้น โมดูล workbox-window
มอบวิธีที่สะดวกสบายในการแลกเปลี่ยนข้อความระหว่างโปรแกรมทำงานของบริการกับหน้าเว็บ
ขั้นตอนถัดไป
เนื้อหาที่เหลือของซีรีส์นี้มุ่งเน้นที่รูปแบบการสื่อสารระหว่างหน้าต่างและบริการสำหรับผู้ปฏิบัติงาน
- คำแนะนำในการแคชที่จำเป็น: การเรียกใช้ Service Worker จากหน้าเว็บเพื่อแคชทรัพยากรล่วงหน้า (เช่น ในสถานการณ์การดึงข้อมูลล่วงหน้า)
- อัปเดตการประกาศ: การเรียกใช้หน้าเว็บจาก Service Worker เพื่อแจ้งการอัปเดตที่สำคัญ (เช่น เว็บไซต์เวอร์ชันใหม่พร้อมใช้งานแล้ว)
- การสื่อสารแบบ 2 ทาง: การมอบหมายงานให้กับ Service Worker (เช่น การดาวน์โหลดจำนวนมาก) และการแจ้งความคืบหน้าในหน้าเว็บ
โปรดดูรูปแบบการสื่อสารของ Windows และ Web Worker ที่หัวข้อใช้ Web Worker เพื่อเรียกใช้ JavaScript ออกจากเทรดหลักของเบราว์เซอร์