ข้อดีและข้อเสียของการใช้ตรรกะการหมดอายุที่สอดคล้องกันหรือแตกต่างกันในแคชของ Service Worker และเลเยอร์แคช HTTP
ในขณะที่ Service Worker และ PWA กลายเป็นมาตรฐานของเว็บแอปพลิเคชันสมัยใหม่ การแคชทรัพยากรก็ซับซ้อนกว่าที่เคย บทความนี้ครอบคลุมภาพรวมของการแคชเบราว์เซอร์ ซึ่งรวมถึง
- กรณีการใช้งานและความแตกต่างระหว่างการแคช Service Worker และการแคช HTTP
- ข้อดีและข้อเสียของกลยุทธ์การแคชเวลาหมดอายุของพนักงานบริการที่แตกต่างกันเมื่อเทียบกับกลยุทธ์การแคช HTTP แบบปกติ
ภาพรวมของขั้นตอนการแคช
ในระดับสูง เบราว์เซอร์จะเป็นไปตามลำดับการแคชด้านล่างเมื่อขอทรัพยากร:
- แคชของ Service Worker: โปรแกรมทำงานของบริการจะตรวจสอบว่าทรัพยากรอยู่ในแคชหรือไม่และตัดสินใจว่าจะส่งคืนทรัพยากรนั้นเองตามกลยุทธ์การแคชที่ตั้งโปรแกรมไว้หรือไม่ โปรดทราบว่าปัญหานี้จะไม่เกิดขึ้นโดยอัตโนมัติ คุณต้องสร้างเครื่องจัดการเหตุการณ์การดึงข้อมูลใน Service Worker และสกัดกั้นคำขอของเครือข่ายเพื่อให้คำขอนั้นแสดงจากแคชของผู้ปฏิบัติงานบริการแทนที่จะเป็นเครือข่าย
- แคช HTTP (หรือที่เรียกว่าแคชของเบราว์เซอร์): หากพบทรัพยากรในแคช HTTP และยังไม่หมดอายุ เบราว์เซอร์จะใช้ทรัพยากรจากแคช HTTP โดยอัตโนมัติ
- ฝั่งเซิร์ฟเวอร์: หากไม่พบอะไรในแคชของโปรแกรมทำงานของบริการหรือแคช HTTP เบราว์เซอร์จะไปที่เครือข่ายเพื่อขอทรัพยากร หากทรัพยากรไม่ได้แคชใน CDN คำขอต้องกลับไปที่เซิร์ฟเวอร์ต้นทางจนสุด
การแคชเลเยอร์
การแคช Service Worker
โปรแกรมทำงานของบริการจะสกัดกั้นคำขอ HTTP ประเภทเครือข่าย และใช้กลยุทธ์การแคชเพื่อกำหนดทรัพยากรที่ควรส่งกลับไปยังเบราว์เซอร์ แคชของโปรแกรมทำงานของบริการและแคช HTTP มีจุดประสงค์ทั่วไปเดียวกัน แต่แคชของโปรแกรมทำงานของบริการมีความสามารถในการแคชมากกว่า เช่น การควบคุมแบบละเอียดสำหรับสิ่งที่แคชและวิธีการแคช
การควบคุมแคชของ Service Worker
โปรแกรมทำงานของบริการจะสกัดกั้นคำขอ HTTP ด้วย Event Listener (โดยปกติจะเป็นเหตุการณ์ fetch
) ข้อมูลโค้ดนี้จะแสดงตรรกะของกลยุทธ์การแคชแบบ Cache-First
เราขอแนะนำเป็นอย่างยิ่งให้ใช้ Workbox เพื่อหลีกเลี่ยงการพลิกโฉมการใช้งาน ตัวอย่างเช่น คุณอาจลงทะเบียนเส้นทาง URL ทรัพยากรด้วยโค้ดนิพจน์ทั่วไปบรรทัดเดียวได้
import {registerRoute} from 'workbox-routing';
registerRoute(new RegExp('styles/.*\\.css'), callbackHandler);
กลยุทธ์และกรณีการใช้งานสำหรับการแคชโปรแกรมทำงาน
ตารางถัดไปจะสรุปกลยุทธ์การแคชโปรแกรมทำงานทั่วไปและกรณีที่แต่ละกลยุทธ์มีประโยชน์
กลยุทธ์ | เหตุผลด้านความใหม่ | กรณีการใช้งาน |
---|---|---|
เครือข่าย เท่านั้น | เนื้อหาต้องเป็นปัจจุบันตลอดเวลา |
|
เครือข่าย กลับไปใช้แคช | แต่ควรแสดงเนื้อหาใหม่ อย่างไรก็ตาม หากเครือข่ายล้มเหลวหรือไม่เสถียร เราก็อนุญาตให้แสดงเนื้อหาเก่าเล็กน้อยได้ |
|
ไม่มีอัปเดตขณะตรวจสอบใหม่ | การแสดงเนื้อหาที่แคชไว้ในทันทีนั้นทำได้ แต่ระบบควรใช้เนื้อหาที่แคชไว้ในอนาคต |
|
แคชก่อน กลับไปใช้เครือข่าย | เนื้อหาไม่สำคัญและอาจแสดงจากแคชเพื่อเพิ่มประสิทธิภาพได้ แต่ผู้ดูแลบริการควรตรวจสอบการอัปเดตเป็นครั้งคราว |
|
แคชเท่านั้น | เนื้อหาไม่ค่อยเปลี่ยนแปลง |
|
ประโยชน์เพิ่มเติมของการแคชโปรแกรมทำงานของบริการ
นอกจากการควบคุมตรรกะการแคชแบบละเอียดแล้ว การแคชโปรแกรมทำงานของบริการยังมีสิ่งต่อไปนี้ด้วย
- หน่วยความจำและพื้นที่เก็บข้อมูลสำหรับต้นทางมากขึ้น: เบราว์เซอร์จะจัดสรรทรัพยากรแคช HTTP ตามต้นทาง หรือพูดอีกอย่างก็คือ หากคุณมีโดเมนย่อยหลายรายการ ทุกโดเมนย่อยจะใช้แคช HTTP เดียวกัน เราไม่รับประกันว่าเนื้อหาของต้นทาง/โดเมนของคุณจะยังอยู่ในแคช HTTP เป็นเวลานาน ตัวอย่างเช่น ผู้ใช้อาจล้างแคชอย่างถาวรด้วยการล้างข้อมูลด้วยตนเองจาก UI การตั้งค่าของเบราว์เซอร์ หรือทริกเกอร์การโหลดใหม่ด้วยตนเองในหน้าเว็บ เมื่อใช้แคชของโปรแกรมทำงาน คุณมีโอกาสสูงขึ้นมากที่เนื้อหาที่แคชไว้จะยังคงแคชต่อไป ดูข้อมูลเพิ่มเติมได้ที่พื้นที่เก็บข้อมูลถาวร
- ความยืดหยุ่นที่สูงขึ้นด้วยเครือข่ายที่ไม่สม่ำเสมอหรือประสบการณ์การใช้งานออฟไลน์: เมื่อใช้แคช HTTP คุณจะมีตัวเลือกแบบไบนารีเท่านั้น ขึ้นอยู่กับว่าทรัพยากรนั้นมีการแคชหรือไม่ การแคชโปรแกรมทำงานของบริการจะช่วยลด "อาการสะอึก" เล็กๆ น้อยๆ ได้ง่ายขึ้นมาก (ด้วยกลยุทธ์ "ไม่อัปเดตขณะตรวจสอบใหม่") มอบประสบการณ์แบบออฟไลน์ที่สมบูรณ์ (โดยใช้กลยุทธ์ "แคชเท่านั้น") หรือแม้กระทั่งบางอย่าง เช่น UI ที่กำหนดเองที่มีบางส่วนของหน้าเว็บมาจากแคชของโปรแกรมทำงานของบริการ และบางส่วนที่ถูกยกเว้น (โดยใช้กลยุทธ์ "ตั้งค่าเครื่องจัดการแท็ก") ตามความเหมาะสม
การแคช HTTP
ในครั้งแรกที่เบราว์เซอร์โหลดหน้าเว็บและทรัพยากรที่เกี่ยวข้อง เบราว์เซอร์จะจัดเก็บทรัพยากรเหล่านี้ไว้ในแคช HTTP โดยปกติแล้วเบราว์เซอร์จะเปิดใช้แคช HTTP โดยอัตโนมัติ เว้นแต่ผู้ใช้ปลายทางตั้งใจปิดใช้แคชไว้อย่างชัดแจ้ง
การใช้การแคช HTTP ต้องอาศัยเซิร์ฟเวอร์ในการพิจารณาว่าควรแคชแหล่งข้อมูลเมื่อใดและนานเท่าใด
ควบคุมการหมดอายุของแคช HTTP ด้วยส่วนหัวการตอบกลับ HTTP
เมื่อเซิร์ฟเวอร์ตอบกลับคำขอของเบราว์เซอร์สำหรับทรัพยากร เซิร์ฟเวอร์จะใช้ส่วนหัวการตอบกลับ HTTP เพื่อแจ้งเบราว์เซอร์ว่าควรแคชแหล่งข้อมูลไว้นานเท่าใด โปรดดูที่ส่วนหัวการตอบกลับ: กำหนดค่าเว็บเซิร์ฟเวอร์เพื่อเรียนรู้เพิ่มเติม
กลยุทธ์และกรณีการใช้งานสำหรับการแคช HTTP
การแคช HTTP ง่ายกว่าการแคช Service Worker มาก เนื่องจากการแคช HTTP จะดีลที่มีตรรกะการหมดอายุของทรัพยากรตามเวลา (TTL) เท่านั้น โปรดดูข้อมูลเพิ่มเติมเกี่ยวกับกลยุทธ์การแคช HTTP ในคุณควรใช้ค่าส่วนหัวการตอบกลับแบบใด และสรุป
การออกแบบตรรกะการหมดอายุของแคช
ส่วนนี้อธิบายข้อดีและข้อเสียของการใช้ตรรกะการหมดอายุที่สอดคล้องกันในเลเยอร์แคชของ Service Worker และแคช HTTP รวมถึงข้อดีและข้อเสียของตรรกะการหมดอายุที่แยกกันในเลเยอร์เหล่านี้
ข้อบกพร่องด้านล่างแสดงให้เห็นวิธีการทำงานของการแคชโปรแกรมทำงานและการแคช HTTP ในสถานการณ์ต่างๆ
ตรรกะการหมดอายุที่สอดคล้องกันสำหรับเลเยอร์แคชทั้งหมด
เพื่อสาธิตข้อดีและข้อเสีย เราจะดูสถานการณ์ 3 แบบ ได้แก่ ระยะยาว ระยะกลาง และระยะสั้น
สถานการณ์ | การแคชระยะยาว | การแคชระยะกลาง | การแคชระยะสั้น |
---|---|---|---|
กลยุทธ์การแคช Service Worker | แคช ย้อนกลับไปยังเครือข่าย | ไม่มีอัปเดตขณะตรวจสอบใหม่ | เครือข่ายกลับไปใช้แคช |
แคชของ Service Worker สำหรับ TTL | 30 วัน | 1 วัน | 10 นาที |
อายุสูงสุดของแคช HTTP | 30 วัน | 1 วัน | 10 นาที |
สถานการณ์: การแคชระยะยาว (แคช กลับไปใช้เครือข่าย)
- เมื่อทรัพยากรที่แคชไว้ถูกต้อง (<= 30 วัน): โปรแกรมทำงานของบริการจะส่งคืนทรัพยากรที่แคชไว้ทันทีโดยไม่ต้องไปที่เครือข่าย
- เมื่อทรัพยากรที่แคชไว้หมดอายุ (มากกว่า 30 วัน): โปรแกรมทำงานของบริการจะไปที่เครือข่ายเพื่อดึงข้อมูลทรัพยากร เบราว์เซอร์ไม่มีสำเนาของทรัพยากรในแคช HTTP ดังนั้นทรัพยากรจะอยู่ในฝั่งเซิร์ฟเวอร์
ข้อเสีย: ในสถานการณ์นี้ การแคช HTTP จะให้ค่าน้อยกว่า เนื่องจากเบราว์เซอร์จะส่งคำขอไปยังฝั่งเซิร์ฟเวอร์เสมอเมื่อแคชหมดอายุในโปรแกรมทำงานของบริการ
สถานการณ์: การแคชระยะสั้น (ไม่อัปเดตขณะตรวจสอบใหม่)
- เมื่อทรัพยากรที่แคชไว้ถูกต้อง (<= 1 วัน): โปรแกรมทำงานของบริการจะคืนทรัพยากรที่แคชไว้ทันที และไปที่เครือข่ายเพื่อดึงทรัพยากร เบราว์เซอร์มีสำเนาของทรัพยากรอยู่ในแคช HTTP จึงส่งสำเนานั้นกลับไปยังโปรแกรมทำงานของบริการ
- เมื่อทรัพยากรที่แคชไว้หมดอายุ (มากกว่า 1 วัน): โปรแกรมทำงานของบริการจะส่งคืนทรัพยากรที่แคชไว้ทันที และไปที่เครือข่ายเพื่อดึงข้อมูลทรัพยากร เบราว์เซอร์ไม่มีสำเนาของทรัพยากรในแคช HTTP จึงไปที่ฝั่งเซิร์ฟเวอร์เพื่อดึงทรัพยากร
ข้อเสีย: โปรแกรมทำงานของบริการต้องใช้การป้องกันแคชเพิ่มเติมในการลบล้างแคช HTTP เพื่อให้ได้ประโยชน์สูงสุดจากขั้นตอน "ตรวจสอบความถูกต้องอีกครั้ง"
สถานการณ์: การแคชระยะสั้น (เครือข่ายกลับไปใช้แคช)
- เมื่อทรัพยากรที่แคชไว้ถูกต้อง (<= 10 นาที): โปรแกรมทำงานของบริการจะไปยังเครือข่ายเพื่อดึงข้อมูลทรัพยากร เบราว์เซอร์มีสำเนาของทรัพยากรอยู่ในแคช HTTP จึงส่งคืนทรัพยากรนั้นไปยัง Service Worker โดยไม่ต้องไปที่ฝั่งเซิร์ฟเวอร์
- เมื่อทรัพยากรที่แคชไว้หมดอายุ (มากกว่า 10 นาที): โปรแกรมทำงานของบริการจะแสดงทรัพยากรที่แคชไว้ทันที และไปที่เครือข่ายเพื่อดึงข้อมูลทรัพยากร เบราว์เซอร์ไม่มีสำเนาของทรัพยากรในแคช HTTP จึงไปที่ฝั่งเซิร์ฟเวอร์เพื่อดึงทรัพยากร
ข้อเสีย: เช่นเดียวกับสถานการณ์การแคชระยะกลาง โปรแกรมทำงานของบริการต้องใช้ตรรกะในการป้องกันแคชเพิ่มเติมเพื่อลบล้างแคช HTTP เพื่อดึงทรัพยากรล่าสุดจากฝั่งเซิร์ฟเวอร์
Service Worker ในทุกสถานการณ์
ในทุกสถานการณ์ แคชของ Service Worker จะยังคงแสดงผลทรัพยากรที่แคชไว้เมื่อเครือข่ายไม่เสถียร ในทางกลับกัน แคช HTTP จะไม่น่าเชื่อถือเมื่อเครือข่ายไม่เสถียรหรือล่ม
ตรรกะการหมดอายุของแคชแบบต่างๆ ในแคชและเลเยอร์ HTTP ของโปรแกรมทำงานของบริการ
ในการสาธิตข้อดีและข้อเสีย เราจะมาดูสถานการณ์ระยะยาว ระยะกลาง และระยะสั้นกัน
สถานการณ์ | การแคชระยะยาว | การแคชระยะกลาง | การแคชระยะสั้น |
---|---|---|---|
กลยุทธ์การแคช Service Worker | แคช ย้อนกลับไปยังเครือข่าย | ไม่มีอัปเดตขณะตรวจสอบใหม่ | เครือข่ายกลับไปใช้แคช |
แคชของ Service Worker สำหรับ TTL | 90 วัน | 30 วัน | 1 วัน |
อายุสูงสุดของแคช HTTP | 30 วัน | 1 วัน | 10 นาที |
สถานการณ์: การแคชระยะยาว (แคช กลับไปใช้เครือข่าย)
- เมื่อทรัพยากรที่แคชไว้อยู่ในแคชของ Service Worker (<= 90 วัน): โปรแกรมทำงานของบริการจะส่งคืนทรัพยากรที่แคชไว้ทันที
- เมื่อทรัพยากรที่แคชไว้ในแคชของ Service Worker หมดอายุ (มากกว่า 90 วัน): โปรแกรมทำงานของบริการจะไปที่เครือข่ายเพื่อดึงข้อมูลทรัพยากร เบราว์เซอร์ไม่มีสำเนาของทรัพยากร อยู่ในแคช HTTP จึงเปลี่ยนไปเป็นฝั่งเซิร์ฟเวอร์
ข้อดีและข้อเสีย
- ข้อดี: ผู้ใช้จะได้รับการตอบกลับทันทีเมื่อ Service Worker ส่งคืนทรัพยากรที่แคชไว้ทันที
- ข้อดี: โปรแกรมทำงานของบริการมีการควบคุมโดยละเอียดมากกว่าว่าควรใช้แคชเมื่อใดและเมื่อใดที่จะขอทรัพยากรเวอร์ชันใหม่
- ข้อเสีย: ต้องมีกลยุทธ์การแคช Service Worker ที่กำหนดไว้เป็นอย่างดี
สถานการณ์: การแคชในระยะกลาง (ไม่อัปเดตขณะตรวจสอบใหม่)
- เมื่อทรัพยากรที่แคชไว้อยู่ในแคชของ Service Worker (<= 30 วัน): โปรแกรมทำงานของบริการจะส่งคืนทรัพยากรที่แคชไว้ทันที
- เมื่อทรัพยากรที่แคชไว้ในแคชของ Service Worker หมดอายุ (มากกว่า 30 วัน): โปรแกรมทำงานของบริการจะไปยังเครือข่ายสำหรับทรัพยากรนั้น เบราว์เซอร์ไม่มีสำเนาของทรัพยากรในแคช HTTP จึงเปลี่ยนไปใช้ฝั่งเซิร์ฟเวอร์
ข้อดีและข้อเสีย
- ข้อดี: ผู้ใช้จะได้รับการตอบกลับทันทีเมื่อ Service Worker ส่งคืนทรัพยากรที่แคชไว้ทันที
- ข้อดี: โปรแกรมทำงานของบริการจะดูแลให้คำขอถัดไปสำหรับ URL ที่ระบุใช้การตอบสนองใหม่จากเครือข่ายได้ด้วยการตรวจสอบความถูกต้องอีกครั้งที่เกิดขึ้น "ในเบื้องหลัง"
- ข้อเสีย: ต้องมีกลยุทธ์การแคช Service Worker ที่กำหนดไว้เป็นอย่างดี
สถานการณ์: การแคชระยะสั้น (เครือข่ายกลับไปใช้แคช)
- เมื่อทรัพยากรที่แคชไว้อยู่ในแคชของ Service Worker ได้ (<= 1 วัน): โปรแกรมทำงานของบริการจะไปยังเครือข่ายสำหรับทรัพยากรนั้น เบราว์เซอร์จะส่งคืนทรัพยากรจากแคช HTTP หากมีอยู่ หากเครือข่ายหยุดทำงาน โปรแกรมทำงานของบริการจะส่งคืนทรัพยากรจากแคชของโปรแกรมทำงานของบริการ
- เมื่อทรัพยากรที่แคชไว้ในแคชของ Service Worker หมดอายุ (มากกว่า 1 วัน): โปรแกรมทำงานของบริการจะไปที่เครือข่ายเพื่อดึงข้อมูลทรัพยากร เบราว์เซอร์จะดึงทรัพยากรผ่านเครือข่ายเนื่องจากเวอร์ชันในแคชในแคช HTTP หมดอายุแล้ว
ข้อดีและข้อเสีย
- ข้อดี: เมื่อเครือข่ายไม่เสถียรหรือไม่ทำงาน โปรแกรมทำงานของบริการจะส่งคืนทรัพยากรที่แคชไว้ทันที
- ข้อเสีย: โปรแกรมทำงานของบริการต้องใช้การป้องกันแคชเพิ่มเติมเพื่อลบล้างแคช HTTP และส่งคำขอ "เครือข่ายก่อน"
บทสรุป
เนื่องจากความซับซ้อนของสถานการณ์การแคชร่วมกัน เราจึงไม่สามารถออกแบบกฎหนึ่งข้อให้ครอบคลุมทุกกรณีได้ อย่างไรก็ตาม จากข้อมูลที่พบในส่วนก่อนหน้านี้ มีข้อแนะนำ 2-3 ข้อที่ควรพิจารณาเมื่อออกแบบกลยุทธ์การแคช ดังนี้
- ตรรกะการแคชของโปรแกรมทำงานของบริการไม่จำเป็นต้องสอดคล้องกับตรรกะการหมดอายุของการแคช HTTP หากเป็นไปได้ ให้ใช้ตรรกะการหมดอายุที่นานขึ้นในโปรแกรมทำงานของบริการเพื่อให้โปรแกรมทำงานของบริการควบคุมได้มากขึ้น
- การแคช HTTP ยังคงมีบทบาทสำคัญ แต่จะเชื่อถือไม่ได้เมื่อเครือข่ายไม่เสถียรหรือขัดข้อง
- กลับไปดูกลยุทธ์การแคชทรัพยากรแต่ละรายการเพื่อให้แน่ใจว่ากลยุทธ์การแคชโปรแกรมทำงานของบริการนั้นให้คุณค่าโดยไม่ขัดแย้งกับแคช HTTP