Service Worker เป็นเครื่องมือที่มีประสิทธิภาพในการอนุญาตให้เว็บไซต์ทำงานแบบออฟไลน์และสร้างกฎการแคชเฉพาะสำหรับตนเอง แฮนเดิล fetch
ของ Service Worker จะดูคำขอทั้งหมดจากหน้าที่ควบคุมได้ และตัดสินใจได้ว่าต้องการแสดงคำตอบจากแคชของ Service Worker หรือจะเขียน URL ใหม่เพื่อดึงข้อมูลคำตอบอื่นทั้งหมดก็ได้ เช่น ตามค่ากําหนดของผู้ใช้ในเครื่อง
อย่างไรก็ตาม Service Worker อาจส่งผลเสียต่อประสิทธิภาพเมื่อมีการโหลดหน้าเว็บเป็นครั้งแรกในระยะเวลาหนึ่งและ Service Worker ที่ควบคุมไม่ได้ทำงานอยู่ เนื่องจากการดึงข้อมูลทั้งหมดต้องดำเนินการผ่าน Service Worker เบราว์เซอร์จึงต้องรอให้ Service Worker เริ่มทำงานและเรียกใช้เพื่อดูว่าต้องโหลดเนื้อหาใด ค่าใช้จ่ายเริ่มต้นนี้อาจน้อยนิด แต่สำคัญอย่างยิ่งสำหรับนักพัฒนาซอฟต์แวร์ที่ใช้ Service Worker เพื่อปรับปรุงประสิทธิภาพผ่านกลยุทธ์การแคช
การโหลดนำทางล่วงหน้าเป็นแนวทางหนึ่งในการแก้ปัญหา ซึ่งช่วยให้ส่งคำขอไปยังเครือข่ายได้ควบคู่ไปกับการเปิดใช้งาน Service Worker แต่จำกัดไว้ที่คำขอนำทางเริ่มต้นและยังคงรวม Service Worker ไว้ในเส้นทางที่สำคัญ นับตั้งแต่เปิดตัวการโหลดนำทางล่วงหน้า เราได้พยายามหลายครั้งในการพัฒนาโซลูชันทั่วไปมากขึ้นสำหรับปัญหานี้ รวมถึงวิธีป้องกันไม่ให้คำขอบางรายการถูกบล็อกเมื่อ Service Worker เริ่มทำงาน
Service Worker Static Routing API
ตั้งแต่ Chrome 116 เป็นต้นไป Service Worker Static Routing API เวอร์ชันทดลองจะพร้อมให้ทดสอบเป็นขั้นตอนแรกในโซลูชันดังกล่าว เมื่อติดตั้ง Service Worker แล้ว บริการดังกล่าวจะใช้ Service Worker Static Routing API เพื่อประกาศวิธีดึงข้อมูลเส้นทางทรัพยากรบางอย่างได้
ใน API เวอร์ชันแรก คุณสามารถประกาศเส้นทางให้แสดงจากเครือข่ายเสมอ ไม่ใช่จาก Service Worker เมื่อโหลด URL ที่มีการควบคุมในภายหลัง เบราว์เซอร์จะเริ่มดึงข้อมูลทรัพยากรจากเส้นทางเหล่านั้นก่อนที่ Service Worker จะเริ่มต้นเสร็จ ซึ่งจะนำ Service Worker ออกจากเส้นทางที่คุณทราบว่าไม่จําเป็นต้องใช้
หากต้องการใช้ API เวิร์กเกอร์บริการจะเรียก event.registerRouter ในเหตุการณ์ install
ด้วยชุดกฎต่อไปนี้
self.addEventListener('install', event => {
if (event.registerRouter) {
// Go straight to the network and bypass invoking "fetch" handlers for all
// same-origin URLs that start with '/form/'.
event.registerRouter([{
condition: {
urlPattern: {pathname: '/form/*'},
},
source: 'network',
}]);
}
});
โดยทั่วไปกฎแต่ละข้อจะมีพร็อพเพอร์ตี้ 2 รายการ ได้แก่
condition: ระบุเวลาที่จะใช้กฎโดยใช้ URL Pattern API เพื่อจับคู่เส้นทางทรัพยากร พร็อพเพอร์ตี้นี้ใช้อินสแตนซ์URLPatternหรือออบเจ็กต์ทั่วไปที่เทียบเท่าซึ่งเข้ากันได้กับการส่งผ่านไปยังคอนสตรัคเตอร์URLPatternได้ (เช่นnew URLPattern({pathname: '*.jpg'})หรือแค่{pathname: '*.jpg'})ความยืดหยุ่นของรูปแบบ URL หมายความว่ากฎสามารถจับคู่กับสิ่งที่เรียบง่าย เช่น ทรัพยากรภายใต้เส้นทาง ไปจนถึงเงื่อนไขที่เฉพาะเจาะจงและละเอียดมาก โดยทั่วไปแล้ว รูปแบบเหล่านี้ควรคุ้นเคยกับผู้ใช้ไลบรารีการกำหนดเส้นทางยอดนิยม
source: ระบุวิธีโหลดทรัพยากรที่ตรงกับconditionปัจจุบันระบบรองรับเฉพาะค่า'network'(ข้าม Service Worker เพื่อโหลดทรัพยากรผ่านเครือข่ายโดยตรง) แต่เรามีแผนที่จะขยายการให้บริการนี้ไปยังค่าอื่นๆ ในอนาคต
กรณีการใช้งาน
ตามที่อธิบายไว้ API เวอร์ชันแรกมีไว้เพื่อหลบเลี่ยงการควบคุม Service Worker สำหรับบางเส้นทาง กรณีที่ควรใช้จะขึ้นอยู่กับวิธีใช้ Service Worker และวิธีที่ผู้ใช้ไปยังส่วนต่างๆ ของเว็บไซต์
ตัวอย่างเช่น เว็บไซต์ใช้กลยุทธ์แคชก่อน (ใช้เครือข่ายสำรอง) แต่มีเนื้อหาบางอย่างที่ไม่ค่อยมีคนเข้าชม จึงไม่มีคุณค่ามากนักในการแคช (เช่น เนื้อหาที่เก็บถาวรหรือฟีด RSS) การจำกัดเส้นทางเหล่านี้ให้ดึงข้อมูลจากเครือข่ายทำได้เฉพาะใน Service Worker แต่ Service Worker ยังคงต้องเริ่มต้นและทำงานเพื่อตัดสินใจว่าจะจัดการกับคำขอเหล่านั้นอย่างไร
ในทางตรงกันข้าม API การกำหนดเส้นทางแบบคงที่จะข้าม Service Worker ทั้งหมดด้วยบรรทัดประกาศ 2-3 บรรทัด ดังนี้
self.addEventListener('install', event => {
if (event.registerRouter) {
event.registerRouter([{
condition: {
urlPattern: {pathname: '/feeds/*.xml'},
},
source: 'network',
}, {
condition: {
urlPattern: {pathname: '/archives/*'},
},
source: 'network',
}]);
}
});
เมื่อ Service Worker Static Routing API พัฒนาขึ้น แผนของเราคือการกำหนดค่านี้จะมีความยืดหยุ่นมากขึ้นและรองรับสถานการณ์ต่างๆ ได้มากขึ้น เช่น การประกาศการแข่งขันการดึงข้อมูลเครือข่ายและการเริ่มต้น Service Worker ดูรายละเอียดเพิ่มเติมได้ที่การสํารวจ "รูปแบบสุดท้าย" ที่เป็นไปได้ของ API จากคําอธิบายข้อกําหนด
ลองใช้ Service Worker Static Routing API
Service Worker Static Routing API พร้อมใช้งานใน Chrome ตั้งแต่เวอร์ชัน 116 เป็นต้นไปในช่วงทดลองใช้แหล่งที่มา ซึ่งช่วยให้นักพัฒนาแอปทดสอบ API ในเว็บไซต์กับผู้ใช้จริงเพื่อวัดผลได้ ดูข้อมูลเบื้องต้นเกี่ยวกับการทดลองใช้ต้นทางได้ที่"เริ่มต้นใช้งานการทดลองใช้ต้นทาง"
สําหรับการทดสอบในเครื่อง คุณสามารถเปิดใช้ Service Worker Static Routing API ด้วย Flag ที่ chrome://flags/#service-worker-static-router หรือเรียกใช้ Chrome จากคําสั่ง เช่น --enable-features=ServiceWorkerStaticRouter
ความคิดเห็นและทิศทางในอนาคต
Service Worker Static Routing API กำลังอยู่ระหว่างการพัฒนาและกำลังมีการเปลี่ยนแปลง หากคิดว่าฟีเจอร์นี้อาจมีประโยชน์กับคุณ โปรดลองใช้ผ่านช่วงทดลองใช้เวอร์ชันต้นทางและแสดงความคิดเห็นเกี่ยวกับ API, การใช้งาน และฟังก์ชันการทำงานที่มีให้