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

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

Jonathan Chen
Jonathan Chen
X GitHub

แม้ว่า 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

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

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

Service Worker จะสกัดกั้นคำขอ HTTP ด้วยตัวรับเหตุการณ์ (โดยปกติจะเป็นเหตุการณ์ fetch) ข้อมูลโค้ดนี้แสดงตรรกะของกลยุทธ์การแคชแบบ Cache-First

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

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

import {registerRoute} from 'workbox-routing';

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

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

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

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

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

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

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

การแคช HTTP

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

การใช้การแคช HTTP หมายถึงการพึ่งพาเซิร์ฟเวอร์เพื่อกำหนดว่าจะแคชทรัพยากรเมื่อใดและเป็นระยะเวลานานเท่าใด

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

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

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

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

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

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

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

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

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

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

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

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

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

  • เมื่อทรัพยากรที่แคชไว้ถูกต้อง (<= 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

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

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

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

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

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

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

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

  • เมื่อทรัพยากรที่แคชไว้ถูกต้องในแคชของ 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

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