การแคช Service Worker และการแคช HTTP

ข้อดีและข้อเสียของการใช้ตรรกะการหมดอายุที่สอดคล้องกันหรือแตกต่างกันในแคช Service Worker และเลเยอร์แคช HTTP

Jonathan Chen

แม้ว่า Service Worker และ PWA กำลังกลายเป็นมาตรฐานของแอปพลิเคชันเว็บสมัยใหม่ แต่การแคชทรัพยากรก็ซับซ้อนขึ้นกว่าที่เคย บทความนี้ครอบคลุมภาพรวมของการแคชของเบราว์เซอร์ ซึ่งรวมถึงข้อมูลต่อไปนี้

  • กรณีการใช้งานและความแตกต่างระหว่างการแคช Service Worker กับการแคช HTTP
  • ข้อดีและข้อเสียของกลยุทธ์การหมดอายุของแคช Service Worker ที่แตกต่างกันเมื่อเทียบกับกลยุทธ์การแคช HTTP ปกติ

ภาพรวมของขั้นตอนการแคช

ในระดับสูง เบราว์เซอร์จะปฏิบัติตามลําดับการแคชด้านล่างเมื่อขอทรัพยากร

  1. แคชของ Service Worker: Service Worker จะตรวจสอบว่าทรัพยากรอยู่ในแคชหรือไม่ และตัดสินใจว่าจะแสดงทรัพยากรนั้นเองหรือไม่ตามกลยุทธ์การแคชที่ตั้งโปรแกรมไว้ โปรดทราบว่าการดำเนินการนี้จะไม่เกิดขึ้นโดยอัตโนมัติ คุณต้องสร้างตัวแฮนเดิลเหตุการณ์การดึงข้อมูลใน Service Worker และขัดขวางคําขอเครือข่ายเพื่อให้ระบบแสดงคําขอจากแคชของ Service Worker แทนเครือข่าย
  2. แคช HTTP (หรือที่เรียกว่าแคชเบราว์เซอร์): หากพบทรัพยากรในแคช HTTP และยังไม่ได้หมดอายุ เบราว์เซอร์จะใช้ทรัพยากรจากแคช HTTP โดยอัตโนมัติ
  3. ฝั่งเซิร์ฟเวอร์: หากไม่พบข้อมูลในแคช Service Worker หรือแคช HTTP เบราว์เซอร์จะไปที่เครือข่ายเพื่อขอทรัพยากร หากทรัพยากรไม่ได้แคชไว้ใน CDN คำขอจะต้องกลับไปที่เซิร์ฟเวอร์ต้นทาง

ขั้นตอนการแคช

การแคชเลเยอร์

การแคช Service Worker

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

การควบคุมแคชของ Service Worker

ผู้ให้บริการจะขัดจังหวะคำขอ HTTP ด้วยตัวรับฟังเหตุการณ์ (โดยปกติคือเหตุการณ์ fetch) ข้อมูลโค้ดนี้แสดงตรรกะของกลยุทธ์การแคชแบบใช้แคชก่อน

แผนภาพที่แสดงวิธีที่ Service Worker ขัดขวางคำขอ HTTP

เราขอแนะนําอย่างยิ่งให้ใช้ Workbox เพื่อหลีกเลี่ยงการคิดค้นสิ่งใหม่ เช่น คุณสามารถลงทะเบียนเส้นทาง URL ของทรัพยากรด้วยโค้ดนิพจน์ทั่วไป 1 บรรทัด

import {registerRoute} from 'workbox-routing';

registerRoute(new RegExp('styles/.*\\.css'), callbackHandler);

กลยุทธ์และกรณีการใช้งานการแคชของ Service Worker

ตารางถัดไปจะแสดงกลยุทธ์การแคช Service Worker ทั่วไปและกรณีที่ควรใช้กลยุทธ์แต่ละรายการ

กลยุทธ์ เหตุผลของความใหม่ กรณีการใช้งาน
Network only เนื้อหาต้องเป็นข้อมูลล่าสุดอยู่เสมอ
  • การชำระเงินและการชำระเงิน
  • ยอดคงเหลือ
เครือข่ายใช้แคชสำรอง เราขอแนะนำให้แสดงเนื้อหาใหม่ อย่างไรก็ตาม หากเครือข่ายไม่เสถียรหรือใช้งานไม่ได้ ก็ถือว่ายอมรับได้หากแสดงเนื้อหาที่เก่าไปเล็กน้อย
  • ข้อมูลที่เป็นปัจจุบัน
  • ราคาและอัตรา (ต้องมีข้อจำกัดความรับผิด)
  • สถานะการสั่งซื้อ
Stale-while-revalidate คุณแสดงเนื้อหาที่แคชไว้ได้ทันที แต่ควรใช้เนื้อหาที่แคชไว้ซึ่งอัปเดตแล้วในอนาคต
  • ฟีดข่าว
  • หน้าข้อมูลผลิตภัณฑ์ที่แสดง
  • ข้อความ
ใช้แคชก่อน แล้วเปลี่ยนไปใช้เครือข่ายหากไม่สำเร็จ เนื้อหาไม่สำคัญและสามารถแสดงจากแคชเพื่อเพิ่มประสิทธิภาพได้ แต่ Service Worker ควรตรวจสอบการอัปเดตเป็นครั้งคราว
  • App Shell
  • ทรัพยากรส่วนกลาง
แคชเท่านั้น เนื้อหามีการเปลี่ยนแปลงน้อยมาก
  • เนื้อหาคงที่

ประโยชน์เพิ่มเติมของการแคช Service Worker

นอกจากการควบคุมตรรกะการแคชอย่างละเอียดแล้ว การแคช Service Worker ยังให้ประโยชน์ต่อไปนี้ด้วย

  • หน่วยความจําและพื้นที่เก็บข้อมูลมากขึ้นสําหรับต้นทาง: เบราว์เซอร์จะจัดสรรทรัพยากรแคช HTTP ตามต้นทาง กล่าวคือ หากคุณมีโดเมนย่อยหลายรายการ โดเมนย่อยทั้งหมดจะใช้แคช HTTP เดียวกัน เราไม่รับประกันว่าเนื้อหาของต้นทาง/โดเมนจะอยู่ในแคช HTTP เป็นเวลานาน เช่น ผู้ใช้อาจล้างแคชด้วยตนเองโดยการล้างข้อมูลใน UI การตั้งค่าของเบราว์เซอร์ หรือเรียกให้โหลดหน้าเว็บซ้ำ เมื่อใช้แคช Service Worker คุณมีแนวโน้มที่เนื้อหาที่แคชไว้จะยังคงอยู่ในแคชได้นานขึ้น ดูข้อมูลเพิ่มเติมได้ที่พื้นที่เก็บข้อมูลถาวร
  • มีความยืดหยุ่นมากขึ้นเมื่อใช้เครือข่ายที่ไม่เสถียรหรือเมื่อใช้แบบออฟไลน์: เมื่อใช้แคช HTTP คุณจะมีตัวเลือกเพียง 2 ตัวเลือกเท่านั้น คือแคชทรัพยากรหรือไม่แคชทรัพยากร เมื่อใช้การแคช Service Worker คุณจะสามารถลด "ปัญหาเล็กๆ น้อยๆ" ได้ง่ายขึ้น (โดยใช้กลยุทธ์ "stale-while-revalidate") มอบประสบการณ์การใช้งานแบบออฟไลน์ที่สมบูรณ์ (โดยใช้กลยุทธ์ "Cache only") หรือแม้แต่ใช้กลยุทธ์แบบกลางๆ เช่น UI ที่กําหนดเองซึ่งมีบางส่วนของหน้ามาจากแคช Service Worker และยกเว้นบางส่วน (โดยใช้กลยุทธ์ "Set catch handler") ตามความเหมาะสม

การแคช HTTP

เมื่อเบราว์เซอร์โหลดหน้าเว็บและทรัพยากรที่เกี่ยวข้องเป็นครั้งแรก ระบบจะจัดเก็บทรัพยากรเหล่านี้ไว้ในแคช HTTP โดยปกติแล้วเบราว์เซอร์จะเปิดใช้แคช HTTP โดยอัตโนมัติ เว้นแต่ผู้ใช้ปลายทางจะปิดใช้อย่างชัดเจน

การใช้การแคช HTTP หมายความว่าคุณจะต้องอาศัยเซิร์ฟเวอร์ในการกำหนดเวลาแคชทรัพยากรและระยะเวลาในการแคช

ควบคุมวันหมดอายุของแคช HTTP ด้วยส่วนหัวการตอบกลับ HTTP

เมื่อเซิร์ฟเวอร์ตอบสนองต่อคำขอทรัพยากรจากเบราว์เซอร์ เซิร์ฟเวอร์จะใช้ส่วนหัวการตอบกลับ HTTP เพื่อบอกเบราว์เซอร์ว่าควรแคชทรัพยากรไว้นานเท่าใด ดูข้อมูลเพิ่มเติมที่ส่วนหัวการตอบกลับ: กำหนดค่าเว็บเซิร์ฟเวอร์

กลยุทธ์และกรณีการใช้งานการแคช HTTP

การแคช HTTP นั้นง่ายกว่าการแคช Service Worker มาก เนื่องจากแคช HTTP จะจัดการเฉพาะตรรกะการหมดอายุของทรัพยากรตามเวลา (TTL) ดูข้อมูลเพิ่มเติมเกี่ยวกับกลยุทธ์การแคช HTTP ได้ที่หัวข้อคุณควรใช้ค่าส่วนหัวการตอบกลับใดและสรุป

การออกแบบตรรกะวันหมดอายุของแคช

ส่วนนี้จะอธิบายข้อดีและข้อเสียของการใช้ตรรกะการหมดอายุที่สอดคล้องกันในแคชของ Service Worker และเลเยอร์แคช HTTP รวมถึงข้อดีและข้อเสียของการใช้ตรรกะการหมดอายุแยกกันในเลเยอร์เหล่านี้

Glitch ด้านล่างแสดงวิธีการทำงานของการแคช Service Worker และการแคช HTTP ในสถานการณ์ต่างๆ

ตรรกะวันหมดอายุที่สอดคล้องกันสำหรับเลเยอร์แคชทั้งหมด

เราจะดูข้อดีและข้อเสียจาก 3 สถานการณ์ ได้แก่ ระยะยาว ระยะกลาง และระยะสั้น

สถานการณ์ การแคชระยะยาว การแคชระยะกลาง การแคชระยะสั้น
กลยุทธ์การแคช Service Worker แคช กลับไปใช้เครือข่าย Stale-while-revalidate เครือข่ายใช้แคชสำรอง
TTL ของแคช Service Worker 30 วัน 1 วัน 10 นาที
max-age ของแคช HTTP 30 วัน 1 วัน 10 นาที

สถานการณ์: การแคชระยะยาว (แคช กลับไปใช้เครือข่าย)

  • เมื่อทรัพยากรที่แคชไว้ใช้งานได้ (<= 30 วัน): Service Worker จะแสดงทรัพยากรที่แคชไว้ทันทีโดยไม่ต้องไปที่เครือข่าย
  • เมื่อทรัพยากรที่แคชไว้หมดอายุ (> 30 วัน): เวิร์กเกอร์บริการจะไปที่เครือข่ายเพื่อดึงข้อมูลทรัพยากร เบราว์เซอร์ไม่มีสำเนาของทรัพยากรในแคช HTTP จึงต้องขอทรัพยากรจากฝั่งเซิร์ฟเวอร์

ข้อเสีย: ในสถานการณ์นี้ การแคช HTTP จะมีคุณค่าน้อยลงเนื่องจากเบราว์เซอร์จะส่งต่อคำขอไปยังฝั่งเซิร์ฟเวอร์เสมอเมื่อแคชหมดอายุใน Service Worker

สถานการณ์: การแคชระยะกลาง (Stale-while-revalidate)

  • เมื่อทรัพยากรที่แคชไว้ใช้งานได้ (<= 1 วัน): Service Worker จะแสดงทรัพยากรที่แคชไว้ทันที และไปที่เครือข่ายเพื่อดึงข้อมูลทรัพยากร เนื่องจากเบราว์เซอร์มีสำเนาของทรัพยากรดังกล่าวในแคช HTTP จึงส่งสำเนานั้นกลับไปยัง Service Worker
  • เมื่อทรัพยากรที่แคชไว้หมดอายุ (> 1 วัน): Service Worker จะแสดงทรัพยากรที่แคชไว้ทันที และไปที่เครือข่ายเพื่อดึงข้อมูลทรัพยากร เบราว์เซอร์ไม่มีสำเนาของทรัพยากรในแคช HTTP ดังนั้นจึงไปที่ฝั่งเซิร์ฟเวอร์เพื่อดึงข้อมูลทรัพยากร

ข้อเสีย: Service Worker ต้องใช้การลบแคชเพิ่มเติมเพื่อลบล้างแคช HTTP เพื่อให้ใช้ขั้นตอน "ตรวจสอบอีกครั้ง" ให้ได้ประโยชน์สูงสุด

สถานการณ์: การแคชระยะสั้น (เครือข่ายใช้แคชสำรอง)

  • เมื่อทรัพยากรที่แคชไว้ใช้งานได้ (<= 10 นาที): บริการเวิร์กเกอร์จะไปยังเครือข่ายเพื่อดึงข้อมูลทรัพยากร เนื่องจากเบราว์เซอร์มีสำเนาของทรัพยากรในแคช HTTP จึงส่งคืนทรัพยากรนั้นไปยัง Service Worker โดยไม่ต้องไปที่ฝั่งเซิร์ฟเวอร์
  • เมื่อทรัพยากรที่แคชไว้หมดอายุ (> 10 นาที): Service Worker จะแสดงทรัพยากรที่แคชไว้ทันที และไปที่เครือข่ายเพื่อดึงข้อมูลทรัพยากร เบราว์เซอร์ไม่มีสำเนาของทรัพยากรในแคช HTTP ดังนั้นจึงไปที่ฝั่งเซิร์ฟเวอร์เพื่อดึงข้อมูลทรัพยากร

ข้อเสีย: เช่นเดียวกับสถานการณ์การแคชระยะกลาง เวิร์กเกอร์บริการต้องใช้ตรรกะการทำลายแคชเพิ่มเติมเพื่อลบล้างแคช HTTP เพื่อดึงข้อมูลทรัพยากรล่าสุดจากฝั่งเซิร์ฟเวอร์

Service Worker ในทุกสถานการณ์

ในทุกสถานการณ์ แคช Service Worker จะยังคงแสดงทรัพยากรที่แคชไว้ได้เมื่อเครือข่ายไม่เสถียร ในทางกลับกัน แคช HTTP ไม่น่าเชื่อถือเมื่อเครือข่ายไม่เสถียรหรือหยุดทำงาน

ตรรกะวันหมดอายุของแคชที่แตกต่างกันที่แคช Service Worker และเลเยอร์ HTTP

เราจะดูสถานการณ์ระยะยาว ระยะกลาง และระยะสั้นอีกครั้งเพื่อแสดงให้เห็นข้อดีและข้อเสีย

สถานการณ์ การแคชระยะยาว การแคชระยะกลาง การแคชระยะสั้น
กลยุทธ์การแคช Service Worker แคช กลับไปใช้เครือข่าย Stale-while-revalidate เครือข่ายใช้แคชสำรอง
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 (<= 30 วัน): Service Worker จะแสดงทรัพยากรที่แคชไว้ทันที
  • เมื่อทรัพยากรที่แคชไว้หมดอายุในแคชของ Service Worker (> 30 วัน) Service Worker จะไปที่เครือข่ายเพื่อขอทรัพยากร เนื่องจากเบราว์เซอร์ไม่มีสำเนาของทรัพยากรในแคช HTTP จึงต้องส่งคำขอไปยังฝั่งเซิร์ฟเวอร์

ข้อดีและข้อเสีย

  • ข้อดี: ผู้ใช้จะได้รับประสบการณ์การตอบสนองทันทีเนื่องจาก 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 และส่งคําขอ "เครือข่ายก่อน"

บทสรุป

ด้วยความซับซ้อนของชุดค่าผสมของสถานการณ์การแคช จึงไม่สามารถออกแบบกฎเดียวที่ครอบคลุมทุกกรณีได้ อย่างไรก็ตาม จากข้อมูลที่ได้รับในส่วนก่อนหน้านี้ เราขอแนะนํา 2-3 ข้อเมื่อออกแบบกลยุทธ์แคช ดังนี้

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

ดูข้อมูลเพิ่มเติม