คุณกำลังติดอยู่ในการต่อสู้เพื่อความเสถียรของเครือข่าย แคช HTTP ของเบราว์เซอร์เป็นแนวป้องกันแรก แต่ดังที่ได้ทราบแล้วว่าแคชนี้จะมีประสิทธิภาพก็ต่อเมื่อโหลด URL ที่กำหนดเวอร์ชันซึ่งคุณเคยเข้าชมก่อนหน้านี้เท่านั้น แคช HTTP เพียงอย่างเดียวไม่เพียงพอ
โชคดีที่เรามีเครื่องมือใหม่ 2 รายการที่จะช่วยพลิกสถานการณ์ให้เป็นไปตามที่คุณต้องการ ได้แก่ Service Worker และ Cache Storage API เนื่องจากมักใช้ร่วมกันบ่อยครั้ง จึงควรเรียนรู้ทั้ง 2 อย่างไปพร้อมกัน
Service Worker
Service Worker จะติดตั้งมาในเบราว์เซอร์และควบคุมโดยโค้ด JavaScript เพิ่มเติมเล็กน้อยที่คุณมีหน้าที่สร้าง คุณจะติดตั้งใช้งานไฟล์นี้ควบคู่ไปกับไฟล์อื่นๆ ที่ประกอบกันเป็นเว็บแอปพลิเคชันจริง
Service Worker มีความสามารถพิเศษบางอย่าง หน้าที่หนึ่งของ Service Worker คือการรออย่างอดทนให้เว็บแอปส่งคำขอขาออก แล้วจึงเริ่มทำงานโดยการสกัดกั้นคำขอนั้น สิ่งที่คุณต้องการให้ Service Worker ทำกับคำขอที่ถูกสกัดกั้นนี้ขึ้นอยู่กับคุณ
สำหรับคำขอบางรายการ แนวทางปฏิบัติที่ดีที่สุดอาจเป็นเพียงการอนุญาตให้คำขอดำเนินการต่อในเครือข่าย เช่นเดียวกับสิ่งที่จะเกิดขึ้นหากไม่มี Service Worker เลย
อย่างไรก็ตาม สำหรับคำขออื่นๆ คุณสามารถใช้ประโยชน์จากสิ่งที่ยืดหยุ่นกว่าแคช HTTP ของเบราว์เซอร์ และแสดงการตอบกลับที่รวดเร็วและเชื่อถือได้โดยไม่ต้องกังวลเกี่ยวกับเครือข่าย ซึ่งหมายความว่าต้องใช้จิ๊กซอว์อีกชิ้นหนึ่ง นั่นคือ Cache Storage API
Cache Storage API
Cache Storage API เปิดโอกาสใหม่ๆ มากมายด้วยการให้นักพัฒนาแอปควบคุมเนื้อหาของแคชได้อย่างสมบูรณ์ Cache Storage API แสดงแนวทางที่ขับเคลื่อนด้วยโค้ดสำหรับการแคช แทนที่จะอาศัยการผสมผสานระหว่างส่วนหัว HTTP และฮิวริสติกในตัวของเบราว์เซอร์ Cache Storage API จะมีประโยชน์อย่างยิ่งเมื่อเรียกใช้จาก JavaScript ของ Service Worker
เดี๋ยวนะ… มีแคชอีกประเภทที่ต้องพิจารณาด้วยเหรอ
คุณอาจกำลังถามตัวเองด้วยคำถามต่างๆ เช่น "ฉันยังต้องกำหนดค่าส่วนหัว HTTP อยู่ไหม" และ "ฉันจะทำอะไรกับแคชใหม่นี้ได้บ้างซึ่งทำไม่ได้ด้วยแคช HTTP" ไม่ต้องกังวล เพราะนั่นเป็นปฏิกิริยาปกติ
เรายังคงแนะนำให้คุณกำหนดค่าส่วนหัว Cache-Control ในเว็บเซิร์ฟเวอร์ แม้ว่าคุณจะทราบว่ากำลังใช้ Cache Storage API อยู่ก็ตาม โดยปกติแล้ว คุณสามารถตั้งค่า Cache-Control: no-cache สำหรับ URL ที่ไม่มีเวอร์ชัน และ/หรือ Cache-Control: max-age=31536000 สำหรับ URL ที่มีข้อมูลการกำหนดเวอร์ชัน เช่น แฮช
เมื่อป้อนข้อมูลแคช Cache Storage API เบราว์เซอร์จะตรวจสอบรายการที่มีอยู่โดยค่าเริ่มต้นในแคช HTTP และใช้รายการเหล่านั้นหากพบ หากคุณเพิ่ม URL ที่กำหนดเวอร์ชันลงในแคช Cache Storage API เบราว์เซอร์จะหลีกเลี่ยงคำขอเครือข่ายเพิ่มเติม ในทางกลับกัน หากคุณใช้ส่วนหัว Cache-Control ที่กำหนดค่าไม่ถูกต้อง เช่น การระบุอายุการใช้งานแคชที่ยาวนานสำหรับ URL ที่ไม่มีเวอร์ชัน คุณอาจทำให้สถานการณ์แย่ลงด้วยการเพิ่มเนื้อหาที่ล้าสมัยลงใน Cache Storage API การจัดเรียงลักษณะการทำงานของแคช HTTP เป็นข้อกำหนดเบื้องต้นสำหรับการใช้ Cache Storage API อย่างมีประสิทธิภาพ
คำตอบสำหรับคำถามที่ว่า API ใหม่นี้ทำอะไรได้บ้างก็คือ ทำได้หลายอย่าง ตัวอย่างการใช้งานทั่วไปที่ทำได้ยากหรือเป็นไปไม่ได้เลยหากใช้เพียงแคช HTTP ได้แก่
- ใช้แนวทาง "รีเฟรชในเบื้องหลัง" กับเนื้อหาที่แคชไว้ ซึ่งเรียกว่า stale-while-revalidate
- กำหนดขีดจำกัดจำนวนชิ้นงานสูงสุดที่จะแคช และใช้นโยบายการหมดอายุที่กำหนดเองเพื่อนำรายการออกเมื่อถึงขีดจำกัดนั้น
- เปรียบเทียบการตอบสนองของเครือข่ายที่แคชไว้ก่อนหน้านี้กับการตอบสนองใหม่เพื่อดูว่ามีการเปลี่ยนแปลงหรือไม่ และอนุญาตให้ผู้ใช้อัปเดตเนื้อหา (เช่น ด้วยปุ่ม) เมื่อมีการอัปเดตข้อมูลจริง
ดูข้อมูลเพิ่มเติมได้ที่คู่มือฉบับย่อเกี่ยวกับ Cache API
รายละเอียดเกี่ยวกับ API
สิ่งที่ควรคำนึงถึงเกี่ยวกับการออกแบบ API มีดังนี้
- ระบบจะใช้ออบเจ็กต์
Requestเป็นคีย์ที่ไม่ซ้ำกันเมื่ออ่านและเขียนลงในแคชเหล่านี้ เพื่อความสะดวก คุณสามารถส่งสตริง URL เช่น'https://example.com/index.html'เป็นคีย์แทนออบเจ็กต์Requestจริง และ API จะจัดการให้คุณโดยอัตโนมัติ - ระบบจะใช้ออบเจ็กต์
Responseเป็นค่าในแคชเหล่านี้ - ระบบจะไม่สนใจส่วนหัว
Cache-ControlในResponseที่ระบุเมื่อแคชข้อมูล ไม่มีการตรวจสอบการหมดอายุหรือความใหม่ในตัวโดยอัตโนมัติ และเมื่อคุณจัดเก็บรายการในแคช รายการนั้นจะยังคงอยู่จนกว่าโค้ดจะนำออกอย่างชัดแจ้ง (มีไลบรารีที่ช่วยให้การบำรุงรักษาแคชง่ายขึ้นในนามของคุณ เราจะพูดถึงเรื่องนี้ในภายหลังในซีรีส์นี้) - การดำเนินการทั้งหมดของ Cache Storage API จะเป็นแบบอะซิงโครนัส ซึ่งต่างจาก API แบบซิงโครนัสรุ่นเก่า เช่น
LocalStorage
ทางอ้อมสั้นๆ: Promise และ async/await
Service Worker และ Cache Storage API ใช้แนวคิดการเขียนโปรแกรมแบบอะซิงโครนัส
โดยเฉพาะอย่างยิ่ง การใช้ Promise เพื่อแสดงผลลัพธ์ในอนาคตของการดำเนินการแบบไม่พร้อมกัน คุณควรทำความคุ้นเคยกับ promises และไวยากรณ์ async/await ที่เกี่ยวข้องก่อนที่จะเจาะลึก
อย่าเพิ่งติดตั้งใช้งานโค้ดนั้น
แม้ว่าทั้ง Service Worker และ Cache Storage API จะเป็นรากฐานที่สำคัญและสามารถใช้ได้ตามที่เป็นอยู่ แต่ก็เป็นองค์ประกอบระดับต่ำกว่าที่มีประสิทธิภาพ โดยมีกรณีสุดโต่งและ "ข้อผิดพลาด" จำนวนมาก มีเครื่องมือระดับสูงบางอย่างที่ช่วยให้ส่วนที่ยากของ API เหล่านั้นราบรื่นขึ้น และมอบทุกสิ่งที่คุณต้องการเพื่อสร้าง Service Worker ที่พร้อมใช้งานจริง คู่มือถัดไปจะครอบคลุมเครื่องมือดังกล่าว ซึ่งก็คือ Workbox