ตอบสนองคําขอการนําทางโดยไม่ต้องรอเครือข่ายโดยใช้ Service Worker
คำขอการนําทางคือคําขอเอกสาร HTML ที่เบราว์เซอร์สร้างขึ้นทุกครั้งที่คุณป้อน URL ใหม่ในแถบนําทาง หรือทําตามลิงก์ในหน้าเว็บซึ่งนําคุณไปยัง URL ใหม่ การดำเนินการนี้ทำให้ Service Worker ส่งผลต่อประสิทธิภาพมากที่สุด หากคุณใช้ Service Worker เพื่อตอบสนองคำขอการไปยังส่วนต่างๆ โดยไม่ต้องรอเครือข่าย คุณจะมั่นใจได้ว่าการไปยังส่วนต่างๆ จะรวดเร็วและเชื่อถือได้ ทั้งยังยืดหยุ่นเมื่อเครือข่ายไม่พร้อมใช้งาน นี่เป็นการเพิ่มประสิทธิภาพที่ใหญ่ที่สุดอย่างหนึ่งที่ได้จาก Service Worker เมื่อเทียบกับสิ่งที่ทำได้ด้วย HTTP caching
ดังที่อธิบายไว้ในคู่มือระบุทรัพยากรที่โหลดจากเครือข่าย คําขอไปยังส่วนต่างๆ ของเว็บไซต์เป็นคําขอแรกใน"การแสดงโฆษณาตามลำดับขั้น" ของการเข้าชมเครือข่าย ซึ่งอาจมีหลายรายการ 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 พื้นฐาน ซึ่งประกอบด้วยตัวบ่งชี้การโหลดทั่วไปหรือเนื้อหาโครงร่าง เมื่อเบราว์เซอร์โหลด HTML นี้จากแคชแล้ว JavaScript ฝั่งไคลเอ็นต์ที่มีอยู่จะเข้ามาทำงานแทน และแสดงผลเนื้อหา HTML ที่ถูกต้องสำหรับ URL จากคำขอการนําทางเดิม
Workbox มีเครื่องมือที่จําเป็นต่อการใช้แนวทางนี้ โดย navigateFallback
option
ช่วยให้คุณระบุเอกสาร HTML ที่จะใช้เป็นเชลล์แอปได้ พร้อมกับรายการที่อนุญาตและปฏิเสธที่ไม่บังคับเพื่อจํากัดลักษณะการทํางานนี้ให้อยู่เฉพาะ 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 ให้ใช้การตอบกลับของเครือข่าย
รูปภาพโดย Aaron Burden ใน Unsplash