Cache Trefferverhältnis: was es ist und wie Sie Ihre über 95% erhalten
Es ist die eine Zahl, die Ihnen sagt, ob Ihr CDN tatsächlich seine Arbeit tut. Was es bedeutet, die fünf Dinge, die es normalerweise zerstören, und wie man herausfindet, welche deine zerstört.
Sie stellen die Seite hinter ein CDN, das Dashboard ist seit einer Woche auf, und das Cache-Hit-Verhältnis sagt 61%. Ist das schlimm? Sollten Sie sich Sorgen machen? Was machst du überhaupt?
Dies kommt eine Menge, und die ehrliche Antwort ist, dass 61% wahrscheinlich schlecht ist, aber nicht unbedingt - es hängt ganz davon ab, was Ihre Website ist. Fangen wir also damit an, was die Zahl eigentlich bedeutet, dann arbeiten wir durch Diagnosen, denn die Lösung ist fast immer eines von fünf spezifischen Dingen.
Was die Zahl bedeutet
Jede Anfragetroffend bereits eine frische Kopie hatte und sofort servierte. Ein Fehl bedeutet, dass es nicht, so fragte es Ihren Ursprung, wartete, übVermissen.
Eine Miss ist nicht nur langsamer für diesen einen Besucher. Es ist eine Anfrage, die Ihr Ursprung zu handhaben hat, Bandbreite, die Sie auf beiden Beinen bezahlen, und ein wenig weniger Spielraum für, wenn Verkehr Spitzen. Multiplizieren Sie ein niedriges Verhältnis über Millionen von Anfragen und Sie betreiben ein globales Netzwerk als kostspieliger Passthrough.
Bitten oder Bytes?
Wissenswert, bevor Sie Zahlen mit jemandem vergleichen: Einige Dashboards berichten Trefferquote nach Anfragezahl, andere von Bytes bedient. Sie können sich wild unterscheiden. Eine Seite, die ein riesiges uncached Video unter einer Million kleinen Cache-Assets serviert, hat ein hervorragendes Request-Verhältnis und ein schreckliches Byte-Verhältnis. Wenn Ihre Bandbreitenrechnung und Ihr Trefferverhältnis zu widersprechen scheinen, ist dies in der Regel, warum — überprüfen Sie, welche Sie betrachten.
Was ist eigentlich ein gutes Verhältnis?
Die "über 95%" im Titel ist ein vernünftiges Ziel für die meisten Websites, aber es ist nicht universell, und es auf der falschen Art von Website zu jagen ist verschwendet Aufwand.
| Standorttyp | Realistisches Ziel | Warum? |
|---|---|---|
| Statische Website, docs, Marketing | 98%+ | Fast nichts ist persönlich |
| Blog oder Verlag | 95–98% | Langlebige Seiten, starke Wiederverwendung der Vermögenswerte |
| Shop mit ganzseitigem Caching | 85–95% | Warenkorb, Kasse und Konto immer umgehen |
| Nur Asset-Zone (Bilder, JS, CSS) | 99% | Wenn es niedriger ist, ist etwas falsch konfiguriert |
| Eingeloggte App | Verändert sich wild | Vermögenswerte und Seiten der Richter getrennt |
Zwei Dinge folgen von diesem Tisch. Erstens, wenn Sie einen Shop laufen, keine Panik bei 88% - ein Stück Ihres Traffics ist Checkout und Kontoseiten, die nie zwischengespeichert werden dürfen, und ohne sie richtig ist das System funktioniert. Zweitens, wenn Sie eine separate Zone für statische Vermögenswerte haben und sie unter 99% liegt, ist das eine echte Fehlkonfiguration und zehn Minuten Ihrer Zeit wert.
Diagnose eines niedrigen Verhältnisses
In grober Reihenfolge, wie oft sich jeder als Schuldiger erweist:
1. Ihr Ursprung sagt dem CDN, dass es nicht zwischenspeichern soll
Dies ist die häufigste Ursache durch eine Entfernung, und die befriedigendste zu beheben, weil es in der Regel ein Header ist. Ein Streuner Cache-Control: no-store, privateoder max-age=0 sagt die Kante, um das Caching vollständig zu überspringen. Frameworks fügen diese standardmäßig häufiger hinzu, als Sie erwarten würden, insbesondere für HTML.
Prüfen Sie, was Ihre Herkunft tatsächlich sendet, nicht, was Sie denken, es sendet:
curl -sI https://origin.example.com/some-page | grep -iE 'cache-control|set-cookie|vary'2. Query Strings fragmentieren den Cache
Wenn /product, /product?utm_source=newsletter und /product?fbclid=abc123 sind drei separate Cache-Einträge, eine beliebte Seite ist ruhig zu mehreren hundert Einträgen geworden, jeder mit einem Publikum von einem. Jede Aktie auf Social Media erzeugt einen brandneuen Cache-Schlüssel, der nie wieder angefordert wird.
Nachverfolgungsparameter aus dem Cache-Schlüssel entfernen. Sie sind wichtig für Ihre Analysen, die sie im Browser liest, und überhaupt nicht, zu dem Bytes Sie zurückkehren.
3. Cookies auf Dinge, die sie nicht benötigen
A Set-Cookie header auf einem statischen Asset lässt das CDN diese Antwort als personalisiert behandeln und weigern, sie zu speichern. Ihr Logo benötigt keinen Cookie. Session Middleware, die auf jeder Route läuft, einschließlich Asset-Routen, ist die übliche Quelle.
4. TTLs sind zu kurz
Wenn der Inhalt nach 60 Sekunden abläuft, verbringt der Rand sein Leben damit, Dinge wieder zu spüren, die sich nicht verändert haben. Abschreibungen — app.a1b2c3.css — kann sicher für ein Jahr zwischengespeichert werden, da eine neue Version einen neuen Dateinamen erhält. HTML will normalerweise etwas kürzeres, aber "kürzeres" kann noch Stunden bedeuten, wenn Sie auf veröffentlichen reinigen können.
5. Ein Vary Header, den Sie nicht senden wollten
Die subtile. Vary: User-Agent macht den Kantenspeicher zu einer separaten Kopie pro User-Agent-String, und es gibt effektiv unbegrenzte User-Agent-Strings. Ihr Trefferverhältnis kollabiert und nichts in Ihrer Konfiguration sieht falsch aus. Vary: Accept-Encoding ist gut und erwartet; fast alles andere verdient einen zweiten Blick.
Wenn Sie nur eine Sache tun: Sortieren Sie Ihre CDN-Protokolle nach Cache-Status, Filter zu verpassen, und gruppieren Sie nach URL. Die Top zwanzig Misses werden Ihnen sagen, welche der fünf oben Sie haben, in der Regel innerhalb einer Minute. Ich schätze, es dauert länger als zu suchen.
Warum 100% das falsche Ziel ist
Sie können nicht 100% erreichen, und eine Website, die es tat, wäre verdächtig. Cache-Einträge verjähren rechtmäßig. Neue Inhalte müssen einmal abgerufen werden. Reinigt absichtlich den Cache. Und eine wirklich personalisierte Seite – ein Warenkorb, ein Konto-Dashboard – sollte jedes Mal fehlen, denn Caching wäre ein Fehler und möglicherweise ein Datenleck.
Die zu beobachtende Zahl ist nicht der absolute Wert, sondern ihre Form im Laufe der Zeit. Ein Verhältnis von 96% und jetzt 78% bedeutet etwas geändert: Eine Bereitstellung veränderte Ihre Header, eine Kampagne fügte neue Abfrageparameter hinzu, oder jemand schickte ein Cookie auf Ihren Asset-Routen. Plötzliche Bewegung ist ein Signal. Ein konstantes 91% auf einem Geschäft ist nur Dienstag.
Häufig gestellte Fragen
Was ist ein gutes Cache-Hit-Verhältnis?
Es hängt von der Seite ab. Eine statische oder Marketing-Website sollte 98% oder höher, ein Blog 95 bis 98%, und ein Shop mit ganzseitigen caching in der Regel 85 bis 95%, weil Cart, Checkout und Konto-Seiten immer den Cache umgehen müssen. Eine Zone, die nur statische Vermögenswerte bedient, sollte bei 99% liegen; alles niedrigere deutet normalerweise auf eine Fehlkonfiguration hin.
Wie kann ich mein Cache Hit-Verhältnis verbessern?
Arbeiten Sie durch fünf Ursachen in der Reihenfolge: Cache-Steuerkopfzeilen auf Ihrem Ursprung, die Caching verhindern, Abfrage-Strings wie utm_source Fragmentierung einer Seite in viele Cache-Einträge, Set-Cookie-Header auf statischen Assets, TTLs, die sind zu kurz, und eine überbreite Vary-Header wie Vary: User-Agent. Sortieren Ihrer CDN-Protokolle nach Cache-Status und Gruppierung verpasst durch URL identifiziert, welche man schneller als Vermutungen anwendet.
Warum ist mein Cache-Hit-Verhältnis niedrig, obwohl Caching aktiviert ist?
Fast immer, weil etwas in der Antwort dem CDN sagt, es nicht zu speichern. Die üblichen Schuldigen sind ein Cache-Control Header von no-store, private oder max-age=0, der von Ihrem Anwendungs-Framework gesendet wird, ein Set-Cookie Header für Antworten, die geteilt werden sollen, oder ein Vary Header, der auf etwas mit variiert unbegrenzte Werte wie User-Agent. Führen Sie Curl -I gegen Ihren Ursprung und überprüfen Sie die tatsächlichen Header.
Verlangsamt ein Cache den Besucher?
Doch. Ein Cache-Hit wird typischerweise in weniger als 20 Millisekunden vom nächsten Rand aus bedient, während ein Miss eine komplette Rundreise zu Ihrem Ursprung erfordert, sowie die Zeit, die Ihr Ursprung benötigt, um die Antwort zu generieren — häufig 200 Millisekunden oder mehr, und für Besucher auf einem anderen Kontinent erheblich schlechter. Jede Miss verbraucht auch Ursprungskapazität und Bandbreite, für die Sie bezahlen.
Sollte ich auf ein 100% Cache Trefferverhältnis zielen?
Nein. Cache-Einträge verfallen rechtmäßig, neue Inhalte müssen mindestens einmal abgerufen werden und entleeren den Cache bewusst. Echt personalisierte Seiten wie Carts und Account Dashboards sollten jedes Mal fehlen – Caching wäre ein Fehler und ein möglicher Datenleck. Achten Sie auf plötzliche Tropfen, anstatt eine absolute Zahl zu jagen.
Also: 61%. Ziehen Sie Ihre Miss-Liste, schauen Sie sich die Top 20 URLs, und es gibt eine gute Chance, dass Sie entweder eine unbeabsichtigte no-store oder einem Stapel von ?utm_source= Varianten. Beides ist eine Konfigurationsänderung, kein Projekt.
Sehen Sie, wie NordicCDN dies für Ihre Website tut:
Mads hat seit seinem 16. Lebensjahr in der IT gearbeitet — hauptsächlich als Hosting. Er beteiligte sich früh an einer SaaS-Firma und half, sie bis zur Übernahme durch Visma weiterzuentwickeln, hat Data-Center-Netzwerke aufgebaut und betrieben und diente als CTO eines dänischen Rechenzentrums. Er hat NordicCDN gestartet, um eine schnelle, sichere Infrastruktur einfach zu bedienen.
