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