ตอบกลับคำขอการนำทางโดยไม่ต้องรอเครือข่ายโดยใช้โปรแกรมทำงานของบริการ
คำขอการนำทางคือคำขอเอกสาร HTML ที่เบราว์เซอร์สร้างขึ้นเมื่อคุณป้อน URL ใหม่ในแถบนำทาง หรือไปตามลิงก์ในหน้าเว็บที่นำคุณไปยัง URL ใหม่ ซึ่งเป็นจุดที่พนักงานบริการสร้างผลลัพธ์ที่ดีที่สุดต่อประสิทธิภาพการทำงาน หากคุณใช้ Service Worker เพื่อตอบกลับคำขอการนำทางโดยไม่ต้องรอเครือข่าย คุณจะมั่นใจได้ว่าการนำทางนั้นรวดเร็วและเชื่อถือได้ นอกเหนือจากความยืดหยุ่นเมื่อเครือข่ายไม่พร้อมใช้งาน นี่คือชัยชนะด้านประสิทธิภาพที่ใหญ่ที่สุดรายการเดียวที่มาจากโปรแกรมทำงานของบริการ เมื่อเทียบกับสิ่งที่เป็นไปได้จากการแคช HTTP
ตามที่อธิบายไว้ในคำแนะนำระบุทรัพยากรที่โหลดจากเครือข่าย คำขอการนำทางเป็นคำขอแรกที่เป็นไปได้จำนวนมากซึ่งสร้างใน "Waterfall" ของการจราจรของข้อมูลในเครือข่าย HTML ที่คุณโหลดผ่านคำขอการนำทางจะเริ่มต้นโฟลว์ของคำขออื่นๆ ทั้งหมดสำหรับทรัพยากรย่อย เช่น รูปภาพ สคริปต์ และสไตล์
ภายในตัวแฮนเดิลเหตุการณ์ fetch ของ Service Worker คุณระบุได้ว่าคำขอเป็นการนำทางหรือไม่โดยตรวจสอบพร็อพเพอร์ตี้ request.mode ใน FetchEvent หากตั้งค่าเป็น 'navigate'
นั่นจะเป็นคำขอการนำทาง
ตามกฎทั่วไป อย่าใช้ Cache-Control headers ที่มีอายุการใช้งานที่ยาวนานเพื่อแคชการตอบกลับ HTML สำหรับคำขอการนำทาง โดยปกติควรดำเนินการผ่านเครือข่ายโดยมี Cache-Control: no-cache เพื่อดูแลให้ HTML พร้อมกับห่วงโซ่คำขอเครือข่ายที่ตามมา มีความใหม่ (อย่างสมเหตุสมผล) การเข้าไปยังเครือข่ายทุกครั้งที่ผู้ใช้ไปที่หน้าใหม่หมายความว่าการนำทางแต่ละครั้งอาจช้า อย่างน้อยที่สุดก็หมายความว่าแอปจะไม่เร็วน่าเชื่อถือ
วิธีการต่างๆ สำหรับสถาปัตยกรรม
การค้นหาวิธีตอบสนองคำขอการนำทางโดยหลีกเลี่ยงเครือข่ายอาจเป็นเรื่องยุ่งยาก วิธีที่เหมาะสมขึ้นอยู่กับสถาปัตยกรรมของเว็บไซต์และจำนวน URL ที่ไม่ซ้ำกันซึ่งผู้ใช้อาจไปถึง
แม้ว่าจะไม่มีวิธีใดที่จะตอบโจทย์ทุกสถานการณ์ แต่หลักเกณฑ์ทั่วไปต่อไปนี้จะช่วยให้คุณตัดสินใจได้ว่าวิธีใดใช้ได้ผลมากที่สุด
เว็บไซต์แบบคงที่ขนาดเล็ก
หากเว็บแอปมี URL ที่ไม่ซ้ำกันจำนวนหนึ่ง (อย่างเช่น 2-3 โหล) และ URL แต่ละรายการในจำนวนนั้นสอดคล้องกับไฟล์ HTML แบบคงที่อื่นๆ วิธีที่ได้ผลคือ การแคชไฟล์ HTML เหล่านั้นทั้งหมดเท่านั้น และตอบสนองต่อคำขอการนำทางด้วย HTML ที่แคชไว้ที่เหมาะสม
เมื่อใช้การแคชล่วงหน้า คุณจะแคช HTML ล่วงหน้าได้ทันทีที่มีการติดตั้ง Service Worker และอัปเดต HTML ที่แคชทุกครั้งที่คุณสร้างเว็บไซต์อีกครั้งและทำให้ Service Worker ใช้งานได้อีกครั้ง
หรือหากต้องการหลีกเลี่ยงการแคช HTML ทั้งหมดไว้ล่วงหน้า อาจเป็นเพราะผู้ใช้มีแนวโน้มที่จะไปยังชุดย่อยของ URL ในเว็บไซต์เท่านั้น คุณใช้กลยุทธ์การแคชรันไทม์แบบไม่มีอัปเดตขณะตรวจสอบอีกครั้งได้ โปรดระมัดระวังเกี่ยวกับวิธีการนี้ เนื่องจากเอกสาร HTML แต่ละฉบับจะได้รับการแคชและอัปเดตแยกกัน การใช้การแคชรันไทม์สำหรับ HTML เป็นวิธีที่เหมาะสมที่สุดหากคุณมี URL จำนวนเล็กน้อยที่กลุ่มผู้ใช้ชุดเดิมจะกลับมาเข้าชมอีกครั้งบ่อยครั้ง และหากคุณรู้สึกสบายใจที่จะมีการตรวจสอบ URL เหล่านั้นซ้ำแบบเป็นอิสระจากกัน
แอปแบบหน้าเดียว
เว็บแอปพลิเคชันสมัยใหม่มักจะใช้สถาปัตยกรรมแบบหน้าเดียว ในนี้ JavaScript ฝั่งไคลเอ็นต์จะแก้ไข HTML เพื่อตอบสนองต่อการดำเนินการของผู้ใช้ โมเดลนี้ใช้ History API เพื่อแก้ไข URL ปัจจุบันขณะที่ผู้ใช้โต้ตอบกับเว็บแอป ที่นำไปสู่การไปยังส่วนต่างๆ แบบ "จำลอง" ที่มีประสิทธิภาพ แม้ว่าการนำทางที่ตามมาอาจเป็นการ "ปลอม" แต่การนำทางเบื้องต้นนั้นมีอยู่จริง และเป็นเรื่องสำคัญที่จะต้องตรวจสอบว่าไม่มีการบล็อกในเครือข่าย
หากคุณใช้สถาปัตยกรรมแบบหน้าเดียว จะมีรูปแบบที่ตรงไปตรงมาเพื่อให้แสดงการไปยังส่วนต่างๆ ครั้งแรกจากแคช ซึ่งก็คือ Application Shell ในโมเดลนี้ โปรแกรมทำงานของบริการจะตอบสนองต่อคำขอการนำทางโดยการส่งคืนไฟล์ HTML ไฟล์เดียวเดิมที่ถูกแคชล่วงหน้าไว้แล้ว โดยไม่คำนึงถึง URL ที่ขอ HTML นี้ควรเป็นโค้ดที่สมบูรณ์ ประกอบด้วยสัญญาณบอกสถานะการโหลดทั่วไปหรือเนื้อหา เมื่อเบราว์เซอร์โหลด HTML นี้จากแคชแล้ว JavaScript ฝั่งไคลเอ็นต์ที่มีอยู่จะเข้าควบคุมและแสดงเนื้อหา HTML ที่ถูกต้องสำหรับ URL จากคำขอการนำทางเดิม
Workbox มีเครื่องมือที่จำเป็นต่อการนำแนวทางนี้มาใช้ โดย navigateFallback
option ให้คุณระบุเอกสาร HTML ที่จะใช้เป็น App Shell รวมถึงรายการอนุญาตและปฏิเสธที่ไม่บังคับเพื่อจำกัดลักษณะการทำงานนี้ให้กับ URL บางส่วน
แอปแบบหลายหน้า
หากเว็บเซิร์ฟเวอร์ของคุณสร้าง HTML ของเว็บไซต์แบบไดนามิก หรือหากคุณมีหน้าเว็บที่ไม่ซ้ำหลายสิบหน้า การหลีกเลี่ยงเครือข่ายเมื่อจัดการคำขอนำทางจะยากขึ้นมาก คำแนะนำในเรื่องอื่นๆ น่าจะเกี่ยวข้องกับคุณ
แต่สำหรับแอปที่มีหลายหน้าเว็บชุดย่อย คุณอาจใช้ Service Worker ที่จำลองตรรกะที่ใช้ในเว็บเซิร์ฟเวอร์เพื่อสร้าง HTML ได้อย่างสมบูรณ์ ซึ่งจะได้ผลดีที่สุดหากคุณแชร์ข้อมูลการกำหนดเส้นทางและเทมเพลตระหว่างสภาพแวดล้อมของเซิร์ฟเวอร์และ Service Worker โดยเฉพาะเมื่อเว็บเซิร์ฟเวอร์ใช้ JavaScript (โดยไม่ต้องอาศัยฟีเจอร์เฉพาะของ Node.js เช่น การเข้าถึงระบบไฟล์)
หากเว็บเซิร์ฟเวอร์ของคุณอยู่ในหมวดหมู่ดังกล่าว และคุณต้องการสำรวจแนวทางหนึ่งในการย้ายการสร้าง HTML ออกจากเครือข่ายไปยัง Service Worker คำแนะนำใน Beyond SPA: สถาปัตยกรรมทางเลือกสำหรับ PWA จะช่วยให้คุณเริ่มต้นได้
อื่นๆ ที่เหลือ
หากคุณตอบกลับคำขอการนำทางด้วย HTML ที่แคชไว้ไม่ได้ คุณต้องทำตามขั้นตอนเพื่อให้แน่ใจว่าการเพิ่ม Service Worker ลงในเว็บไซต์ (เพื่อจัดการคำขออื่นๆ ที่ไม่ใช่ HTML) จะไม่ทำให้การนำทางช้าลง การเริ่มต้นใช้งาน Service Worker โดยไม่ใช้การตอบกลับคำขอการนำทางจะทำให้ต้องใช้เวลาในการตอบสนองเล็กน้อย (ตามที่อธิบายไว้ในการสร้างแอปที่รวดเร็วและยืดหยุ่นมากขึ้นโดยใช้ Service Worker) คุณลดภาระงานนี้ได้ด้วยการเปิดใช้ฟีเจอร์ที่เรียกว่าการโหลดล่วงหน้าสำหรับการนำทาง จากนั้นใช้การตอบสนองของเครือข่ายที่โหลดไว้ล่วงหน้าภายในตัวแฮนเดิลเหตุการณ์ fetch
Workbox มีไลบรารีตัวช่วยที่ฟีเจอร์ตรวจหาว่าระบบรองรับการโหลดล่วงหน้าของการนำทางหรือไม่ และหากใช่ จะช่วยลดความซับซ้อนของกระบวนการบอกโปรแกรมทำงานของบริการให้ใช้การตอบสนองของเครือข่าย
รูปภาพโดย Aaron Burden ใน Unsplash