โปรแกรมทำงานของบริการและ Cache Storage API

คุณกำลังประสบปัญหาด้านความเสถียรของเครือข่าย แคช HTTP ของเบราว์เซอร์คือด่านแรกในการป้องกัน แต่อย่างที่คุณเรียนรู้ว่า แคชจะมีประสิทธิภาพจริงๆ ก็ต่อเมื่อโหลด URL เวอร์ชันที่คุณเคยเข้าชมก่อนหน้านี้เท่านั้น แค่แคช HTTP อย่างเดียวนั้นไม่เพียงพอ

โชคดีที่มีเครื่องมือใหม่ 2 อย่างพร้อมช่วยคุณเปลี่ยนความต้องการ ได้แก่ โปรแกรมทำงานของบริการ และ Cache Storage API เนื่องจากมีการใช้ชื่อเหล่านี้อยู่บ่อยๆ จึงคุ้มค่าที่จะเรียนรู้เกี่ยวกับทั้ง 2 อย่างนี้ในเวลาเดียวกัน

โปรแกรมทำงานของบริการสร้างขึ้นในเบราว์เซอร์ และควบคุมด้วยโค้ด JavaScript เพิ่มเติมเล็กน้อยที่คุณมีหน้าที่สร้าง ซึ่งคุณจะทำให้ไฟล์นี้ใช้งานได้พร้อมกับไฟล์อื่นๆ ที่ประกอบกันเป็นเว็บแอปพลิเคชันจริงของคุณ

โปรแกรมทำงานของบริการมีความสามารถพิเศษบางอย่าง นอกจากหน้าที่อื่นๆ แล้ว Chrome จะรอให้เว็บแอปส่งคำขอออก จากนั้นเริ่มดำเนินการด้วยการสกัดกั้น คุณจะเป็นผู้กระทำสิ่งที่โปรแกรมทำงานของบริการจะดำเนินการกับคำขอที่ถูกดักจับนี้

สำหรับคำขอบางอย่าง การดำเนินการที่ดีที่สุดอาจเป็นเพียงการอนุญาตคำขอนั้นต่อไปในเครือข่าย เช่นเดียวกับสิ่งที่จะเกิดขึ้นหากไม่มีโปรแกรมทำงานของบริการเลย

อย่างไรก็ตาม สำหรับคำขออื่นๆ คุณจะใช้ประโยชน์จากสิ่งที่มีความยืดหยุ่นมากกว่าแคช HTTP ของเบราว์เซอร์ และให้การตอบสนองที่รวดเร็วและเชื่อถือได้โดยไม่ต้องกังวลเกี่ยวกับเครือข่าย ซึ่งเกี่ยวข้องกับการใช้ปริศนาอีกข้อหนึ่ง ซึ่งก็คือ Cache Storage API

Cache Storage API

การสนับสนุนเบราว์เซอร์

  • 43
  • 16
  • 41
  • 11.1

แหล่งที่มา

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