ตอบสนองต่อคำขอการนำทางโดยไม่ต้องรอเครือข่ายโดยใช้ Service Worker
คำขอการนำทางคือคำขอเอกสาร HTML ที่เบราว์เซอร์สร้างขึ้นเมื่อใดก็ตามที่คุณป้อน URL ใหม่ในแถบนำทาง หรือคลิกลิงก์ในหน้าเว็บที่นำคุณไปยัง URL ใหม่ นี่คือจุดที่ Service Worker มีผลต่อประสิทธิภาพมากที่สุด หากคุณใช้ Service Worker เพื่อตอบสนองต่อคำขอการนำทางโดยไม่ต้องรอเครือข่าย คุณจะมั่นใจได้ว่าการนำทางจะรวดเร็วและเชื่อถือได้ นอกเหนือจากความยืดหยุ่นเมื่อเครือข่ายไม่พร้อมใช้งาน นี่คือประสิทธิภาพที่เพิ่มขึ้นมากที่สุดเพียงอย่างเดียวที่มาจาก 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 เพียงบางส่วนในเว็บไซต์) คุณสามารถใช้กลยุทธ์การแคชรันไทม์ stale-while-revalidate ได้ อย่างไรก็ตาม โปรดระมัดระวังเกี่ยวกับแนวทางนี้ เนื่องจากเอกสาร HTML แต่ละรายการจะได้รับการแคชและอัปเดตแยกกัน การใช้การแคชรันไทม์สำหรับ HTML เหมาะสมที่สุดหากคุณมี URL จำนวนน้อยที่ผู้ใช้กลุ่มเดียวกันกลับมาเข้าชมบ่อยครั้ง และหากคุณพอใจที่ URL เหล่านั้นได้รับการตรวจสอบซ้ำโดยไม่ขึ้นต่อกัน
แอปหน้าเดียว
เว็บแอปพลิเคชันสมัยใหม่มักใช้สถาปัตยกรรมหน้าเว็บเดียว ในกรณีนี้ JavaScript ฝั่งไคลเอ็นต์จะแก้ไข HTML เพื่อตอบสนองต่อการกระทำของผู้ใช้ โมเดลนี้ใช้ History API เพื่อแก้ไข URL ปัจจุบันเมื่อผู้ใช้โต้ตอบกับเว็บแอป ซึ่งนำไปสู่การไปยังส่วนต่างๆ ที่ "จำลอง" ขึ้นมาอย่างมีประสิทธิภาพ แม้ว่าการนําทางที่ตามมาอาจเป็น "ของปลอม" แต่การนําทางเริ่มต้นนั้นเป็นของจริง และยังคงเป็นสิ่งสําคัญที่จะต้องตรวจสอบว่าไม่ได้ถูกบล็อกในเครือข่าย
โชคดีที่หากคุณใช้สถาปัตยกรรมหน้าเว็บเดียว จะมีรูปแบบที่ตรงไปตรงมาให้ทำตามเพื่อแสดงการนำทางครั้งแรกจากแคช ซึ่งก็คือ Application Shell ในโมเดลนี้ Service Worker จะตอบสนองต่อคำขอการนำทางโดยแสดงผลไฟล์ HTML ไฟล์เดียวกับที่แคชไว้ล่วงหน้า ไม่ว่าจะเป็น URL ใดก็ตามที่ขอ HTML นี้ควรเป็นแบบพื้นฐาน ซึ่งอาจประกอบด้วยสัญญาณบอกสถานะการโหลดทั่วไปหรือเนื้อหาโครงร่าง เมื่อเบราว์เซอร์โหลด HTML นี้จากแคชแล้ว JavaScript ฝั่งไคลเอ็นต์ที่มีอยู่จะเข้ามาแทนที่ และแสดงผลเนื้อหา HTML ที่ถูกต้องสำหรับ URL จากคำขอการนำทางเดิม
Workbox มีเครื่องมือที่จำเป็นสำหรับการใช้วิธีนี้ โดย navigateFallback
option จะช่วยให้คุณระบุเอกสาร HTML ที่จะใช้เป็น App Shell พร้อมกับรายการที่อนุญาตและปฏิเสธ (ไม่บังคับ) เพื่อจำกัดลักษณะการทำงานนี้ไว้เฉพาะ URL บางส่วน
แอปแบบหลายหน้า
หากเว็บเซิร์ฟเวอร์สร้าง HTML ของเว็บไซต์แบบไดนามิก หรือหากคุณมีหน้าเว็บที่ไม่ซ้ำกันมากกว่า 2-3 โหล การหลีกเลี่ยงเครือข่ายเมื่อจัดการคำขอการนำทางจะทำได้ยากขึ้นมาก คำแนะนำในอื่นๆ น่าจะใช้กับคุณได้
แต่สำหรับแอปหลายหน้าบางชุดย่อย คุณอาจใช้ Service Worker ที่จำลองตรรกะที่ใช้ในเว็บเซิร์ฟเวอร์เพื่อสร้าง HTML ได้อย่างสมบูรณ์ วิธีนี้จะได้ผลดีที่สุดหากคุณสามารถแชร์ข้อมูลการกำหนดเส้นทางและเทมเพลตระหว่างสภาพแวดล้อมของเซิร์ฟเวอร์และ Service Worker และโดยเฉพาะอย่างยิ่งหากเว็บเซิร์ฟเวอร์ใช้ JavaScript (โดยไม่ต้องอาศัยฟีเจอร์เฉพาะของ Node.js เช่น การเข้าถึงระบบไฟล์)
หากเว็บเซิร์ฟเวอร์ของคุณอยู่ในหมวดหมู่นั้นและคุณต้องการสำรวจแนวทางหนึ่งในการย้ายการสร้าง HTML ออกจากเครือข่ายและไปยัง Service Worker คำแนะนำในนอกเหนือจาก SPA: สถาปัตยกรรมทางเลือกสำหรับ PWA จะช่วยให้คุณเริ่มต้นได้
อื่นๆ ที่เหลือ
หากตอบสนองต่อคำขอการนำทางด้วย HTML ที่แคชไว้ไม่ได้ คุณต้องทำตามขั้นตอนเพื่อให้แน่ใจว่าการเพิ่ม Service Worker ลงในเว็บไซต์ (เพื่อจัดการคำขออื่นๆ ที่ไม่ใช่ HTML) จะไม่ทำให้การนำทางช้าลง การเริ่มต้น Service Worker โดยไม่ใช้เพื่อตอบสนองต่อคำขอการนำทางจะทำให้เกิดเวลาในการตอบสนองเล็กน้อย (ตามที่อธิบายไว้ในการสร้างแอปที่รวดเร็วและยืดหยุ่นมากขึ้นด้วย Service Worker) คุณลดโอเวอร์เฮดนี้ได้โดยเปิดใช้ฟีเจอร์ที่ชื่อว่าการโหลดการนำทางล่วงหน้า แล้วใช้การตอบสนองของเครือข่ายที่โหลดไว้ล่วงหน้าภายในเครื่องจัดการเหตุการณ์ fetch
Workbox มีไลบรารีตัวช่วยที่ตรวจหาฟีเจอร์ว่าระบบรองรับการโหลดการนำทางล่วงหน้าหรือไม่ และหากรองรับ ก็จะลดความซับซ้อนของกระบวนการบอก Service Worker ให้ใช้การตอบสนองของเครือข่าย