Slik bufrer du OG-bilder
Bufring av OG-bilder betyr å levere en tidligere generert sosial forhåndsvisning fra en CDN i stedet for å gjengi den på nytt ved hver deling. FastOG bufrer identiske bilder i kanten i ett år — den samme URL-en returnerer det bufrede PNG-bildet uten å telle mot kvoten din og med omtrent null ventetid, så mesteparten av et nettsteds OG-trafikk når aldri gjengiveren.
Hvorfor caching er viktig
En sosial deling utløser en henting fra plattformens crawler. Hvis hver deling gjenga innholdet på nytt, ville du brukt kvote og latens på identisk innhold. Aggressiv caching — nøklet på bildets innhold — gjør at «hver deling teller som 1 gjengivelse» blir til «den første delingen teller som 1 gjengivelse, alle andre delinger er gratis.»
Innholdsbasert modell som gjør at det fungerer
FastOG bruker innholdssignerte URL-er: URL-en er en ren funksjon av parameterne. Identisk tittel + mal → identisk URL. Det betyr:
- FastOGs edge-kant beholder bildet under URL-en.
- Samme innhold delt 10 000 ganger → én rendering, én kvotetelling, 9 999 cache-treff.
- Endre innholdet → annen URL → én ny rendering.
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)
FastOGs cache-hoder
FastOG returnerer Cache-Control: public, max-age=31536000, immutable (ett år) for genererte bilder. Et forsidebilde
serveres fra FastOGs edge i to nivåer: render-cachen foran fastog.com, og et varig objektlager
bak den. Gjentatte hentinger besvares uten å rendere på nytt, og X-FastOG-Worker-Cache i
svaret forteller hvilket nivå som svarte (HIT, R2, MISS).
Siden den varige kopien ikke avhenger av rendereren, fortsetter forsidebilder som er hentet minst én gang å bli servert mens FastOGs render-tjeneste er kortvarig utilgjengelig — et avbrudd gjør ikke at en forhåndsvisning som allerede er generert blir blank. Et forsidebilde som aldri har blitt rendret før, er det eneste tilfellet som trenger rendereren, og der svarer FastOG med et bilde i stedet for en feil:
| Situasjon | Hva en crawler får |
|---|---|
| Forsidebilde allerede rendret | forsidebildet, fra edge eller det varige lageret |
| Aldri rendret, render-tjenesten oppe | forsidebildet, rendret på forespørsel |
| Aldri rendret, render-tjenesten kortvarig nede | sidens eget bilde som følger med i URL-en (produktbildet ditt), eller et nøytralt kort — aldri en feilside |
Hvis selve forespørselen er ugyldig (en manipulert signatur, en manglende title), får du fortsatt den tilsvarende 4xx-feilen.
Endre et bilde du allerede har publisert
| Du endret | Hva du gjør |
|---|---|
| Innholdet (tittel, pris, bilde) | ingenting: innholdet ligger i URL-en, så det nye innholdet er en ny URL og rendres ferskt |
| Malen eller en standardverdi for rendering | øk cache-bust-versjonen (FASTOG_CACHE_BUST) slik at hver URL får en ny v-parameter |
| Du trenger samme URL rendret på nytt | be support om å tømme akkurat den URL-en — tømming av eksakt URL er ikke eksponert som et offentlig endepunkt |
Lenker som allerede er delt fortsetter å fungere, og fortsetter å vise bildet de lovet, med mindre du tømmer akkurat den URL-en.
Caching av din egen og:image (selvhostet)
Hvis du lagrer bilder selv i stedet for å bruke FastOGs cache, gjelder de samme reglene:
| Steg | Detalj |
|---|---|
| Cache-nøkkel = innholdshash | Lagre basert på en hash av dataene, ikke et foranderlig filnavn |
| Lang TTL | max-age=31536000, immutable for stabilt innhold |
| Versjonerte URL-er | Legg til en hash/versjon når innholdet endres |
| CDN foran | La CDN-en absorbere gjentatte hentinger |
FAQ
Koster gjentatte delinger virkelig 0 renders?
Ja. Identiske URL-er treffer edge-cachen og når aldri rendereren — ingen kvote telles opp.
Hvor lenge cacher FastOG et bilde?
Ett år (immutable). Lenge etter første render blir et delt kort servert fra cachen.
Hva hvis jeg vil at et bilde skal oppdateres (f.eks. live pris)?
Endre en parameter (prisen) → ny URL → ny render. Stabil innhold forblir cachet; dynamisk innhold oppdateres når du vil.