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

วิธีที่ Web Worker และ 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 ได้รับการออกแบบตามแนวคิดของเทรดเดียว และขาดความสามารถที่จำเป็นในการใช้โมเดลแบบมัลติเทรดเหมือนกับที่แอปมี เช่น หน่วยความจำที่ใช้ร่วมกัน

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

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

Web Worker และ Service Worker

ความคล้ายคลึง

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

• ทั้ง 2 อย่างนี้ทำงานในเทรดรอง ซึ่งช่วยให้โค้ด JavaScript ทำงานได้โดยไม่บล็อกเทรดหลักและอินเทอร์เฟซผู้ใช้
• สคริปต์เหล่านี้ไม่มีสิทธิ์เข้าถึงออบเจ็กต์ Window และ Document จึงไม่สามารถโต้ตอบกับ DOM โดยตรง และมีสิทธิ์เข้าถึง API ของเบราว์เซอร์แบบจำกัด

ความแตกต่าง

บางคนอาจคิดว่าสิ่งต่างๆ ส่วนใหญ่ที่สามารถมอบสิทธิ์ให้ Web Worker ได้นั้นสามารถทำได้ใน Service Worker และในทางกลับกัน แต่ทั้ง 2 อย่างนี้มีความแตกต่างที่สำคัญดังนี้

• Service Worker ต่างจาก Web Worker ตรงที่ช่วยให้คุณสกัดกั้นคำขอเครือข่าย (ผ่านเหตุการณ์ fetch) และฟังเหตุการณ์ Push API ในเบื้องหลัง (ผ่านเหตุการณ์ push) ได้
• หน้าเว็บสามารถสร้าง Web Worker ได้หลายรายการ แต่ Service Worker รายการเดียวจะควบคุมแท็บที่ใช้งานอยู่ทั้งหมดภายใต้ขอบเขตที่ลงทะเบียนไว้
• อายุการใช้งานของ Web Worker จะเชื่อมโยงกับแท็บที่เกี่ยวข้องอย่างใกล้ชิด ในขณะที่วงจรชีวิตของ Service Worker จะเป็นอิสระจากแท็บ ด้วยเหตุนี้ การปิดแท็บที่ Web Worker ทำงานอยู่จะสิ้นสุดการทำงานของ Web Worker ขณะที่ Service Worker จะทำงานในเบื้องหลังต่อไปได้ แม้ว่าเว็บไซต์จะไม่มีแท็บที่เปิดอยู่ก็ตาม

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

กรณีการใช้งาน

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

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

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

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

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

UI ได้รับการอัปเดตเพื่อแสดงความคืบหน้าของการดาวน์โหลด (ซ้าย) Service Worker ช่วยให้การดำเนินการทำงานต่อไปได้เมื่อปิดแท็บทั้งหมดแล้ว (ขวา)

เครื่องมือและไลบรารี

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

Comlink

Comlink เป็นไลบรารี RPC ขนาดเล็ก (1.6k) ที่ดูแลรายละเอียดเบื้องหลังมากมายเมื่อสร้างเว็บไซต์ที่ใช้ Web Worker โดยมีการใช้ในเว็บไซต์ต่างๆ เช่น PROXX และ Squoosh ดูสรุปแรงจูงใจและตัวอย่างโค้ดได้ที่นี่

Workbox

Workbox เป็นไลบรารียอดนิยมสำหรับการสร้างเว็บไซต์ที่ใช้ Service Worker โดยจะรวมชุดแนวทางปฏิบัติแนะนำเกี่ยวกับสิ่งต่างๆ เช่น การแคช, ออฟไลน์, การซิงค์ในเบื้องหลัง ฯลฯ โมดูล workbox-window ช่วยให้แลกเปลี่ยนข้อความระหว่าง Service Worker กับหน้าเว็บได้อย่างสะดวก

ขั้นตอนถัดไป

ส่วนที่เหลือของชุดบทความนี้จะเน้นที่รูปแบบการสื่อสารระหว่างหน้าต่างและ Service Worker ดังนี้

• คู่มือการแคชแบบบังคับ: การเรียกใช้ Service Worker จากหน้าเว็บเพื่อแคชทรัพยากรล่วงหน้า (เช่น ในสถานการณ์การดึงข้อมูลล่วงหน้า)
• ประกาศการอัปเดต: การเรียกหน้าเว็บจาก Service Worker เพื่อแจ้งเกี่ยวกับการอัปเดตที่สำคัญ (เช่น เว็บไซต์เวอร์ชันใหม่พร้อมใช้งานแล้ว)
• การสื่อสารแบบ 2 ทาง: การมอบหมายงานให้ Service Worker (เช่น การดาวน์โหลดขนาดใหญ่) และแจ้งความคืบหน้าให้หน้าเว็บทราบ

ดูรูปแบบการสื่อสารของหน้าต่างและ Web Worker ได้ที่ใช้ Web Worker เพื่อเรียกใช้ JavaScript นอกเทรดหลักของเบราว์เซอร์