ภาพรวมผู้ปฏิบัติงาน

วิธีที่ Web Work และ Service Worker สามารถปรับปรุงประสิทธิภาพของเว็บไซต์ และเวลาที่ควรใช้ Web Worker เทียบกับ Service Worker

Andrew Guan

Demián Renzulli

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

พนักงานจะปรับปรุงเว็บไซต์ของคุณได้อย่างไร

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

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

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

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

ในโพสต์นี้ คุณจะได้เรียนรู้เกี่ยวกับผู้ปฏิบัติงาน 2 ประเภท (Web Worker และ Service Worker) ความเหมือนและความแตกต่าง และรูปแบบที่พบบ่อยที่สุดในการใช้ในเว็บไซต์ที่ใช้งานจริง

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 จะยังทำงานต่อได้ในพื้นหลัง แม้ว่าเว็บไซต์จะไม่ได้เปิดแท็บที่ใช้งานอยู่ไว้เลยก็ตาม

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

Use Case

ข้อแตกต่างระหว่างผู้ปฏิบัติงานทั้ง 2 ประเภทช่วยชี้ให้เห็นว่าบุคคลใดที่อาจต้องการใช้สถานการณ์ใดสถานการณ์หนึ่ง ดังนี้

กรณีการใช้งานสำหรับผู้ปฏิบัติงานบนเว็บมักเกี่ยวข้องกับการลดภาระงาน (เช่น การประมวลผลหนัก) ไปยังเทรดรอง เพื่อหลีกเลี่ยงการบล็อก UI

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

งาน Service Worker มักเกี่ยวข้องกับการทำหน้าที่เป็นพร็อกซีเครือข่าย การจัดการงานในเบื้องหลัง และงานอื่นๆ เช่น การแคชและออฟไลน์

ตัวอย่าง: ใน PWA ของพอดแคสต์ คุณอาจต้องอนุญาตให้ผู้ใช้ดาวน์โหลดตอนทั้งหมดไว้ฟังขณะออฟไลน์ โปรแกรมทำงานของบริการ (Service Worker) โดยเฉพาะอย่างยิ่ง Background Fetch API สามารถใช้ในจุดนั้นได้ ด้วยวิธีนี้ หากผู้ใช้ปิดแท็บขณะกำลังดาวน์โหลดตอน งานจะไม่ถูกขัดจังหวะ

ระบบจะอัปเดต UI เพื่อระบุความคืบหน้าของการดาวน์โหลด (ซ้าย) ด้วยโปรแกรมทำงานของบริการ การดำเนินการเหล่านี้จะยังคงทำงานต่อไปเมื่อปิดแท็บทั้งหมดแล้ว (ขวา)

เครื่องมือและห้องสมุด

คุณสามารถนำการสื่อสารในหน้าต่างและผู้ปฏิบัติงานได้โดยใช้ API ระดับต่ำลงมา โชคดีที่มีไลบรารีที่แยกกระบวนการดังกล่าว และพิจารณากรณีการใช้งานที่พบบ่อยที่สุด ในส่วนนี้ เราจะกล่าวถึงเครื่องมือ 2 ประเภทที่ดูแล Windows Worker สำหรับ Web Work และ Service Worker ตามลำดับ ได้แก่ Comlink และWorkbox

ลิงก์คอมลิงก์

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 ออกจากเทรดหลักของเบราว์เซอร์