พนักงานบริการ กปภ. หุ่นจำลอง

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

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

พนักงานบริการคืออะไร?

คำจำกัดความ

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

มันทำงานอย่างไร

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

และเนื่องจากพนักงานบริการเป็นคนทำงาน ตามเหตุการณ์ จึงตอบสนองและสื่อสารผ่านเหตุการณ์เท่านั้น และใช้คำสัญญาเพื่อบอกว่าการดำเนินการเสร็จสิ้นเมื่อใด อย่างไรก็ตาม การรับเหตุการณ์ทั้งหมด (เช่น fetch and push ) จะเกิดขึ้นได้ก็ต่อเมื่อพนักงานบริการทำงาน อยู่ ซึ่งบ่งชี้ว่าเบราว์เซอร์รู้จักและ ลงทะเบียน พนักงานบริการเมื่อใด (และเมื่อตัวพนักงานบริการ ติดตั้งเสร็จเรียบร้อยแล้วด้วย) ในลักษณะที่เรียบง่าย นี่คือวงจรชีวิตทั่วไปของพนักงานบริการ:

นอกจากนี้ ให้สังเกตเหตุการณ์ที่มีทั้งหมดเหล่านี้ในพนักงานบริการ:

เหตุการณ์การทำงานทั้งหมด ( fetch , sync , และ push ) ควรอธิบายในตัวคุณได้เอง เนื่องจากเป็นเหตุการณ์ที่สร้างคุณลักษณะขั้นสูงเกือบทั้งหมดของ PWA (เช่น ความสามารถออฟไลน์ การซิงค์พื้นหลัง การแจ้งเตือนแบบพุช)

 การอ่านที่แนะนำ: กปภ. คืออะไร? สิ่งที่คุณต้องรู้เกี่ยวกับ Progressive Web Apps

ข้อจำกัดของพนักงานบริการ

เนื่องจากเป็นสคริปต์ที่ทำงานโดยไม่ขึ้นกับเบราว์เซอร์ จึงมีข้อจำกัดบางประการ:

• โปรโตคอล HTTPS : พนักงานบริการต้องทำงานบนเว็บไซต์ที่ใช้ HTTPS

• ไม่มีการเข้าถึง localStorage , DOM และหน้าต่าง
• scope ที่จำกัด : พนักงานบริการสามารถทำงานได้เฉพาะใน scope ของไดเร็กทอรีปัจจุบัน (และไดเร็กทอรีย่อย) ที่ service-worker.js ตั้งอยู่
• อะซิงโครนัส : พนักงานบริการมีลักษณะไม่ตรงกัน จึงอาศัย API แบบ Promise

พนักงานบริการมีความหมายต่อ กปภ. อย่างไร

ตามที่ระบุไว้ก่อนหน้านี้ พนักงานบริการเป็นกระดูกสันหลังของ กปภ. หากปราศจากคุณสมบัติที่ปฏิวัติวงการมากมายของ กปภ. ก็เป็นไปไม่ได้ โดยพื้นฐานแล้ว สิ่งที่พนักงานบริการทำคือมีช่องทางสำหรับ:

ประสิทธิภาพที่ดีขึ้น

ประสิทธิภาพในการเยี่ยมชมซ้ำๆ จะดีกว่าใน PWA อย่างมาก เนื่องจากพนักงานบริการช่วยในกระบวนการแคชอย่างมาก เมื่อเทียบกับแคชของเว็บทั่วไป (แคช HTTP) ที่ใช้ในเว็บไซต์ส่วนใหญ่ PWA นำเสนอเนื้อหาได้ดีเยี่ยมแม้ในสภาพเครือข่ายที่ไม่เอื้ออำนวย:

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

โดยเฉลี่ย หน้าโหลดเร็วขึ้นเล็กน้อยเมื่อพนักงานบริการควบคุมเพจมากกว่าที่พวกเขาทำโดยไม่มีพนักงานบริการ ทั้งสำหรับผู้เยี่ยมชมใหม่และผู้เข้าชมที่กลับมา

Philip Walton การวัดผลการปฏิบัติงานในโลกแห่งความเป็นจริงของพนักงานบริการ

การเข้าถึงแบบออฟไลน์

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

นี่ไม่ได้หมายความว่าการเข้าถึงแบบออฟไลน์เป็นคุณลักษณะที่ไม่เคยเห็นบนเว็บมาก่อนเช่นกัน — เป็น ไปได้ ที่จะมอบประสบการณ์ออฟไลน์บนเว็บให้กับผู้ใช้ เพียงแต่ประสบการณ์ที่ไม่เหมาะสม (ดู Application Cache เป็น Douchebag) และบริการ คนงานถูกคิดค้นเพื่อแก้ไข (หรือมากกว่าเช่นหลีกเลี่ยง) ข้อเสียของ AppCache

 การอ่านที่แนะนำ: วิธีทำให้ PWA ของคุณทำงานแบบออฟไลน์

คุณสมบัติแอพเนทีฟ

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

วงจรชีวิตของพนักงานบริการ

อายุการใช้งานของบริการประกอบด้วยสามส่วน: การลงทะเบียน การติดตั้ง และการเปิดใช้งาน ซึ่งเราจะพูดถึงรายละเอียดด้านล่าง:

การลงทะเบียน

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

 if('serviceWorker' ในตัวนำทาง) {
    navigator.serviceWorker.register('./pwa-examples/simicart/sw.js', {ขอบเขต: './sw-scope/'})
.then((reg) => {
   //การลงทะเบียนทำงาน
       console.log('การลงทะเบียนสำเร็จ ขอบเขตคือ ' + reg.scope);
};

โค้ดข้างต้นจะเริ่มค้นหา Service Worker API ในเบราว์เซอร์ก่อน และหากเบราว์เซอร์รองรับ API ดังกล่าว โค้ดดังกล่าวจะลงทะเบียนพนักงานบริการใหม่โดยใช้เมธอด serviceworkerContainer.register() และให้ scope ของพนักงานบริการ ตัวอย่างเช่น ในโค้ดด้านบน scope ของเราคือ /pwa-examples/simicart/ ซึ่งหมายความว่าพนักงานบริการของเราจะทำงานกับหน้าที่ขึ้นต้นด้วย /pwa-examples/simicart/ เท่านั้น เราเรียกหน้าเหล่านี้ว่า ' หน้าที่ควบคุม '

การติดตั้ง

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

 const cacheName = 'site-cache-v1'
const assetToCache = [
    '/pwa-ตัวอย่าง/',
    '/pwa-examples/index.html',
    '/pwa-examples/css/styles.css',
    '/pwa-examples/js/app.js',
]

self.addEventListener ('ติดตั้ง', ( เหตุการณ์ ) => {
    เหตุการณ์. waitUntil(  
        caches.open(cacheName).then((cache) => {
              ส่งคืน cache.addAll(assetsToCache);
        })
      );
});

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

การเปิดใช้งาน

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

อีกวิธีหนึ่ง คุณยังสามารถทำให้กระบวนการเปิดใช้งานของผู้ปฏิบัติงานบริการของคุณเป็นแบบอัตโนมัติได้โดยใช้ skipWaiting()

 const cacheName = 'site-cache-v1'
const assetToCache = [
    '/pwa-ตัวอย่าง/',
    '/pwa-examples/index.html',
    '/pwa-examples/css/styles.css',
    '//pwa-examples/js/app.js',
]
self.addEventListener ('ติดตั้ง', ( เหตุการณ์ ) => {
    self.skipWaiting(); //ข้ามไปรอ
    เหตุการณ์. waitUntil(  
        caches.open(cacheName).then((cache) => {
              ส่งคืน cache.addAll(assetsToCache);
        })
      );
});

เว็บต้องการพนักงานบริการ

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

สำหรับผู้ค้า Magento ที่ต้องการเปลี่ยนหน้าร้าน เรามอบโซลูชัน PWA แบบไม่มีหัวที่คุ้มค่าและสมบูรณ์แบบสำหรับธุรกิจของคุณ