CDNs und Caching im Vergleich: Was ist der Unterschied?

Der folgende Blogpost wurde von einem Artikel übernommen, den Doc für „O'Reilly Radar“ geschrieben hat.

Da es sich bei einem CDN im Wesentlichen um einen Cache handelt, besteht die Versuchung, auf einen Browser-Cache zu verzichten, um Komplexität zu vermeiden. Jeder dieser Cache-Typen hat aber seine eigenen Vorteile, die wir Ihnen in diesem Blogpost erklären. Außerdem erfahren Sie, wie Sie beide Caches für eine optimale Website-Performance – und ein ideales Endnutzererlebnis – kombinieren können.

Was bedeutet Cache Busting?

Beim Cache Busting wird eine neue Datei hochgeladen, um eine bereits vorhandene und im Cache befindliche Datei zu ersetzen. Cache Busting ist hilfreich, weil es den Browser daran hindert, die alte zu ersetzende Datei abzurufen.

Weshalb sollte man CDN Cache Browsing verwenden?

CDNs sind zwar gut darin, Inhalte sehr schnell bereitzustellen, aber sie helfen wenig bei Nutzern, die in ländlichen Regionen leben und kaum Mobilfunkempfang haben. Tatsächlich liegt laut Berichten von Cedexis in den USA das 95. Perzentil für die Round Trip Time (RTT) zu allen CDNs bei weit über 200 Millisekunden. Das bedeutet, dass mindestens 5 % Ihrer Nutzer, wenn nicht sogar mehr, wahrscheinlich eine langsame Erfahrung mit Ihrer Website oder Anwendung machen. Zum Vergleich: Das 50. Perzentil bzw. der Median der RTT liegt bei 45 Millisekunden.

Warum sollte man überhaupt ein CDN verwenden? Warum kann man sich nicht einfach auf den Browser-Cache verlassen?

1. Kontrolle. Bei den meisten CDNs können Sie Ihre Assets aus dem Cache löschen. Das ist sehr nützlich, wenn Sie Änderungen an Ihren Assets vornehmen. Mit dem Browser-Cache ist das nicht möglich.

2. Der erste Eindruck zählt. Der Browser-Cache ist beim ersten Besuch eines Nutzers auf Ihrer Website überhaupt nicht hilfreich, denn er enthält noch keine nützlichen Objekte. CDNs sorgen mit einem leeren Browser-Cache für ein möglichst schnelles Nutzererlebnis und bei einem vollen Browser-Cache werden aufeinanderfolgende Seiten sogar noch schneller.

3. CDNs bieten trotz allem einen geografischen Vorteil. Selbst wenn ein Nutzer in das 95. Perzentil fällt, ist eine RTT von 250 Millisekunden immer noch besser als eine RTT von 350 Millisekunden. Vor allem, wenn Sie bedenken, dass jedes Asset bei einer offenen Verbindung mindestens einen Round Trip benötigt, Sie aber einen zusätzlichen Round Trip zum Öffnen der Verbindung einplanen müssen. Transport Layer Security (TLS – früher als SSL bezeichnet) fügt mindestens einen weiteren Hin- und Rückweg pro Verbindung hinzu, manchmal sogar zwei. All diese zusätzlichen Round Trips summieren sich schnell.

4. CDNs sind viel effizienter, da ihr Cache von all Ihren Nutzern gemeinsam genutzt wird. Dies bedeutet eine geringere Belastung Ihrer Origin-Server, ohne dass Sie einen eigenen Caching Layer in Ihrer Plattform benötigen.

Wie Sie sowohl ein CDN als auch den Browser-Cache verwenden können

Nachdem wir nun festgestellt haben, dass ein CDN nach wie vor wichtig ist und dass der Browser-Cache ebenfalls sehr wertvoll ist, hier zwei Ansätze, um beides zu kombinieren:

1. Eine kurze Time to Live (TTL) für den Browser-Cache kombiniert mit langen TTLs und Bereinigung auf Seiten des CDN.

2. Eine lange TTL sowohl für das CDN als auch für den Browser-Cache, aber mit versionsbasierten Cache-Bustern.

Ich möchte Ihnen im Folgenden jeden Ansatz im Detail vorstellen und auch erläutern, wie Sie sogar eine Kombination der beiden Ansätze verwenden können.

Kurze und lange TTLs

Idealerweise verwenden Sie eine TTL für den Browser-Cache, die einen gesamten Besuch abdeckt, aber nicht viel mehr. Auf diese Weise können Ihre Nutzer die Seiten während ihres Besuchs schnell laden, bekommen aber keine veralteten Inhalte angezeigt, wenn sie später zurückkehren. Ihre Analysetools sollten Ihnen sagen können, wie die Besuchszeiten für Ihre Website aussehen, aber im Allgemeinen sind 5 oder 10 Minuten ein guter Richtwert.

Bei Fastly würde ich empfehlen, eine TTL von etwa einem Monat oder einem Jahr zu verwenden und die Bereinigung als Teil Ihrer Bereitstellungspipeline einzurichten, damit Fastly die neuen Versionen so schnell wie möglich bereitstellen kann. Weitere Informationen zum Thema Purging finden Sie unter https://docs.fastly.com/guides/purging/.

Denken Sie daran: Senden Sie den Bereinigungsbefehl erst dann, wenn die neuen Versionen der aktualisierten Assets garantiert vom Origin-Server bereitgestellt werden. Ich habe Fälle erlebt, in denen jemand einen Bereinigungsbefehl an Fastly gesendet hat und Fastly die Datei sofort abgerufen hat, bevor die Datei mit den Origin-Servern synchronisiert wurde, was zu einer Menge Verwirrung geführt hat.

Um die TTL des Browser-Cache festzulegen, verwenden Sie den Cache-Control-Header in Ihrer Antwort vom Origin-Server. Verwenden Sie dann entweder den Surrogate-Control-Header oder eine Überschreibung in Ihrer Fastly-Konfiguration, um die TTL dort einzustellen.

Hier ein Beispiel für die erste Variante:

Cache-Control: max-age=600
Surrogate-Control: max-age=31536000

In dem Beispiel oben weist der Cache-Control-Header den Browser an, die Datei 10 Minuten lang zwischenzuspeichern, und er weist Fastly an, sie ein Jahr lang zwischenzuspeichern. Der Surrogate-Control-Header wird entfernt, bevor die Antwort an den Client gesendet wird, sodass dieses Detail der Implementierung den Nutzern verborgen bleibt. Weitere Informationen über die verschiedenen Header, die Sie zur Steuerung der TTL mit Fastly verwenden können, finden Sie in unserer Dokumentation.

Versionsabhängige Cache-Buster

Auch wenn der Name es anders vermuten lässt, können Cache-Buster das Cachen tatsächlich verbessern, wenn sie sinnvoll eingesetzt werden. Im Grunde ist ein Cache-Buster ein neuer Query-String-Parameter, der der URL hinzugefügt wird. Während Webserver und die meisten Anwendungsserver Query-String-Parameter, die für sie nicht von Bedeutung sind, einfach ignorieren, müssen Caches davon ausgehen, dass jeder Unterschied im Query-String einen Einfluss auf das Ergebnis hat. Das gilt auch für den Browser-Cache. Browser müssen jedes der folgenden Objekte als drei einzigartige Objekte behandeln, auch wenn der Server für alle die gleiche Antwort zurückgibt:

https://www.example.com/css/main.css, https://www.example.com/css/main.css?cb=foo, und https://www.example.com/css/main.css?foo=bar

Angenommen, Ihre App läuft auf Build 133. Statt mit https://www.example.com/css/main.css würde Ihre App mit https://www.example.com/css/main.css?v=133 verlinkt werden. Wenn Sie Build 134 erstellen, verlinken Sie stattdessen mit https://www.example.com/css/main.css?v=134. Jetzt muss der Browser diese neue Version von main.css abrufen, obwohl immer noch eine nicht abgelaufene Kopie vorliegt.

Üblicherweise wird entweder ein (kurzer) Hash des Dateiinhalts, eine Build-Nummer oder ein Commit-Hash verwendet.

Ich persönlich ziehe es vor, einen Hash des Dateiinhalts zu verwenden. Auf diese Weise ändert sich der Cache-Buster nur, wenn der Inhalt geändert wird. Bei Build-Nummern oder Commit-Hashes ändert sich der Cache-Buster immer dann, wenn sich etwas ändert. Da jedoch alle URLs von Assets auf Ihrer Website den Cache-Buster haben müssen, kann es einfacher sein, die Build-Nummer oder den Commit-Hash zu verwenden.

Der Nachteil dieses Ansatzes ist, dass Sie bei jeder Änderung alle URLs der Assets aktualisieren müssen. Der Vorteil ist, dass Sie Ihre Assets im Browser mit lange gültigen TTLs zwischenspeichern können und der Browser trotzdem neue Assets abrufen kann, wenn sein Cache veraltet ist.

Kombinationsmöglichkeiten nach Maß

Da Sie mit dem CDN von Fastly veraltete Inhalte innerhalb von 150 ms löschen können, sollten Sie in Erwägung ziehen, auch alle Ihre HTML-Seiten zu cachen. Aber selbst wenn Sie Ihre Website so umgestalten können, dass Sie Cache-Buster für Assets wie Bilder, Stylesheets und JavaScript verwenden, sollten Sie Cache-Buster niemals für die URLs der eigentlichen Seiten verwenden – Suchmaschinen wie Google bestrafen Query-Strings in Seiten-URLs.

Wenn Sie also Seiten zwischenspeichern, sollten Sie die Technik der kurzen und langen TTL für Ihre Seiten und Cache-Buster für die Assets dieser Seiten verwenden.

Revalidierung für Fortgeschrittene

Ein sehr netter Nebeneffekt des Browser-Cache ist, dass die Browser Objekte auch nach Ablauf ihrer Gültigkeit behalten und zusätzliche Revalidierungs-Header mit ihren Anfragen senden. Wenn sich das angeforderte Objekt nicht geändert hat, kann Ihr CDN einfach mit einem Status 304 Not Modified antworten, der keinen Text enthält und dem Browser mitteilt, dass er das abgelaufene Objekt verwenden und optional eine neue TTL angeben kann.

Selbst wenn jede Anfrage mit einer 304-Antwort per se einen Round Trip benötigt, bedeutet das Fehlen des Textes der Antwort eine erhebliche Bandbreiteneinsparung. Das ist nicht nur ein Vorteil für Nutzer mit langsamen Verbindungen, sondern kann auch Ihre monatlichen CDN-Kosten senken.

Damit die Revalidierung funktioniert, müssen Sie nur sicherstellen, dass Ihr Origin-Server in seinen Antworten die Header Last-Modified oder ETag einfügt. Die gute Nachricht ist, dass die meisten Webserver bereits die Header Last-Modified und ETag für alle von Festplatten bereitgestellten statischen Dateien enthalten. Der Wert des Headers Last-Modified basiert auf der Änderungszeit der Datei. Der Wert des Headers ETag basiert (bei Apache) auf dem Änderungszeitpunkt, der Inode-Nummer und der Größe.

Wenn ein Browser einen dieser beiden Header oder beide bei abgelaufenen Objekten in seinem Cache feststellt, fügt er den Header If-Modified-Since mit dem Wert von Last-Modified und den Header If-None-Match mit dem Wert von ETag hinzu. Ein Objekt gilt als unverändert, wenn die Werte von If-None-Match und ETag gleich sind und wenn der Wert von If-Modified-Since entweder mit dem Wert von Last-Modified übereinstimmt oder nach diesem liegt.

Wenn Sie einen einzigen Webserver für Ihre statischen Assets verwenden, funktioniert die Revalidierung aufgrund der üblichen Standardeinstellungen wahrscheinlich bereits perfekt.

Wenn Sie jedoch mehrere Webserver verwenden, um für Redundanz zu sorgen, und jeder dieser Server über einen lokalen Speicher anstelle eines gemeinsamen Speichers verfügt, könnte die Revalidierung zufällig fehlschlagen. Da Sie nicht garantieren können, dass einer bestimmten Datei auf jedem Webserver dieselbe Inode-Nummer zugewiesen wird, wird der für sie generierte ETag-Header von Server zu Server unterschiedlich sein. Außerdem behalten die meisten Bereitstellungsskripte beim Kopieren von Dateien die Änderungszeit nicht bei, sodass auch der Header Last-Modified unterschiedlich ausfällt.

Dies ist aus zwei Gründen kontraproduktiv. Erstens: Wenn Fastly mit Ihrem Origin-Server kommuniziert, könnte eine Menge unnötiger Bandbreite für vollständige Antworten anstelle von 304-Antworten verschwendet werden. Zweitens kann es passieren, dass Fastly auf verschiedenen Servern unterschiedliche Werte für ETag und Last-Modified hat. Da nicht sichergestellt ist, dass Browser bei jeder Anfrage mit demselben Server kommunizieren, könnten sie aufgrund der unterschiedlichen Werte auch unnötige Vollantworten erhalten.

Um sich die Revalidierung optimal zunutze zu machen, wenn Sie mehrere Webserver mit lokalem Speicher haben, empfehle ich, ETag zugunsten der ausschließlichen Verwendung von Last-Modified zu deaktivieren und dafür zu sorgen, dass Ihr Bereitstellungsskript beim Kopieren von Dateien die Änderungszeit beibehält.

Wenn Sie einen Cloud-Speicheranbieter wie Google Cloud Storage oder Amazon S3 verwenden, sollte der Header ETag bereits automatisch auf einen Hash des Inhalts gesetzt sein. Dadurch wird der Cloud-Speicher zu einem der optimalsten Origin-Server für Fastly, da das erneute Hochladen der exakt gleichen Datei den ETag nicht verändert.

Weitere Ressourcen

Wir hoffen, dass Sie diesen Blogpost zur Optimierung Ihres CDN und Browser-Cache hilfreich fanden. Wenn Sie an der Feinabstimmung Ihrer Performance-Messung (und der Maximierung der CDN-Performance) interessiert sind, empfehle ich Ihnen diese Blogposts von unserem VP of Technology, Hooman Beheshti: „The truth about cache hit ratios“ und „Cache hit ratios at the edge“ (jeweils nur auf Englisch verfügbar).