แนวทางปฏิบัติแนะนำเกี่ยวกับเวลาในการลงทะเบียน Service Worker
บริการ ผู้ปฏิบัติงาน ช่วยเพิ่มความเร็วในการเข้าชมซ้ำ บนแอปพลิเคชันเว็บของคุณได้อย่างมาก แต่คุณควรดำเนินการ เพื่อตรวจสอบว่าการติดตั้งครั้งแรกของโปรแกรมทำงานของบริการจะไม่ลดระดับ การเข้าชมครั้งแรกของผู้ใช้
โดยทั่วไปการเลื่อนเวลาของ Service Worker การลงทะเบียน จนกว่าหน้าเริ่มต้นจะโหลดขึ้นมาแล้ว จึงจะให้ประสบการณ์ที่ดีที่สุดสำหรับ โดยเฉพาะผู้ที่ใช้อุปกรณ์เคลื่อนที่ซึ่งมีการเชื่อมต่อเครือข่ายที่ช้า
ต้นแบบสำหรับการจดทะเบียนทั่วไป
ถ้าคุณเคยอ่านข้อมูลเกี่ยวกับโปรแกรมทำงานของบริการ คุณคงเคยเจอ ต้นแบบที่คล้ายกันอย่างมากกับตัวอย่างต่อไปนี้
if ('serviceWorker' in navigator) {
navigator.serviceWorker.register('/service-worker.js');
}
บางครั้งอาจมาพร้อมกับคำสั่ง console.log()
บางรายการ หรือ
รหัส
ที่ตรวจหาการอัปเดตในการลงทะเบียน Service Worker ก่อนหน้านี้เพื่อเป็นวิธีการ
ซึ่งแจ้งให้ผู้ใช้รีเฟรชหน้า แต่สิ่งเหล่านี้เป็นเพียงรูปแบบเล็กๆ น้อยๆ
มาตรฐานสองสามบรรทัดของโค้ด
แล้ว navigator.serviceWorker.register
จะมีความแตกต่างเล็กๆ น้อยๆ ไหม มี
แนวทางปฏิบัติแนะนำที่ควรทำตามมีอะไรบ้าง ไม่น่าแปลกใจเลย (หากบทความนี้ไม่ได้จบเพียงเท่านี้
ตรงนี้) คำตอบของทั้ง 2 อย่างคือ "ใช่!"
การเข้าชมครั้งแรกของผู้ใช้
สมมติว่าผู้ใช้เข้าชมเว็บแอปเป็นครั้งแรก ยังไม่มี Service Worker และเบราว์เซอร์ไม่มีทางรู้ล่วงหน้าว่าจะมีบริการ พนักงานที่ติดตั้งในท้ายที่สุด
ในฐานะนักพัฒนาซอฟต์แวร์ สิ่งสำคัญที่ควรทราบคือตรวจสอบว่าเบราว์เซอร์ จะได้รับชุดทรัพยากรที่สำคัญน้อยที่สุดซึ่งจำเป็นต่อการแสดง สิ่งใดก็ตามที่ทำให้การเรียกคำตอบเหล่านั้นช้าลงถือเป็นศัตรูของ โต้ตอบได้อย่างรวดเร็ว
คราวนี้ลองจินตนาการว่าในกระบวนการดาวน์โหลด JavaScript หรือรูปภาพที่ หน้าเว็บของคุณจะต้องแสดงผล เบราว์เซอร์จึงตัดสินใจเริ่มชุดข้อความที่พื้นหลัง หรือ (เพื่อความกระชับ เราจะสมมติว่าเป็นชุดข้อความ) สมมติว่า คุณไม่ได้ใช้เครื่องเดสก์ท็อปขนาดใหญ่ แต่เป็นประเภทที่ด้อยประสิทธิภาพ เป็นโทรศัพท์มือถือที่คนทั่วโลกมองว่าเป็นอุปกรณ์หลัก หมุนขึ้น เทรดพิเศษนี้เพิ่มการช่วงชิงเวลา CPU และหน่วยความจำที่เบราว์เซอร์ของคุณ มิเช่นนั้น อาจต้องเสียค่าการแสดงผลหน้าเว็บแบบอินเทอร์แอกทีฟ
เทรดที่ไม่มีการใช้งานในเบื้องหลังมักไม่สร้างความแตกต่างที่มีนัยสำคัญ แต่ หากเทรดนั้นไม่ได้อยู่ แต่ตัดสินว่าจะเริ่มต้นขึ้นด้วย ดาวน์โหลดทรัพยากรจากเครือข่าย ข้อกังวลต่างๆ เกี่ยวกับ CPU หรือหน่วยความจำ ควรกังวลเรื่องแบนด์วิดท์จำกัด ใช้ได้กับอุปกรณ์เคลื่อนที่จำนวนมาก แบนด์วิดท์มีค่า อย่าทำลายแบนด์วิดท์ ทรัพยากรวิกฤติด้วยการดาวน์โหลด ทรัพยากรรองพร้อมๆ กัน
ซึ่งทั้งหมดนี้คือการสร้างชุดข้อความของ Service Worker ใหม่เพื่อดาวน์โหลด และทรัพยากรแคชในพื้นหลังอาจได้ผล ตามเป้าหมายในการให้ ประสบการณ์การโต้ตอบที่สั้นที่สุด ครั้งแรกที่ผู้ใช้เข้าชม ของคุณ
การปรับปรุงต้นแบบ
โซลูชันคือการควบคุมการเริ่มต้นโปรแกรมทำงานของบริการโดยเลือกเวลาที่จะเรียกใช้
navigator.serviceWorker.register()
หลักการง่ายๆ ก็คือ ความล่าช้า
ลงทะเบียนจนถึงวันที่ load
event
เริ่มทำงานใน window
เช่น
if ('serviceWorker' in navigator) {
window.addEventListener('load', function() {
navigator.serviceWorker.register('/service-worker.js');
});
}
แต่เวลาที่เหมาะสมในการเริ่มต้นลงทะเบียน Service Worker ยังอาจขึ้นอยู่กับ ว่าแอปพลิเคชันเว็บของคุณกำลังทำอะไรหลังจากโหลดขึ้นมา ตัวอย่างเช่น การประชุม Google I/O เว็บแอป 2016 มีภาพเคลื่อนไหวสั้นๆ ก่อนเปลี่ยนไปยังหน้าจอหลัก ทีมของเรา พบที่การเตะ ปิดการลงทะเบียน Service Worker ระหว่างภาพเคลื่อนไหวอาจทำให้เกิดความไม่ปกติ บนอุปกรณ์เคลื่อนที่โลว์เอนด์ แทนที่จะให้ประสบการณ์ที่ไม่ดีแก่ผู้ใช้ เรา ล่าช้า การลงทะเบียนโปรแกรมทำงานของบริการจนกระทั่งหลังจากภาพเคลื่อนไหว ซึ่งเป็นเวลาที่เบราว์เซอร์ มักจะไม่มีการใช้งาน 2-3 วินาที
ในทำนองเดียวกัน หากเว็บแอปของคุณใช้เฟรมเวิร์กที่ตั้งค่าเพิ่มเติมหลังจาก หน้าเว็บโหลดขึ้นมาแล้ว มองหาเหตุการณ์เฉพาะเฟรมเวิร์กซึ่งจะส่งสัญญาณเมื่อมีเหตุการณ์ดังกล่าว เสร็จแล้ว
การเข้าชมที่ตามมา
จนถึงตอนนี้ เรามุ่งเน้นที่การเข้าชมครั้งแรก แต่ถึงตอนนี้ การลงทะเบียน Service Worker ที่ล่าช้ามีการเข้าชมเว็บไซต์ซ้ำไหม แม้ว่าอาจทำให้บางคนตกใจ แต่ก็จะไม่ส่งผลกระทบใดๆ เลย
เมื่อลงทะเบียน Service Worker แล้ว โปรแกรมจะทำงานผ่าน install
และ
activate
วงจร
กิจกรรม
เมื่อเปิดใช้งาน Service Worker แล้ว โปรแกรมจะทำงานเพื่อจัดการเหตุการณ์ fetch
สำหรับ
การเข้าชมเว็บแอปของคุณในภายหลัง Service Worker จะเริ่มทำงานก่อน
มีการจัดทำคำขอสำหรับหน้าเว็บภายใต้ขอบเขตนี้ ซึ่งเหมาะสมหากคุณคิดว่า
เกี่ยวกับเรื่องนี้ หากโปรแกรมทำงานของบริการที่มีอยู่ยังไม่ได้ทำงานก่อน
การเข้าชมหน้าเว็บ ก็คงไม่มีโอกาสดำเนินการตามกิจกรรม fetch
รายการจนครบสำหรับ
คำขอการนำทาง
ดังนั้นเมื่อมี Service Worker ที่ทำงาน ก็ไม่สำคัญว่าคุณจะโทรติดต่อ
navigator.serviceWorker.register()
หรือที่จริงแล้ว ไม่ว่าคุณจะเรียกว่าเลย
ยกเว้นกรณีที่คุณเปลี่ยน URL ของสคริปต์ Service Worker
navigator.serviceWorker.register()
เป็น
no-op ระหว่างการเข้าชมครั้งต่อๆ ไป เมื่อใด
ที่เรียกว่าไม่เกี่ยวข้อง
เหตุผลที่ควรลงทะเบียนตั้งแต่เนิ่นๆ
มีสถานการณ์ใดบ้างที่การลงทะเบียน Service Worker ของคุณโดยเร็วที่สุด
จะสมเหตุสมผลไหม สิ่งหนึ่งที่ต้องนึกถึงก็คือเมื่อโปรแกรมทำงานของบริการใช้
clients.claim()
เข้าควบคุมหน้าเว็บในระหว่างการเข้าชมครั้งแรก และให้โปรแกรมทำงานของบริการ
ทำงานรันไทม์ในเชิงรุก
การแคช
ภายในเครื่องจัดการ fetch
ในสถานการณ์ดังกล่าว
ในการทำให้ Service Worker ทำงานได้รวดเร็วที่สุด
เติมข้อมูลแคชรันไทม์ด้วยทรัพยากรที่อาจมีประโยชน์ในภายหลัง ถ้า
เว็บแอปของคุณจัดอยู่ในหมวดหมู่นี้ คุณจึงควรย้อนกลับไป
ตรวจสอบว่าเครื่องจัดการ install
ของ Service Worker ไม่ได้ขอ
ที่แย่งชิงแบนด์วิดท์ไปกับคำขอของหน้าเว็บหลัก
ทดลองใช้สิ่งต่างๆ
วิธีที่ยอดเยี่ยมในการจำลองการเข้าชมครั้งแรกคือการเปิดเว็บแอปใน Chrome ไม่ระบุตัวตน หน้าต่าง และดูการจราจรของข้อมูลในเครือข่ายใน Chrome เครื่องมือสำหรับนักพัฒนาเว็บ เป็นเว็บ คุณก็คงโหลดอินสแตนซ์ในเครื่องของเว็บแอปหลายสิบรายการ หลายสิบครั้งต่อวัน แต่ด้วยการกลับไปเยี่ยมชมเว็บไซต์ของคุณอีกครั้งเมื่อมี Service Worker และแคชที่มีการเติมข้อมูลให้สมบูรณ์แล้ว คุณจะไม่ได้รับประสบการณ์เดียวกันนี้ ผู้ใช้ใหม่จะได้รับ และคุณก็ไม่ต้องสนใจปัญหาที่อาจเกิดขึ้น
ต่อไปนี้เป็นตัวอย่างที่แสดงความแตกต่างของเวลาการลงทะเบียน แบรนด์ ภาพหน้าจอทั้ง 2 ภาพจะได้รับการบันทึกขณะไปที่ตัวอย่าง แอปใน โหมดไม่ระบุตัวตนที่ใช้การควบคุมเครือข่ายเพื่อจำลองการเชื่อมต่อที่ช้า
ภาพหน้าจอด้านบนแสดงการจราจรของข้อมูลในเครือข่ายเมื่อมีการแก้ไขตัวอย่าง
เพื่อดำเนินการลงทะเบียน Service Worker โดยเร็วที่สุด คุณจะเห็น
คำขอแคชล่วงหน้า (รายการที่มี เฟือง)
ไอคอน
ที่อยู่ติดกัน เริ่มต้นจากเครื่องจัดการ install
ของ Service Worker)
กระจายอยู่กับคำขอทรัพยากรอื่นๆ ที่จำเป็นต่อการแสดงหน้าเว็บ
ในภาพหน้าจอด้านบน การลงทะเบียนโปรแกรมทำงานของบริการล่าช้าจนกระทั่งหลังจาก
โหลดหน้าเว็บแล้ว คุณจะเห็นว่าคำขอแคชล่วงหน้าไม่เริ่มขึ้นจนกว่าจะครบทั้งหมด
ทรัพยากรได้ถูกดึงมาจากเครือข่าย ทำให้ไม่เป็นการช่วงชิง
แบนด์วิดท์ นอกจากนี้ เนื่องจากบางรายการที่เรากำลังเตรียมข้อมูลล่วงหน้าไว้อยู่ใน
แคช HTTP ของเบราว์เซอร์ - รายการที่มี (from disk cache)
ในขนาด
เราจะเติมข้อมูลแคชของ Service Worker ได้โดยไม่ต้องไปที่
เครือข่ายอีกครั้ง
จะดีมากหากคุณทำการทดสอบนี้จากอุปกรณ์ระดับโลว์เอนด์จริงใน เครือข่ายมือถือจริง คุณสามารถใช้ประโยชน์จากการแก้ไขข้อบกพร่องระยะไกลของ Chrome ความสามารถ ในการต่อเชื่อมโทรศัพท์ Android เข้ากับเครื่องเดสก์ท็อปผ่าน USB และตรวจสอบให้แน่ใจว่า การทดสอบที่คุณกำลังทำอยู่นั้นจะสะท้อนให้เห็นถึงประสบการณ์จริง ผู้ใช้
บทสรุป
สรุปก็คือ คุณต้องช่วยให้ผู้ใช้ได้รับประสบการณ์การเข้าชมครั้งแรกที่ดีที่สุด ควรมีความสำคัญสูงสุด ชะลอการลงทะเบียน Service Worker ไว้จนกว่าจะพ้นวันที่ หน้าที่โหลดขึ้นระหว่างการเข้าชมครั้งแรก จะช่วยรับประกันเรื่องนี้ คุณจะยังคงได้รับ ประโยชน์ทั้งหมดของการมี Service Worker สำหรับการกลับมาเข้าชมซ้ำ
วิธีที่ตรงไปตรงมาในการชะลอการเริ่มต้นของ Service Worker ลงทะเบียนจนกระทั่งหน้าแรกโหลดเสร็จแล้ว จึงจะใช้รายการต่อไปนี้ได้:
if ('serviceWorker' in navigator) {
window.addEventListener('load', function() {
navigator.serviceWorker.register('/service-worker.js');
});
}