การแคช 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

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

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

import {registerRoute} from 'workbox-routing';

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

กลยุทธ์การแคชและกรณีการใช้งานของโปรแกรมทำงานของบริการ

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

ประโยชน์เพิ่มเติมของการแคช 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 ด้านล่างแสดงให้เห็นการทำงานของการแคชและการแคช HTTP ของโปรแกรมทำงานในสถานการณ์ต่างๆ

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

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

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

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

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

สถานการณ์: การแคชระยะกลาง (ไม่มีอัปเดตขณะตรวจสอบความถูกต้องอีกครั้ง)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• เมื่อทรัพยากรที่แคชไว้ถูกต้องในแคชของ Service Worker (<= 1 วัน): Service Worker จะไปที่เครือข่ายเพื่อขอทรัพยากร เบราว์เซอร์จะแสดงทรัพยากรจากแคช HTTP หากมี หากเครือข่ายไม่ทำงาน โปรแกรมทำงานของบริการจะส่งคืนทรัพยากรจากแคชของ 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

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

• ความน่าเชื่อถือของเครือข่าย
• ป้องกันคำขอเครือข่ายที่ไม่จำเป็นด้วยแคช HTTP
• Codelab แคช HTTP
• การวัดผลลัพธ์จริงของ Service Worker
• Cache-Control กับ Expires
• ไขข้อสงสัยเกี่ยวกับแคช: ตรวจสอบ ล้าง และปิดใช้แคช