Sådan cacher du OG-billeder
Caching af OG-billeder betyder, at en tidligere genereret social preview (social preview) serveres fra en CDN i stedet for at blive gengivet igen ved hver deling. FastOG cacher identiske billeder på kanten (edge) i et år — den samme URL returnerer det cachelagrede PNG uden at tælle mod dit kvota og med næsten nul latenstid, så størstedelen af en sides OG-trafik aldrig rammer rendereren.
Hvorfor caching er vigtigt
En social deling udløser et kald fra platformens crawler. Hvis hver deling blev gengivet på ny, ville du bruge kvote og latens på identisk indhold. Aggressiv caching — nøglet på billedets indhold — ændrer "hver deling tæller som 1 gengivelse" til "den første deling tæller som 1 gengivelse, alle andre delinger er gratis."
Indholdsbaseret model, der får det til at fungere
FastOG bruger indholdssignerede URL'er: URL'en er en ren funktion af parametrene. Identisk titel + skabelon → identisk URL. Det betyder:
- FastOG's edge holder billedet under URL'en.
- Samme indhold delt 10.000 gange → én gengivelse, én kvotatælling, 9.999 cache-hits.
- Ændr indholdet → anden URL → én ny gengivelse.
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's caching-headere
FastOG returnerer Cache-Control: public, max-age=31536000, immutable (ét år) for genererede billeder. Et cover
serveres fra FastOG's edge i to lag: render-cachen foran fastog.com og et varigt objektlager
bagved. Gentagne hentninger besvares uden at gengive igen, og X-FastOG-Worker-Cache i
svaret angiver, hvilket lag der svarede (HIT, R2, MISS).
Da den varige kopi ikke afhænger af rendereren, bliver covers, der er hentet mindst én gang, ved med at blive serveret, mens FastOG's render-tjeneste kortvarigt er utilgængelig — en udfaldstid sletter ikke en forhåndsvisning, der allerede er genereret. Et cover, der aldrig er blevet renderet før, er det eneste tilfælde, der kræver rendereren, og der svarer FastOG med et billede frem for en fejl:
| Situation | Hvad en crawler får |
|---|---|
| Cover allerede renderet | coveret, fra edge eller det varige lager |
| Aldrig renderet, render-tjenesten oppe | coveret, renderet on demand |
| Aldrig renderet, render-tjenesten kortvarigt nede | sidens eget billede medbragt i URL'en (dit produktfoto), eller et neutralt kort — aldrig en fejlside |
Hvis selve anmodningen er ugyldig (en manipuleret signatur, en manglende title), får du stadig den tilsvarende 4xx.
Ændring af et billede, du allerede har offentliggjort
| Du ændrede | Hvad du skal gøre |
|---|---|
| Indholdet (titel, pris, foto) | intet: indholdet ligger i URL'en, så det nye indhold er en ny URL og gengives frisk |
| Skabelonen eller en gengivelsesstandard | hæv cache-bust-versionen (FASTOG_CACHE_BUST), så hver URL får en ny v-parameter |
| Du har brug for, at den samme URL gengives igen | bed support om at rense den ene URL — præcis-URL-rensningen er ikke eksponeret som et offentligt endpoint |
Links, der allerede er delt, fortsætter med at virke og bliver ved med at vise det billede, de lovede, medmindre du renser den præcise URL.
Cache din egen og:image (selv-hostet)
Hvis du selv gemmer billeder i stedet for at bruge FastOG's cache, så anvend de samme regler:
| Trin | Detalje |
|---|---|
| Cache-nøgle = indholdshash | Gem efter en hash af dataene, ikke et foranderligt filnavn |
| Lang TTL | max-age=31536000, immutable for stabilt indhold |
| Versionerede URL'er | Tilføj en hash/version, når indholdet ændres |
| CDN foran | Lad CDN'et absorbere gentagne hentninger |
FAQ
Koster gentagne delinger virkelig 0 renders?
Ja. Identiske URL'er rammer edge-cachen og når aldrig frem til rendereren — der forbruges ingen kvote.
Hvor længe cacher FastOG et billede?
Et år (immutable). Længe efter første render bliver et delt kort serveret fra cachen.
Hvad hvis jeg vil have et billede til at opdatere (fx live pris)?
Ændr en parameter (prisen) → ny URL → nyt render. Stabil indhold forbliver cachet; dynamisk indhold opdateres, når du ønsker det.