Ein Content Delivery Network kann wiederverwendbare Antworten näher an Besuchern ausliefern und wiederholte Ursprungsanfragen reduzieren. Es hilft besonders, wenn die bremsenden Ressourcen cachebar sind und der gewählte Knoten eine nutzbare Kopie besitzt. Ein CDN repariert weder langsamen Anwendungscode noch große Bilder oder aufwendiges JavaScript automatisch. Ganze Seiten erfordern strengere Cache-Regeln als öffentliche statische Dateien.
Verfolgen Sie eine Anfrage bis zum Ursprung
Der Browser verbindet sich mit dem CDN-Endpunkt. Der Edge prüft, ob eine passende gespeicherte Antwort verfügbar und wiederverwendbar ist. Ein frischer Treffer braucht keinen Ursprungsabruf. Bei einem Miss wird gegebenenfalls der Ursprung angefragt und anschließend entschieden, ob dessen Antwort gespeichert werden darf.
Ein abgelaufenes Objekt ist nicht dasselbe wie ein leerer Cache. Das CDN kann validieren, ersetzen oder unter einer unterstützten Stale-Richtlinie ausliefern. Header und Dienstkonfiguration bestimmen das Verhalten. Lesen Sie die Statusdokumentation, statt jeden Wert außer HIT als gleichwertiges Ereignis zu behandeln.
CDNs können außerdem TLS terminieren, HTTP/2 oder HTTP/3 anbieten, komprimieren und Bilder transformieren. Diese Fähigkeiten sind unabhängig von Cache-Treffern und können Einstellungen oder bestimmte Tarife erfordern. Sie garantieren keine Beschleunigung. Ein naher Besucher mit schnellem Ursprung oder eine stets ungecachte Seite profitiert möglicherweise wenig von einer weiteren Ebene.
Der Leitfaden zur Serverantwortzeit trennt Verbindungsaufbau, Ursprungsverarbeitung und Auslieferung. Dadurch wird sichtbar, ob das CDN den tatsächlichen Engpass trifft. Ein schneller Stylesheet-Treffer gleicht kein HTML aus, das auf eine teure Datenbankabfrage wartet.
Stellen Sie die Standardregeln fest
Es gibt keinen universellen CDN-Standard. Viele Dienste speichern öffentliche Bilder, CSS und JavaScript, während HTML und API-Antworten passende Header oder Regeln brauchen. Andere unterscheiden nach Produkt, Ursprungstyp oder Cache-Modus. Eine Endung beweist keine Speicherung, und Cachebarkeit garantiert keinen dauerhaften Verbleib.
Prüfen Sie Dokumentation und Beispielantworten jeder Inhaltsklasse. Erfassen Sie Schlüssel, Methoden, Statuscodes, Cookie- und Autorisierungsbehandlung, Frischezeit und Ablaufverhalten. Aktivieren Sie keine pauschale Alles-cachen-Regel für Kontoseiten, nur weil eine Testseite schneller wird.
Diese Muster haben unterschiedliche betriebliche Anforderungen.
| Muster | Nutzen | Erforderliche Kontrolle |
|---|---|---|
| Öffentliche Fingerprint-Dateien | Gleiche Dateien zwischen Besuchern teilen | URL bei Byteänderung wechseln |
| Öffentliches HTML am Edge | Wiederholte Seitenerzeugung vermeiden | Eignung, Aktualität und Invalidierung festlegen |
| Persönliche Seiten ohne gemeinsamen Cache | Benutzerantworten isolieren | Sitzung und Autorisierung berücksichtigen |
| Öffentliche Hülle mit privaten Datenanfragen | Stabiles Layout teilen, Daten schützen | Private Endpunkte, sicheres Rendering und Authentifizierung |
Der Browser-Caching-Leitfaden behandelt den separaten Clientcache. Koordinieren Sie beide Regeln: Ein CDN-Purge widerruft keine noch zulässige lokale Browserkopie zuverlässig.
Definieren Sie einen Schlüssel für die tatsächliche Antwort
Der Cache-Schlüssel bestimmt, welche Anfragen ein Objekt teilen. Häufig enthält er Host, Pfad und einige oder alle Query-Parameter sowie dienstabhängige Varianten. Ändern Sprache, Währung oder Bildabmessungen die Antwort, muss der Schlüssel dies ausdrücken oder die Antwort vom gemeinsamen Cache ausschließen.
Ignorierte Trackingparameter können identische öffentliche Antworten zusammenführen. Alle Parameter zu ignorieren kann dagegen Filterseiten, Bildtransformationen oder signierte Anfragen vermischen. Normalisieren Sie anhand einer begründeten Positivliste. Unauffällige Parameternamen beweisen nicht, dass das Backend sie ignoriert.
Ein unnötig feingliedriger Schlüssel ist der Gegenfehler. Eindeutige Besucherkennungen verhindern gemeinsame Nutzung identischer Inhalte. Der vollständige Cookie-Header kann zahlreiche Kombinationen erzeugen. Verwenden Sie wenige explizite öffentliche Varianten, wenn dies zur Anwendung passt. Private Kontodaten gehören nicht in dieses Modell.
Notieren Sie zwei Anfragen, die teilen dürfen, und zwei, die getrennt bleiben müssen. Testen Sie diese Paare vor Veröffentlichung und nach Personalisierungsänderungen. So wird aus einer abstrakten Regel eine überprüfbare Aussage über ausgelieferte Inhalte.
Geben Sie öffentlichem HTML eine ausdrückliche Frischezeit
Cachen Sie HTML am Edge erst, nachdem Sitzungsidentität, Kontodaten, private Tokens und andere persönliche Ausgaben ausgeschlossen wurden. Begrenzen Sie Routen und Methoden und umgehen Sie den Cache bei Authentifizierung und relevanten Sitzungscookies. Der Dienst muss private und no-store respektieren; eine Überschreibung beseitigt deren Schutz.
Für tatsächlich öffentliches HTML trennt dieser Beispielheader Browser- und Shared-Cache-Frische.
Cache-Control: public, max-age=0, s-maxage=300Die Browserkopie wird sofort veraltet, während ein gemeinsamer Cache sie unter Berücksichtigung der HTTP-Altersberechnung und weiterer Regeln 300 Sekunden frisch halten kann. Diese Zahlen sind Beispiele, keine allgemeine Empfehlung. Wählen Sie die Laufzeit anhand akzeptabler Aktualisierungsverzögerung und zuverlässiger Invalidierung.
Kombinieren Sie sensible persönliche Antworten mit einem restriktiven Ursprungsheader und explizitem CDN-Bypass.
Cache-Control: no-storeEntfernen Sie Set-Cookie nicht nur für bessere Cachebarkeit, ohne seinen Zweck zu verstehen. Umgekehrt macht nicht jedes Cookie eine Anfrage privat: Ein Analyse-Cookie kann öffentliche Inhalte unverändert lassen. Entscheidend ist die tatsächliche Antwort. Unklare Fälle bleiben bis zur Prüfung außerhalb gemeinsamer Caches.
Bewerten Sie Treffer mit definiertem Nenner
Die Request-Trefferquote teilt Treffer durch die im Bericht enthaltenen Anfragen. Dienste zählen möglicherweise cachefähige Anfragen, sämtliche Anfragen oder bestimmte Statusklassen. Lesen Sie diese Definition vor Vergleichen. Eine Byte-Trefferquote beantwortet eine andere Frage als der Anteil getroffener Anfragen.
Trennen Sie HTML, Bilder, andere Dateien und gegebenenfalls Regionen. Eine hohe Asset-Quote kann kaum vorhandene HTML-Wiederverwendung verdecken. Eine selten an vielen Knoten angefragte Seite kann wiederholt missen, während eine populäre Datei warm bleibt. Lange Laufzeiten verhindern keine Verdrängung; mehr Knoten garantieren nicht jedes Objekt an jedem Ort.
Vergleichen Sie Treffer, Misses und Bypässe mit TTFB, Ursprungsvolumen und sichtbarer Ladeleistung. Trennen Sie kalte Anfragen nach Deployment vom Dauerbetrieb. Wiederholtes Laden einer warmen URL und Auswahl des schnellsten Ergebnisses repräsentiert nicht die gesamte Nutzerschaft. Der PageSpeed-Analyzer unterstützt Einzelprüfungen, ist aber kein netzweiter CDN-Quotenbericht.
Löschen Sie gezielt und veröffentlichen Sie in sicherer Reihenfolge
Bei Fingerprint-Dateien ist eine neue URL meist einfacher als Ersetzen unter derselben Adresse. Laden Sie Dateien vor dem referenzierenden HTML hoch und erhalten Sie ältere Dateien für offene Seiten und Sitzungen. Edge-Purges ersetzen diese Versionierung nicht.
Für stabile HTML-URLs verwenden Sie URL-Invalidierung oder unterstützte Inhaltstags, die abhängige Seiten gruppieren. Ein Artikelupdate kann Kategorie, Startseite und verwandte Inhalte verändern. Die Löschstrategie muss diese Abhängigkeiten abdecken, ohne unbeteiligte Assets auszuräumen.
Ein breiter Purge kann Miss-Spitzen und Ursprungsarbeit erzeugen. Legen Sie Berechtigte, Fehlerbehandlung und Erkennung alter Antworten fest. Testen Sie Veröffentlichung, Vorschau und Rücknahme vollständig, nicht nur die Annahme einer Purge-API-Anfrage. Verteilte Ausführung und Abschlussgarantien unterscheiden sich.
Origin Shielding leitet bei manchen Diensten Edge-Misses durch eine zusätzliche Cache-Ebene. Das kann Ursprungsanfragen zusammenfassen, erhöht aber Diagnose- und Invalidierungskomplexität. Es lohnt sich bei passender Last und Konfiguration, nicht automatisch durch eine weitere Ebene.
Erkennen Sie Fehler durch überlagerte Caches
Hostingcache, CDN und Browser können unterschiedliche Vorstellungen von Aktualität haben. Dokumentieren Sie Erzeuger und wiederverwendende Ebenen. Age kann das Antwortalter erläutern; dienstspezifische Statusfelder benötigen eigene Dokumentation. Ein einzelner Header erklärt nicht den vollständigen Weg.
Prüfen Sie vermeidbare HTTPS-, Host- und kanonische Weiterleitungen. Konfigurieren Sie Ursprungszertifikat und -authentifizierung auch dann, wenn Besucher nur das CDN erreichen. Eine schnelle Edge-Verbindung rechtfertigt keinen exponierten oder falsch gerouteten Ursprung.
Bilddienste erzeugen Varianten nach Größe, Format und Qualität. Beziehen Sie Transformationen in die Schlüssel ein, begrenzen Sie beliebige Varianten und prüfen Maße und Bytes. Der Leitfaden zur Bildoptimierung behandelt Ressourcenprobleme, die Nähe allein nicht löst.
Stale-Auslieferung benötigt eine Inhaltsentscheidung. Ein kurzzeitig älterer öffentlicher Artikel unterscheidet sich von veralteten Kontoberechtigungen oder Transaktionszuständen. Kopieren Sie Regeln für statische Inhalte nicht auf sensible Endpunkte. Dort bleiben Aktualität und Autorisierung Korrektheitsanforderungen.
Beginnen Sie mit einem begrenzten Rollout
Starten Sie mit einer öffentlichen Asset-Klasse und gegebenenfalls einer geprüften HTML-Route. Testen Sie kalte und wiederholte Anfragen, Dokumentänderung und Fehler. Zwei unabhängige Browsersitzungen müssen getrennte private Daten erhalten; Anmeldung und Abmeldung müssen das Verhalten korrekt ändern.
Erfassen Sie Header mit GET unter der echten öffentlichen URL Ihrer Umgebung.
curl -sS -D - -o /dev/null https://example.com/news/Prüfen Sie dokumentierten Cachestatus, Cache-Control, gegebenenfalls Age und den Antwortkörper. Vergleichen Sie über einen autorisierten Diagnoseweg mit dem Ursprung. Ein richtiger Status bei falschem Inhalt ist kein bestandener Test.
Bewahren Sie Eignungsregeln, Invalidierung und Rücknahme zusammen auf. Nutzen Sie die Sammlung zur Serverleistung und die offizielle CDN-Einführung bei Erweiterungen. Nehmen Sie die nächste Inhaltsklasse erst auf, wenn Nutzen und Aktualisierungsverhalten nachgewiesen sind.
