ตอบกลับคำขอการนำทางโดยไม่ต้องรอเครือข่ายโดยใช้ Service Worker
คำขอการนำทางเป็นคำขอเอกสาร HTML ที่เบราว์เซอร์สร้างขึ้นทุกครั้งที่คุณป้อน URL ใหม่ในแถบนำทาง หรือตามลิงก์ในหน้าเว็บที่พาไปยัง URL ใหม่ จุดนี้เองที่บริการทำงานของบริการจะส่งผลต่อประสิทธิภาพมากที่สุด นั่นคือหากคุณใช้ 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 ที่ไม่ซ้ำกันจำนวนค่อนข้างน้อย (น่าจะประมาณ 20 สิบรายการ) และแต่ละ 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 ออกจากเครือข่ายไปยังโปรแกรมทำงานของบริการ โปรดดูคำแนะนำใน Beyond SPA: สถาปัตยกรรมทางเลือกสำหรับ PWA
อื่นๆ ที่เหลือ
หากไม่สามารถตอบกลับคำขอการนำทางด้วย HTML ที่แคชไว้ คุณต้องดำเนินการเพื่อให้มั่นใจว่าการเพิ่ม Service Worker ลงในเว็บไซต์ (เพื่อจัดการคำขออื่นๆ ที่ไม่ใช่ HTML) จะไม่ทำให้การนำทางช้าลง การเริ่มต้นใช้งาน Service Worker โดยไม่ใช้โปรแกรมดังกล่าวในการตอบกลับคำขอการนำทางจะทำให้ใช้เวลาในการตอบสนองเล็กน้อย (ตามที่อธิบายไว้ในการสร้างแอปที่รวดเร็วขึ้นและยืดหยุ่นมากขึ้นด้วยโปรแกรมทำงานของบริการ) คุณลดค่าใช้จ่ายนี้ได้โดยเปิดใช้ฟีเจอร์ที่เรียกว่าการโหลดล่วงหน้าสำหรับการนำทาง จากนั้นใช้การตอบสนองของเครือข่ายที่โหลดไว้ล่วงหน้าภายในเครื่องจัดการเหตุการณ์ fetch
Workbox มีไลบรารีตัวช่วยที่มีฟีเจอร์ตรวจสอบว่ารองรับการโหลดการนำทางล่วงหน้าหรือไม่ และหากรองรับ ก็จะช่วยให้กระบวนการบอกโปรแกรมทำงานของบริการใช้การตอบสนองของเครือข่ายได้ง่ายขึ้น
รูปภาพโดย Aaron Burden ใน Unsplash