โปรแกรมทำงานของบริการเป็นเครื่องมือที่มีประสิทธิภาพในการอนุญาตให้เว็บไซต์ทำงานแบบออฟไลน์และสร้างกฎการแคชแบบพิเศษสำหรับตนเอง เครื่องจัดการบริการ fetch จะเห็นคำขอทั้งหมดจากหน้าเว็บที่ตนควบคุม และเลือกได้ว่าจะตอบกลับคำขอจากแคชของ Service Worker หรือไม่ หรือแม้แต่เขียน URL ใหม่เพื่อดึงการตอบกลับอื่นโดยสิ้นเชิง เช่น ตามค่ากำหนดของผู้ใช้ในเครื่อง
อย่างไรก็ตาม โปรแกรมทำงานของบริการอาจมีต้นทุนด้านประสิทธิภาพเมื่อโหลดหน้าเว็บเป็นครั้งแรกเป็นระยะเวลาหนึ่ง และ 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 เพื่อโหลดทรัพยากรผ่านเครือข่ายโดยตรง) แต่แผนคือการขยายค่านี้ไปยังค่าอื่นๆ ในอนาคต
Use Case
ตามที่อธิบายไว้ เวอร์ชันแรกของ API นั้นเป็นช่องทางหลีกเลี่ยงจากการควบคุมของ Service Worker สำหรับบางเส้นทาง การดำเนินการที่เหมาะสมจะขึ้นอยู่กับวิธีที่คุณใช้ Service Worker และวิธีที่ผู้ใช้ข้ามผ่านเว็บไซต์
ตัวอย่างหนึ่งอาจเป็นกรณีที่เว็บไซต์ของคุณใช้กลยุทธ์แบบเน้นแคชเป็นหลัก (กลับไปใช้เครือข่ายเดิม) แต่มีเนื้อหาบางส่วนที่มีการเข้าชมน้อยครั้งมากจนเกิดแคช (เช่น เนื้อหาที่เก็บถาวรหรือฟีด RSS) การจำกัดให้ดึงข้อมูลเส้นทางเหล่านี้จากเครือข่ายจะทำได้เท่านั้นใน Service Worker แต่โปรแกรมทำงานของบริการยังคงต้องเริ่มต้นและเรียกใช้เพื่อตัดสินใจว่าจะจัดการกับคำขอเหล่านั้นอย่างไร
ในทางตรงกันข้าม Routing 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',
}]);
}
});
เมื่อ API การกำหนดเส้นทางแบบคงที่ของ Service Worker พัฒนาขึ้น แผนก็เพื่อให้การกำหนดค่านี้มีความยืดหยุ่นมากขึ้นและรองรับสถานการณ์ต่างๆ มากขึ้น เช่น ประกาศการแข่งขันการดึงข้อมูลเครือข่ายและการเริ่มการทำงานของ Service Worker ดูรายละเอียดเพิ่มเติมได้ในการสํารวจข้อมูลจำเพาะของ "รูปแบบสุดท้าย" ที่เป็นไปได้ของ API
การทดลองใช้ Service Worker Static Routing API
Service Worker Static Routing API พร้อมใช้งานใน Chrome ตั้งแต่เวอร์ชัน 116 หลังช่วงทดลองใช้จากต้นทาง ซึ่งช่วยให้นักพัฒนาซอฟต์แวร์ทดสอบ API ในเว็บไซต์กับผู้ใช้จริงเพื่อวัดผลกระทบได้ ดู "เริ่มต้นใช้งานช่วงทดลองใช้จากต้นทาง" เพื่อดูข้อมูลพื้นฐานเกี่ยวกับช่วงทดลองใช้จากต้นทาง
สำหรับการทดสอบภายใน คุณเปิดใช้ Service Worker Static Routing API ได้ด้วยแฟล็กที่ chrome://flags/#service-worker-static-router หรือโดยเรียกใช้ Chrome จากคำสั่งเหมือนใน --enable-features=ServiceWorkerStaticRouter
ความคิดเห็นและคำแนะนำในอนาคต
Service Worker Static Routing API อยู่ระหว่างการพัฒนาอย่างต่อเนื่องและยังคงเป็นรูปเป็นร่าง หากคิดว่าวิธีนี้น่าจะเป็นประโยชน์สำหรับคุณ โปรดลองใช้ผ่านช่วงทดลองใช้จากต้นทางและแสดงความคิดเห็นเกี่ยวกับ API การใช้งาน และฟังก์ชันที่ใช้ได้