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

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

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

แคชไฟล์ Manifest ล่วงหน้า

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

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

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

การแสดงทรัพยากรที่แคชไว้ล่วงหน้า

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

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

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

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

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

หากมี 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 ของแคชล่วงหน้า รวมถึงขนาดทั้งหมดของเพย์โหลดแคชล่วงหน้า

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