Cache-Verwaltung

Cache-Einstellungen

Wie fast.site entscheidet, was gecached wird und wie du es vom Origin aus beeinflussen kannst.

Wie die Defaults gesetzt sind

Beim Hinzufügen einer Domain erkennt fast.site deine Plattform (WordPress, Drupal, Magento usw.) und legt das passende Cache-Template darüber. Das Template deckt die meisten Fälle ab. Die Cache-Control-Header deines Origins haben immer Vorrang, falls du etwas überschreiben willst.

Origin-Cache-Control-Header

Standard: respektiert

Sendet dein Origin Cache-Control-Header, hält sich fast.site daran. Wenn nicht, greifen die Defaults aus dem Plattform-Template.

Browser-Cache

Standard: aktiv

fast.site gibt Cache-Header an Browser weiter, damit wiederkehrende Besucher zusätzlich aus ihrem lokalen Cache profitieren.

Query-String-Caching

Standard: einbezogen

URLs mit unterschiedlichen Query-Strings werden als separate Cache-Einträge geführt (z. B. sind <code class="bg-white/50 px-1 rounded">?v=1</code> und <code class="bg-white/50 px-1 rounded">?v=2</code> verschieden).

Cache-Verhalten vom Origin aus steuern

Du kannst fein justieren, was wie lange gecached wird, indem du Cache-Control-Header an deinem Origin setzt:

# 1 Stunde cachen

Cache-Control: public, max-age=3600

# 1 Jahr cachen (versionierte Assets)

Cache-Control: public, max-age=31536000, immutable

# Nicht cachen (dynamische Seiten)

Cache-Control: private, no-store

Pfade, die das Template standardmäßig ausnimmt

Dein Plattform-Template lässt die Pfade aus, die dynamisch bleiben müssen (Admin, Warenkorb, Kasse, Konto, Login). Beispielhaft für WordPress:

/admin/*
/wp-admin/*
/cart/*
/checkout/*
/my-account/*
/api/*

Brauchst du für dein Setup zusätzliche Pfade ausgenommen? Schreib uns, wir richten das auf unserer Seite ein.

Best Practice

Versionierte Dateinamen für CSS und JS verwenden (z. B. app.v2.js) und lange Cache-Zeiten setzen. So bekommst du maximales Edge-Caching und kannst gleichzeitig Updates ausliefern, ohne manuell zu purgen.

Zurück zum Support