คุณกำลังประสบปัญหาด้านความเสถียรของเครือข่าย แคช HTTP ของเบราว์เซอร์คือด่านแรกในการป้องกัน แต่อย่างที่คุณเรียนรู้ว่า แคชจะมีประสิทธิภาพจริงๆ ก็ต่อเมื่อโหลด URL เวอร์ชันที่คุณเคยเข้าชมก่อนหน้านี้เท่านั้น แค่แคช HTTP อย่างเดียวนั้นไม่เพียงพอ
โชคดีที่มีเครื่องมือใหม่ 2 อย่างพร้อมช่วยคุณเปลี่ยนความต้องการ ได้แก่ โปรแกรมทำงานของบริการ และ Cache Storage API เนื่องจากมีการใช้ชื่อเหล่านี้อยู่บ่อยๆ จึงคุ้มค่าที่จะเรียนรู้เกี่ยวกับทั้ง 2 อย่างนี้ในเวลาเดียวกัน
Service Worker
โปรแกรมทำงานของบริการสร้างขึ้นในเบราว์เซอร์ และควบคุมด้วยโค้ด JavaScript เพิ่มเติมเล็กน้อยที่คุณมีหน้าที่สร้าง ซึ่งคุณจะทำให้ไฟล์นี้ใช้งานได้พร้อมกับไฟล์อื่นๆ ที่ประกอบกันเป็นเว็บแอปพลิเคชันจริงของคุณ
โปรแกรมทำงานของบริการมีความสามารถพิเศษบางอย่าง นอกจากหน้าที่อื่นๆ แล้ว Chrome จะรอให้เว็บแอปส่งคำขอออก จากนั้นเริ่มดำเนินการด้วยการสกัดกั้น คุณจะเป็นผู้กระทำสิ่งที่โปรแกรมทำงานของบริการจะดำเนินการกับคำขอที่ถูกดักจับนี้
สำหรับคำขอบางอย่าง การดำเนินการที่ดีที่สุดอาจเป็นเพียงการอนุญาตคำขอนั้นต่อไปในเครือข่าย เช่นเดียวกับสิ่งที่จะเกิดขึ้นหากไม่มีโปรแกรมทำงานของบริการเลย
อย่างไรก็ตาม สำหรับคำขออื่นๆ คุณจะใช้ประโยชน์จากสิ่งที่มีความยืดหยุ่นมากกว่าแคช HTTP ของเบราว์เซอร์ และให้การตอบสนองที่รวดเร็วและเชื่อถือได้โดยไม่ต้องกังวลเกี่ยวกับเครือข่าย ซึ่งเกี่ยวข้องกับการใช้ปริศนาอีกข้อหนึ่ง ซึ่งก็คือ Cache Storage API
Cache Storage API
Cache Storage API จะเปิดโอกาสให้คุณได้รับประสบการณ์ใหม่ๆ โดยให้นักพัฒนาซอฟต์แวร์ควบคุมเนื้อหาของแคชได้อย่างเต็มที่ แทนที่จะอาศัยทั้งส่วนหัว HTTP และheuristicsในตัวของเบราว์เซอร์ Cache Storage API จะใช้วิธีการแคชโดยใช้โค้ด Cache Storage API จะมีประโยชน์อย่างยิ่งเมื่อเรียกใช้จาก JavaScript ของโปรแกรมทำงานของบริการ
เดี๋ยวนะ... มีแคชอื่นให้คิดไหม
คุณอาจถามตัวเองว่า "ฉันยังต้องกำหนดค่าส่วนหัว 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 เพียงอย่างเดียวมีดังนี้
- ใช้วิธีการ "รีเฟรชในพื้นหลัง" สำหรับเนื้อหาที่แคชไว้ ซึ่งเรียกว่า "ไม่มีอัปเดตขณะตรวจสอบความถูกต้องอีกครั้ง"
- กำหนดขีดจำกัดจำนวนสูงสุดของเนื้อหาที่จะแคช และใช้นโยบายวันหมดอายุที่กำหนดเองเพื่อนำรายการออกเมื่อถึงขีดจำกัดนั้น
- เปรียบเทียบการตอบกลับของเครือข่ายที่แคชไว้และใหม่และเก่าเพื่อดูว่ามีการเปลี่ยนแปลงใดๆ หรือไม่ และช่วยให้ผู้ใช้อัปเดตเนื้อหาได้ (เช่น ใช้ปุ่ม) เมื่อมีการอัปเดตข้อมูลจริงๆ
ดูข้อมูลเพิ่มเติมได้ที่ Cache API: คู่มือฉบับย่อ
น็อตและน็อต API
สิ่งที่ควรทราบเกี่ยวกับการออกแบบของ API มีดังนี้
Requestระบบจะใช้ออบเจ็กต์เป็นคีย์ที่ไม่ซ้ำกันเมื่ออ่านและเขียนลงในแคชเหล่านี้ เพื่อความสะดวก คุณสามารถส่งสตริง URL เช่น'https://example.com/index.html'เป็นคีย์แทนออบเจ็กต์Requestจริงและ API จะจัดการให้คุณโดยอัตโนมัติResponseระบบจะใช้ออบเจ็กต์เป็นค่าในแคชเหล่านี้- ระบบจะละเว้นส่วนหัว
Cache-ControlในResponseที่ระบุเมื่อแคชข้อมูล ไม่มีการตรวจสอบวันหมดอายุในตัวหรือการตรวจสอบความใหม่โดยอัตโนมัติ และเมื่อคุณจัดเก็บรายการไว้ในแคช รายการดังกล่าวจะยังคงอยู่จนกว่าโค้ดจะนำออกอย่างชัดเจน (มีไลบรารีที่จะช่วยให้คุณดูแล แคชได้ง่ายขึ้น ซึ่งจะกล่าวถึงในภายหลังในซีรีส์นี้) - ซึ่งแตกต่างจาก API แบบซิงโครนัสเก่าอย่าง
LocalStorageตรงที่การดำเนินการ Cache Storage API ทั้งหมดเป็นแบบอะซิงโครนัส
อ้อมไปอย่างรวดเร็ว: สัญญาและไม่ซิงค์/รอ
โปรแกรมทำงานของบริการและ Cache Storage API จะใช้แนวคิดการเขียนโปรแกรมแบบไม่พร้อมกัน
โดยเฉพาะอย่างยิ่ง โซลูชันเหล่านี้อาศัยคำสัญญาเป็นหลักเพื่อแสดงผลลัพธ์ในอนาคตของการดำเนินการแบบไม่พร้อมกัน คุณควรทำความคุ้นเคยกับ
สัญญา
และไวยากรณ์
async/await
ที่เกี่ยวข้องก่อนที่จะเจาะลึก
อย่าเพิ่งทำให้โค้ดนี้ใช้งานได้...
แม้ว่าฟีเจอร์เหล่านี้จะเป็นรากฐานที่สำคัญและใช้งานได้ตามที่เป็นอยู่ แต่ทั้งโปรแกรมทำงานของบริการและ Cache Storage API ต่างก็เป็นองค์ประกอบที่ใช้สร้างสรรค์ในระดับต่ำลงมาอย่างมีประสิทธิภาพ ทั้งยังมีกรณีสุดโต่งและ "ปัญหา" จำนวนมาก มีเครื่องมือระดับสูงบางอย่างที่ช่วยปรับส่วนที่ยากของ API เหล่านั้นให้ราบรื่น และมอบทุกอย่างที่คุณต้องการสำหรับสร้าง Service Worker ที่พร้อมสำหรับเวอร์ชันที่ใช้งานจริง คำแนะนำถัดไปจะกล่าวถึงเครื่องมือดังกล่าวซึ่งได้แก่ Workbox