ช่วงทดลองใช้ Service Worker Static Routing API จากต้นทาง

Brendan Kenny
Brendan Kenny

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, การใช้งาน และฟังก์ชันการทำงานที่มีให้