Was sind statische Inhalte?

Statische Inhalte werden aus einer gespeicherten Repräsentation ausgeliefert, die bei verschiedenen Anfragen gewöhnlich identisch bleibt. Änderungen entstehen nur durch Aktualisierungen der zugrunde liegenden Ressource, nicht durch eine Generierung pro Anfrage.

„Statisch“ ist eine Eigenschaft der Auslieferung: Der Server kann bereits vorhandene Bytes zurückgeben, etwa eine Datei auf einem Datenträger oder ein Objekt in einem Bucket, ohne Anwendungslogik für die Anfrage auszuführen. Die Datei kann von Hand geschrieben, bei einem Build erzeugt oder aus einer Medienpipeline exportiert worden sein. „Statisch“ bedeutet also nicht, dass sie sich nie ändert. Es bedeutet, dass sich der Inhalt ändert, wenn die gespeicherte Datei ersetzt wird, nicht beim Eingang einer Anfrage. Zwei HTTP-Mechanismen übernehmen daher den Großteil der Arbeit. Die mit Cache-Control festgelegte Frische sagt Browsern und CDNs, wie lange sie eine Kopie ohne Rückfrage wiederverwenden dürfen. Validatoren in Form von ETag oder einem Datum in Last-Modified ermöglichen es einem Cache, nachzufragen, ob seine Kopie noch aktuell ist, und in diesem Fall eine Antwort mit 304 ohne Antwortkörper zu erhalten. Bilder, Videosegmente, Schriftarten, Stylesheets, Skripte und vorab erzeugte HTML-Seiten sind typische statische Inhalte; eine Antwort, die pro Anfrage aus dem Anwendungszustand zusammengesetzt wird, ist dynamischer Inhalt.

Wird eine statische Datei automatisch im Cache gespeichert? Nicht zuverlässig und nicht für eine vorhersehbare Dauer. Ohne explizite Frischeangaben aus Cache-Control oder Expires erlaubt HTTP einem Cache, die Frische heuristisch zu bestimmen: RFC 9111 gestattet es, anhand von Last-Modified eine Gültigkeitsdauer abzuschätzen, und nennt 10 % der seit der letzten Änderung verstrichenen Zeit als typische Einstellung. MDN empfiehlt deshalb, jede Antwort mit einem expliziten Header Cache-Control zu versehen. CDNs haben zusätzlich eigene Standardeinstellungen. Cloudflare verwendet für das Caching beispielsweise die Dateiendung statt des MIME-Typs, speichert HTML oder JSON standardmäßig nicht im Cache und nimmt keine Antwort mit Set-Cookie in den Cache auf.
Sollte eine statische Datei ihre URL behalten, wenn sich ihr Inhalt ändert? Entscheiden Sie das für jede Datei einzeln. Eine Datei, deren URL sich mit ihrem Inhalt ändert, etwa ein Bundle mit einem Hash im Namen, kann mit einem hohen Wert für max-age (im Beispiel von MDN ein Jahr) sowie mit immutable ausgeliefert werden, da eine neue Version unter einer neuen URL erscheint. Eine Datei, die ihre URL behalten muss, etwa eine HTML-Seite, sollte keine lange Gültigkeitsdauer erhalten: Eine Aktualisierung der Datei auf dem Server ersetzt keine noch frische Kopie, die ein Browser bereits gespeichert hat. Wie MDN anmerkt, erreichen Anfragen dafür den Server nämlich nicht mehr, sodass der Browser diese Kopie bis zum Ablauf ihrer Gültigkeitsdauer weiterverwenden kann. Ein CDN, das eine Cache-Bereinigung anbietet, kann seine eigene Kopie entfernen, doch diese Bereinigung erreicht keine bereits in Browsern gespeicherten Kopien. Liefern Sie diese Dateien mit no-cache und Validatoren aus, damit jede Wiederverwendung geprüft wird und bei einer unveränderten Datei nur eine Antwort mit 304 anfällt.
Kann eine Antwort allein deshalb sicher in einem gemeinsam genutzten Cache gespeichert werden, weil sie aus einer Datei ausgeliefert wird? Nein. Ob sie zwischengespeichert werden darf, hängt von der Anfrage und den Antwort-Headern ab, nicht davon, wie der Antwortkörper erzeugt wurde. RFC 9111 verbietet einem gemeinsam genutzten Cache, die Antwort auf eine Anfrage mit Authorization wiederzuverwenden, sofern die Antwort dies nicht mit public, s-maxage oder must-revalidate erlaubt. Für eine Anfrage mit einem Header Cookie enthält der Standard keine solche Regel. MDN weist darauf hin, dass ein Cookie allein eine Antwort nicht privat macht. Der Standard weist außerdem darauf hin, dass Set-Cookie das Caching nicht verhindert. Eine mit einem Cookie gesendete statische Datei kann daher von einem standardkonformen Cache gespeichert und für spätere Anfragen wiederverwendet werden. Ein CDN kann stattdessen eigene Regeln anwenden: Cloudflare speichert eine solche Antwort, wie oben erwähnt, standardmäßig nicht im Cache. Setzen Sie auf statischen Pfaden möglichst keine Cookies. Wenn eine Antwort ein Cookie enthalten muss oder durch ein Cookie personalisiert wird, kennzeichnen Sie sie mit private: Ein gemeinsam genutzter Cache wie ein CDN darf sie dann nicht speichern, sodass diese Datei nur in Browsern zwischengespeichert wird.
Was ändert sich, wenn Dateien vorkomprimiert sind? Die komprimierte und die unkomprimierte Datei sind zwei Repräsentationen unter derselben URL, daher benötigen Antworten Vary: Accept-Encoding. Laut RFC 9110 muss sich ein starker ETag einer Repräsentation mit Inhalts-Encoding von dem der Repräsentation ohne Inhalts-Encoding unterscheiden, um Konflikte bei Cache-Aktualisierungen und Bereichsanfragen zu verhindern. Server unterscheiden sich darin, wie viel sie davon für Sie übernehmen. Bei nginx sendet gzip_static eine vorhandene Datei mit der Endung .gz anstelle der regulären Datei, fügt Vary: Accept-Encoding jedoch nur hinzu, wenn gzip_vary aktiviert ist, was standardmäßig nicht der Fall ist. Keine der beiden nginx-Modulseiten beschreibt, wie der Wert von ETag bei einer Antwort mit .gz gebildet wird. Fordern Sie daher eine Datei mit und ohne Accept-Encoding: gzip an, vergewissern Sie sich anhand von Content-Encoding, dass nur die erste Antwort komprimiert ist, und vergleichen Sie die Header Vary und ETag beider Antworten. Wiederholen Sie die Prüfung über das CDN: gzip_static berücksichtigt auch gzip_proxied, und die zugehörige Standardeinstellung off deaktiviert die Komprimierung für Anfragen mit einem Header Via, sodass eine vom CDN weitergeleitete Anfrage die unkomprimierte Datei erhalten kann. Bei Apache komprimiert mod_deflate während der Auslieferung und hängt standardmäßig die Komprimierungsmethode an ETag an. Laut Dokumentation verhindert dies Antworten mit 304 auf bedingte Anfragen für komprimierte Inhalte.

Verwenden Sie lange Cache-Gültigkeitsdauern, wenn jede Inhaltsversion eine eindeutige URL hat, um Latenz und Last am Origin-Server zu reduzieren. Wenn Inhalte unter einer gleichbleibenden URL aktualisiert werden können, sind kürzere Cache-Zeiten oder eine erneute Validierung sicherer.

Dateien, die eine Assembly mit einem Robot zum Speichern exportiert, sind ab dann statische Inhalte: Sie liegen in Ihrem Bucket unter dem gewählten Pfad und werden von Ihrem Speicherdienst oder CDN ausgeliefert. Der Robot /s3/store nimmt ein Objekt headers entgegen, das für die gespeicherte Datei gesetzt wird, und /video/adaptive weist jedem Segment und jeder Playlist einen Wert für relative_path zu, damit die gespeicherte Struktur den Verweisen in den Playlists entspricht. Smart CDN ist das On-Demand-Gegenstück: Ein Ergebnis wird bei der ersten Anfrage erzeugt und anschließend zwischengespeichert. Der Robot /file/serve setzt den Header Cache-Control, den Browser und CDN erhalten und der sich mit cache_duration ändern lässt.

Ein Browser-Player, der HLS- oder MPEG-DASH-Dateien von einem anderen Ursprung als dem der Seite lädt, etwa von einem Bucket- oder CDN-Hostnamen, benötigt CORS-Header auf dem Server, der die Dateien ausliefert. Diese Header sind auf der Seite /video/adaptive aufgeführt. Sobald die exportierten Dateien gespeichert sind, ist Ihr Speicherdienst oder CDN für ihre Cache-Header zuständig.

Entdecken Sie Transloadits Möglichkeiten zur Auslieferung

Was sind statische Inhalte?

So funktionieren statische Inhalte

Wichtige Fakten

Wann statische Inhalte wichtig sind

So hilft Transloadit bei statischen Inhalten

Quellen

Machen Sie aus Medienwissen eine funktionierende Pipeline