Service Worker เป็นเครื่องมือที่มีประสิทธิภาพที่ช่วยให้เว็บไซต์ทำงานแบบออฟไลน์และสร้างกฎการแคชเฉพาะให้กับตนเองได้ เครื่องจัดการ fetch ของ Service Worker จะเห็นคำขอทั้งหมดจากหน้าเว็บที่ตนควบคุม และตัดสินใจได้ว่าต้องการแสดงการตอบกลับจากแคชของ 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 สามารถประกาศเส้นทางให้แสดงจากเครือข่ายได้เสมอ ไม่ใช่โปรแกรมทำงานของบริการ เมื่อมีการโหลด 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: ระบุว่ากฎจะมีผลเมื่อใดโดยใช้ API รูปแบบ URL เพื่อจับคู่เส้นทางทรัพยากร พร็อพเพอร์ตี้สามารถใช้อินสแตนซ์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 โดยสิ้นเชิงด้วยบรรทัดประกาศไม่กี่บรรทัดต่อไปนี้
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 พัฒนาขึ้นเรื่อยๆ แผนการจะช่วยให้การกำหนดค่านี้มีความยืดหยุ่นมากขึ้นและรองรับสถานการณ์ต่างๆ มากขึ้น เช่น การแข่งขันที่จะเริ่มต้นการดึงข้อมูลเครือข่ายและการเริ่มต้นโปรแกรมทำงานของบริการ ดูรายละเอียดเพิ่มเติมได้ในการสำรวจ "รูปแบบสุดท้าย" ที่เป็นไปได้ของ 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, การใช้งาน และฟังก์ชันที่พร้อมใช้งาน