การแคชล่วงหน้าด้วย Workbox

เจฟฟ์ พอสนิก

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

เหตุใดจึงควรใช้ Workbox

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

ไฟล์ Manifest สำหรับแคชล่วงหน้า

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

[{
  url: 'app.abcd1234.js'
}, {
  url: 'offline.svg',
  revision: '7836745f'
}, {
  url: 'index.html',
  revision: '518747aa'
}]

เมื่อติดตั้ง Service Worker แล้ว ระบบจะสร้างรายการแคช 3 รายการในพื้นที่เก็บข้อมูลแคช สำหรับ URL ทั้ง 3 รายการที่ระบุ เนื้อหาแรกมีข้อมูลการกำหนดเวอร์ชันรวมอยู่ใน URL แล้ว (app คือชื่อไฟล์จริงและ .abcd1234 มีข้อมูลการกำหนดเวอร์ชันอยู่ก่อนนามสกุลไฟล์ .js) เครื่องมือสร้างของ Workbox สามารถตรวจจับได้และยกเว้นช่องการแก้ไข เนื้อหาอีก 2 รายการจะไม่รวมข้อมูลการกำหนดเวอร์ชันใน URL เครื่องมือสร้างของ Workbox จะสร้างช่อง revision แยกต่างหากโดยมีแฮชเนื้อหาของไฟล์ในเครื่อง

การแสดงทรัพยากรที่จัดเก็บในแคชล่วงหน้า

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

การอัปเดตที่มีประสิทธิภาพ

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

การอัปเดตทรัพยากรที่จัดเก็บในแคชล่วงหน้า

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

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

[{
  url: 'app.ffaa4455.js'
}, {
  url: 'offline.svg',
  revision: '7836745f'
}, {
  url: 'index.html',
  revision: '518747aa'
}]

การเปลี่ยนแปลงแต่ละรายการจะบอกให้ Service Worker ทราบว่าต้องมีคำขอใหม่เพื่ออัปเดตรายการที่แคชไว้ก่อนหน้านี้ ('offline.svg' และ 'index.html') และแคช URL ใหม่ ('app.ffaa4455.js') รวมถึงการลบเพื่อล้าง URL ที่ไม่มีการใช้งานแล้ว ('app.abcd1234.js')

ประสบการณ์การติดตั้ง "App Store" ที่แท้จริง

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

เมื่อติดตั้งแอป ผู้ใช้คาดหวังให้ส่วนต่างๆ แสดงอย่างรวดเร็ว ไม่ใช่แค่ยอดดูที่ผ่านมา การแคชล่วงหน้าช่วยให้ เว็บแอปได้รับประสบการณ์แบบเดียวกัน

เนื้อหาใดควรแคชล่วงหน้า

ให้กลับไปที่คำแนะนำในการระบุสิ่งที่กำลังโหลดเพื่อให้เห็นภาพรวมว่า URL ใดเหมาะกับการแคชล่วงหน้ามากที่สุด กฎทั่วไปคือให้แคช HTML, JavaScript หรือ CSS ที่โหลดไว้ก่อนล่วงหน้าและสำคัญต่อการแสดงโครงสร้างพื้นฐานของหน้าเว็บหนึ่งๆ

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

โปรดทราบว่าการแคชล่วงหน้าต้องใช้แบนด์วิดท์ของเครือข่ายและพื้นที่เก็บข้อมูลในอุปกรณ์ของผู้ใช้ (เหมือนกับการติดตั้งแอปจาก App Store) คุณในฐานะนักพัฒนาซอฟต์แวร์ต้องแคชล่วงหน้าอย่างรอบคอบ และหลีกเลี่ยงไฟล์ Manifest ที่มีขนาดใหญ่ผิดปกติ

เครื่องมือสร้างของ Workbox จะช่วยบอกจำนวนรายการในไฟล์ Manifest ของแคชล่วงหน้า รวมถึงขนาดโดยรวมของเพย์โหลดสำหรับแคชล่วงหน้า

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