So speichern Sie OG-Bilder zwischen
Das Zwischenspeichern von OG-Bildern bedeutet, eine zuvor generierte Social-Preview von einem CDN auszuliefern, anstatt sie bei jedem Teilen neu zu rendern. FastOG speichert identische Bilder am Edge für ein Jahr zwischen – dieselbe URL liefert das zwischengespeicherte PNG, ohne gegen Ihr Kontingent zu zählen, und mit nahezu null Latenz, sodass der Großteil des OG-Traffics einer Website den Renderer nie erreicht.
Warum Caching wichtig ist
Ein Social Share löst einen Abruf durch den Crawler der Plattform aus. Wenn jeder Share neu gerendert würde, würden Sie Kontingent und Latenz für identische Inhalte verschwenden. Aggressives Caching – basierend auf dem Inhalt des Bildes – verwandelt „jeder Share zählt als 1 Render" in „der erste Share zählt als 1 Render, jeder weitere Share ist kostenlos."
Das inhaltsbasierte Modell, das dahintersteckt
FastOG verwendet inhalts-signierte URLs: Die URL ist eine reine Funktion der Parameter. Identischer Titel + Vorlage → identische URL. Das bedeutet:
- Der Edge-Server von FastOG speichert das Bild unter der URL.
- Derselbe Inhalt wird 10.000-mal geteilt → ein Rendering, eine Quoten-Zählung, 9.999 Cache-Treffer.
- Inhalt ändern → andere URL → ein neues 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 Caching-Header
FastOG gibt für gerenderte Bilder Cache-Control: public, max-age=31536000, immutable (ein Jahr) zurück. Ein Cover wird von FastOGs Edge in zwei Stufen ausgeliefert: dem Render-Cache vor fastog.com und einem dauerhaften Objektspeicher dahinter. Wiederholte Abrufe werden ohne erneutes Rendern beantwortet, und X-FastOG-Worker-Cache in der Antwort gibt an, welche Stufe geantwortet hat (HIT, R2, MISS).
Da die dauerhafte Kopie nicht vom Renderer abhängt, werden Covers, die mindestens einmal abgerufen wurden, weiterhin ausgeliefert, während FastOGs Render-Dienst kurzzeitig nicht verfügbar ist – ein Ausfall lässt eine bereits erzeugte Vorschau nicht leer erscheinen. Ein Cover, das zuvor noch nie gerendert wurde, ist der einzige Fall, der den Renderer benötigt, und dort antwortet FastOG mit einem Bild statt mit einem Fehler:
| Situation | Was ein Crawler erhält |
|---|---|
| Cover bereits gerendert | das Cover, vom Edge oder aus dem dauerhaften Speicher |
| Nie gerendert, Render-Dienst verfügbar | das Cover, bei Bedarf gerendert |
| Nie gerendert, Render-Dienst kurzzeitig nicht verfügbar | das eigene Bild der Seite aus der URL (Ihr Produktfoto) oder eine neutrale Karte – niemals eine Fehlerseite |
Wenn die Anfrage selbst ungültig ist (eine manipulierte Signatur, ein fehlendes title), erhalten Sie weiterhin den passenden 4xx-Status.
Ändern eines bereits veröffentlichten Bildes
| Sie haben geändert | Was zu tun ist |
|---|---|
| Den Inhalt (Titel, Preis, Foto) | nichts: Der Inhalt ist in der URL enthalten, sodass der neue Inhalt eine neue URL darstellt und frisch gerendert wird |
| Die Vorlage oder einen Render-Standardwert | Erhöhen Sie die Cache-Busting-Version (FASTOG_CACHE_BUST), damit jede URL einen neuen v-Parameter erhält |
| Sie benötigen ein erneutes Rendern derselben URL | Bitten Sie den Support, genau diese eine URL zu leeren – das Leeren einer exakten URL ist nicht als öffentlicher Endpunkt verfügbar |
Bereits geteilte Links funktionieren weiterhin und zeigen weiterhin das Bild, das sie versprochen haben, es sei denn, Sie leeren genau diese URL.
Eigenes og:image-Caching (Self-Hosted)
Wenn Sie Bilder selbst speichern, anstatt den Cache von FastOG zu verwenden, gelten dieselben Regeln:
| Schritt | Detail |
|---|---|
| Cache-Schlüssel = Inhalts-Hash | Speichern Sie anhand eines Hashs der Daten, nicht anhand eines veränderlichen Dateinamens |
| Lange TTL | max-age=31536000, immutable für stabile Inhalte |
| Versionierte URLs | Hängen Sie einen Hash/eine Version an, wenn sich Inhalte ändern |
| CDN davor | Lassen Sie das CDN wiederholte Abrufe abfangen |
FAQ
Kosten wiederholte Shares wirklich 0 Render?
Ja. Identische URLs treffen auf den Edge-Cache und erreichen den Renderer nie – es wird kein Kontingent verbraucht.
Wie lange speichert FastOG ein Bild im Cache?
Ein Jahr (immutable). Lange nach dem ersten Render wird eine geteilte Karte aus dem Cache ausgeliefert.
Was, wenn ich möchte, dass ein Bild aktualisiert wird (z. B. Live-Preis)?
Ändern Sie einen Parameter (den Preis) → neue URL → neuer Render. Stabile Inhalte bleiben gecacht; dynamische Inhalte aktualisieren sich, wann immer Sie es möchten.