วิธีแคช OG Images
การแคช OG images หมายถึงการส่ง social preview ที่สร้างไว้ก่อนแล้วจาก CDN แทนที่จะเรนเดอร์ใหม่ทุกครั้งที่มีการแชร์ FastOG แคชรูปภาพที่เหมือนกันที่ edge เป็นเวลาหนึ่งปี — URL เดียวกันจะส่งคืน PNG ที่ถูกแคชไว้โดยไม่นับรวมกับโควตาของคุณ และใช้เวลาแฝงเกือบเป็นศูนย์ ดังนั้นปริมาณการเข้าชม OG ส่วนใหญ่ของเว็บไซต์จะไม่แตะต้องตัวเรนเดอร์เลย
เหตุใดการแคชจึงสำคัญ
การแชร์บนโซเชียลทำให้ครอว์เลอร์ของแพลตฟอร์มทำการดึงข้อมูล หากทุกการแชร์ต้องเรนเดอร์ใหม่ คุณจะสิ้นเปลืองโควตาและความหน่วงกับเนื้อหาที่เหมือนกัน การแคชแบบเชิงรุก — ซึ่งใช้คีย์จากเนื้อหาของภาพ — จะเปลี่ยนจาก "ทุกการแชร์นับเป็น 1 การเรนเดอร์" เป็น "การแชร์ครั้งแรกนับเป็น 1 การเรนเดอร์ ส่วนการแชร์ครั้งอื่นๆ ไม่เสียค่าใช้จ่าย"
โมเดลที่อิงคีย์จากเนื้อหา (content-keyed model) ที่ทำให้มันทำงานได้
FastOG ใช้ URL ที่ลงนามด้วยเนื้อหา (content-signed URLs): URL เป็นฟังก์ชันล้วนๆ ของพารามิเตอร์ ชื่อเรื่องเดียวกัน + เทมเพลตเดียวกัน → URL เดียวกัน นั่นหมายความว่า:
- ขอบของ FastOG เก็บรูปภาพไว้ภายใต้ URL นั้น
- เนื้อหาเดียวกันถูกแชร์ 10,000 ครั้ง → เรนเดอร์ครั้งเดียว คิดโควตาครั้งเดียว และแคชฮิต 9,999 ครั้ง
- เปลี่ยนเนื้อหา → URL ต่างกัน → เรนเดอร์ใหม่หนึ่งครั้ง
GET /api/v1/og?title=Hello&template=default&key=...&s=... → render (1 quota count), then
GET /api/v1/og?title=Hello&template=default&key=...&s=... → cached (0 counts, instant)
GET /api/v1/og?title=Changed&template=default&key=...&s=... → render (1 quota count)
ส่วนหัวแคชของ FastOG
FastOG ส่งคืน Cache-Control: public, max-age=31536000, immutable (หนึ่งปี) สำหรับรูปภาพที่เรนเดอร์แล้ว ภาพปกจะถูกให้บริการจากเอจของ FastOG ในสองชั้น: แคชการเรนเดอร์ที่อยู่ด้านหน้า fastog.com และที่เก็บอ็อบเจกต์แบบถาวรที่อยู่ด้านหลัง การเรียกซ้ำจะได้รับการตอบสนองโดยไม่ต้องเรนเดอร์ใหม่ และ X-FastOG-Worker-Cache ในส่วนหัวการตอบสนองจะระบุว่าชั้นใดเป็นผู้ตอบ (HIT, R2, MISS)
เนื่องจากสำเนาแบบถาวรไม่ได้ขึ้นอยู่กับตัวเรนเดอร์ ภาพปกที่ถูกเรียกอย่างน้อยหนึ่งครั้งจะยังคงถูกให้บริการต่อไปในขณะที่บริการเรนเดอร์ของ FastOG ไม่พร้อมใช้งานชั่วคราว — การหยุดทำงานจะไม่ทำให้ตัวอย่างที่สร้างไว้แล้วว่างเปล่า ภาพปกที่ไม่เคยถูกเรนเดอร์มาก่อนเป็นกรณีเดียวที่ต้องใช้ตัวเรนเดอร์ และในกรณีนั้น FastOG จะตอบกลับด้วยรูปภาพแทนที่จะเป็นข้อผิดพลาด:
| สถานการณ์ | สิ่งที่ครอว์เลอร์ได้รับ |
|---|---|
| ภาพปกเรนเดอร์แล้ว | ภาพปก จากเอจหรือที่เก็บแบบถาวร |
| ไม่เคยเรนเดอร์ บริการเรนเดอร์ทำงาน | ภาพปก เรนเดอร์ตามคำขอ |
| ไม่เคยเรนเดอร์ บริการเรนเดอร์หยุดชั่วคราว | รูปภาพของหน้าเว็บที่ฝังอยู่ใน URL (รูปสินค้าของคุณ) หรือการ์ดที่เป็นกลาง — ไม่ใช่หน้าแสดงข้อผิดพลาด |
หากคำขอไม่ถูกต้อง (ลายเซ็นที่ถูกแก้ไข, title ที่หายไป) คุณจะยังคงได้รับรหัส 4xx ที่สอดคล้องกัน
การเปลี่ยนรูปภาพที่คุณเผยแพร่ไปแล้ว
| สิ่งที่คุณเปลี่ยน | สิ่งที่ต้องทำ |
|---|---|
| เนื้อหา (ชื่อเรื่อง ราคา รูปภาพ) | ไม่ต้องทำอะไร: เนื้อหาอยู่ใน URL ดังนั้นเนื้อหาใหม่ก็คือ URL ใหม่ และจะแสดงผลใหม่ทั้งหมด |
| เทมเพลตหรือค่าเริ่มต้นของการเรนเดอร์ | เพิ่มเวอร์ชันสำหรับการล้างแคช (FASTOG_CACHE_BUST) เพื่อให้ทุก URL ได้รับพารามิเตอร์ v ใหม่ |
| คุณต้องการให้ URL เดิมถูกเรนเดอร์ใหม่ | ขอให้ฝ่ายสนับสนุนล้างแคชเฉพาะ URL นั้น — การล้างแคชแบบระบุ URL ที่แน่นอนไม่ได้เปิดเป็น endpoint สาธารณะ |
ลิงก์ที่แชร์ไปแล้วยังคงทำงานได้ และยังคงแสดงรูปภาพตามที่สัญญาไว้ เว้นแต่คุณจะล้างแคชของ URL นั้นโดยเฉพาะ
แคช og:image ของคุณเอง (self-hosted)
หากคุณจัดเก็บรูปภาพด้วยตัวเองแทนการใช้แคชของ FastOG ให้ใช้กฎเดียวกันนี้:
| ขั้นตอน | รายละเอียด |
|---|---|
| คีย์แคช = แฮชของเนื้อหา | จัดเก็บโดยใช้แฮชของข้อมูล ไม่ใช่ชื่อไฟล์ที่เปลี่ยนแปลงได้ |
| TTL ยาว | max-age=31536000, immutable สำหรับเนื้อหาที่เสถียร |
| URL แบบมีเวอร์ชัน | เพิ่มแฮช/เวอร์ชันเมื่อเนื้อหาเปลี่ยนแปลง |
| วาง CDN ไว้ด้านหน้า | ให้ CDN รับภาระการดึงข้อมูลซ้ำ ๆ |
คำถามที่พบบ่อย
การแชร์ซ้ำ ๆ ใช้เรนเดอร์ 0 ครั้งจริงหรือ?
ใช่ URL ที่เหมือนกันจะถูกแคชที่ขอบเครือข่าย (edge cache) และไม่ไปถึงตัวเรนเดอร์ — ไม่มีการใช้โควต้าเพิ่ม
FastOG แคชรูปภาพไว้นานเท่าใด?
หนึ่งปี (immutable) หลังจากเรนเดอร์ครั้งแรก การ์ดที่แชร์จะถูกเสิร์ฟจากแคชเป็นเวลานาน
หากต้องการให้รูปภาพอัปเดต (เช่น ราคาสด) ต้องทำอย่างไร?
เปลี่ยนพารามิเตอร์ (ราคา) → URL ใหม่ → เรนเดอร์ใหม่ เนื้อหาที่คงที่ยังคงถูกแคชไว้ ส่วนเนื้อหาที่เปลี่ยนแปลงจะอัปเดตเมื่อคุณต้องการ