Vielleicht kennst du das. Du hast endlich die Firmenwebsite aktualisiert ── aber beim Öffnen starrt dich immer noch die alte Version an. Oder umgekehrt: Man sagt dir „die Seite ist jetzt repariert“, doch auf deinem Bildschirm hat sich nichts geändert. Du suchst herum oder fragst den Support, und die Antwort ist fast immer dieselbe: „Bitte leere deinen Cache.“ Du tust es, und tatsächlich: Es funktioniert. Aber die wenigsten können erklären, was sie da gerade gelöscht haben ── oder warum das Löschen geholfen hat.
Dieser Artikel erklärt von Grund auf, was der Cache wirklich ist. Die ganze Landkarte in einer Zeile: Der Cache ist genau der Grund, warum dieselbe Seite beim zweiten Mal schneller öffnet ── und der Vorfall „ich habe aktualisiert, aber nichts hat sich geändert“ ist die Nebenwirkung, die man für diese Geschwindigkeit bezahlt. Beides sind Vorder- und Rückseite desselben Mechanismus. Kommt dir etwas davon bekannt vor, lies weiter.
- Eine Website wurde aktualisiert, zeigte aber weiter die alte Version ── auf deinem Bildschirm oder dem deiner Besucher
- Man sagt dir „leere den Cache„, aber du könntest nicht erklären, was das eigentlich tut
- Du hast dich nie gefragt, warum dieselbe Seite beim zweiten Mal deutlich schneller öffnet
- Du leerst den Cache mit mulmigem Gefühl, unsicher, ob dich das überall ausloggt
Damit auch Einsteiger gut folgen können, geht dieser Artikel sparsam mit Fachbegriffen um. Und er bleibt nicht bei der Funktionsweise stehen ── er geht bis zu den praktischen Entscheidungen: in welcher Reihenfolge man das „nichts hat sich geändert“ behebt und was beim Cache-Leeren wirklich passiert.
| Frage | Abschnitt |
|---|---|
| Was ist der Cache denn nun wirklich? | §1 |
| Wo wohnt der Cache? | §2 |
| Wie lange zeigt sich die alte Version noch? | §3 |
| Warum passiert „ich habe aktualisiert, aber nichts hat sich geändert“? | §4 |
| Wie behebe ich es? | §5 |
| Loggt mich das Cache-Leeren aus? | FAQ Q1 |
In der Serienübersicht Was passiert zwischen dem Eintippen einer URL und dem Erscheinen der Seite? hieß es, der „durch ein veraltetes Lager verursachte Vorfall füllt einen eigenen Artikel“. Das hier ist dieser Artikel.
1. Was der Cache wirklich ist ── einmal geholte Materialien wiederverwenden
1-1. Eine Seite besteht aus Dutzenden geholter Materialien
Wenn du eine Seite öffnest, kommt nicht eine einzelne Datei an. Zuerst trifft der Bauplan (HTML) ein, und während der Browser ihn liest, holt er jedes fehlende Material ── Bilder, die Gestaltungsanweisungen (CSS), die beweglichen Teile (JavaScript) ── eines nach dem anderen vom Server (das Gesamtbild dieses Ablaufs steht in Was passiert zwischen dem Eintippen einer URL und dem Erscheinen der Seite?). Dutzende Materialien für eine einzige Nachrichtenseite sind völlig normal.
Denk einmal darüber nach. Wenn du dieselbe Website morgen besuchst, ist ihr Logo dasselbe wie heute. Die Gestaltungsanweisungen mit ziemlicher Sicherheit auch. Identische Dateien jeden Tag aufs Neue um die halbe Welt zu holen, ist offensichtlich Verschwendung, oder?
1-2. Deshalb führt der Browser ein lokales Lager ── das ist der Cache
Also legt der Browser einmal geholte Materialien eine Weile in ein lokales Lager (einen Speicherbereich in deinem PC). Beim nächsten Öffnen derselben Seite überspringt jedes Material, das schon im Lager liegt, den Botengang komplett und kommt direkt aus dem Regal ── dieser Mechanismus und der Lagerinhalt sind der Cache.
Genau darum „geht’s beim zweiten Mal schneller“. Beim ersten Besuch muss jedes dieser Dutzenden Materialien geholt werden; beim zweiten kommt das meiste direkt aus dem Lager. Je mehr Botengänge man sich spart, desto schneller öffnet die Seite.
Erster Besuch vs. zweiter Besuch Erster Besuch (jedes Material wird geholt) Bauplan HTML : du <──────── Server Logo : du <──────── Server Design CSS : du <──────── Server △ ein Botengang pro Material Skripte JS : du <──────── Server Zweiter Besuch (direkt aus dem Regal) Bauplan HTML : du <──────── Server Logo : du <── [lokales Lager] Design CSS : du <── [lokales Lager] △ der Botengang entfällt komplett Skripte JS : du <── [lokales Lager]
1-3. Cookies haben eine völlig andere Aufgabe
Weil sie im Lösch-Dialog immer nebeneinanderstehen, werden Cookies und Cache ständig verwechselt ── dabei haben ihre Aufgaben nichts miteinander zu tun. Das Cookie ist die Mitgliedskarte, die der Website sagt, „wer du bist„; der Cache ist das Wiederverwenden von Materialien, die „für alle gleich“ sind. Ein Logo ist dasselbe Logo, egal ob für dich oder irgendjemand anderen ── also darf es aus dem Lager wiederverwendet werden; eine Mitgliedskarte verwendet man nicht für andere wieder. Auch das Löschen unterscheidet sich entsprechend: Lösch die Cookies, und du bist ausgeloggt; leere den Cache, und Seiten laden nur eine Weile langsamer (in FAQ Q1 sortieren wir das noch einmal).
2. Caches gibt es überall ── das Browser-Lager ist nur eines davon
2-1. „Cache“ ist der Name einer Idee, nicht einer Funktion
Ein wichtiger Punkt: „Cache“ ist nicht der Name einer bestimmten Browserfunktion. Es ist der Sammelname für eine Idee ── statt etwas erneut zu holen, die griffbereit aufbewahrte Kopie wiederverwenden. Und diese Idee wird in allen Ecken der Computerwelt benutzt.
| Wo | Kopie wovon | Verwandter Artikel auf dieser Seite |
|---|---|---|
| Das Lager des Browsers | Seitenmaterialien (Bilder, CSS, JS) ── der Star dieses Artikels | Dieser Artikel |
| Die Telefonbuchnotizen | Antworten auf Nachschlagen: „die Adresse (IP) dieser Website ist hier“ | Was ist DNS? §5 |
| Gemeinschaftslager in Büros und Netzen | Beliebte Materialien, gesammelt für alle im Netz | ── |
| Die Lager des Liefernetzes (CDN) | Kopien der Materialien einer Website, weltweit verteilt | Für einen künftigen Artikel geplant |
| Ultraschneller Speicher in der CPU | Kopien von Rechendaten (L1/L2/L3-Cache) | Das Speicherhierarchie-Diagramm im Neustart-Artikel |
Wenn du unseren DNS-Artikel gelesen hast, erinnerst du dich an dies: „Hast du eine Nummer einmal nachgeschlagen, behalte die Notiz eine Weile und frag nicht noch einmal.“ Das ist exakt dieselbe Idee. Ob Nachschlage-Antwort (DNS) oder die Ware selbst (Seitenmaterialien) ── das Muster ist identisch: Kopie wiederverwenden, Botengang sparen.
2-2. Mehr Schichten bedeuten mehr Tempo ── und mehr Orte für veraltete Kopien
Gerade weil all diese Cache-Schichten übereinandergestapelt sind, läuft das Internet in seinem heutigen Tempo. Würde jeder Zugriff weltweit jeden Botengang jedes Mal vollständig machen, hielten weder die Leitungen noch die Server durch.
Aber das erzeugt die Eigenschaft, um die sich dieser Artikel dreht. Mehr Orte mit Kopien bedeuten mehr Orte, an denen eine veraltete Kopie liegen bleiben kann. Dein Lager ist frisch, aber ein Gemeinschaftslager auf dem Weg hält noch die alte Kopie ── das kann absolut passieren. Diesen Faden nehmen wir in §4 wieder auf.
Die „Website-Seite“ jener Tabelle ── was genau der Server ist, der die Originalmaterialien hält ── verdient einen eigenen Artikel. Wir planen, das in einem künftigen Beitrag zu behandeln.
3. Wie lange darf eine Kopie wiederverwendet werden? ── Haltbarkeitsetiketten und Bestandsanfragen
3-1. Jedes Paket trägt ein Haltbarkeitsetikett
Würde das Lager seine Ware ewig wiederverwenden, käme kein Website-Update jemals auf deinem Bildschirm an. Aber würde der Browser für jeden einzelnen Artikel beim Server anrufen ── „ist das noch gut?“ ──, verlöre das Sparen des Botengangs die halbe Pointe.
Der Kompromiss ist das Haltbarkeitsetikett. Wenn der Server ein Material übergibt, klebt er dem Paket eine Frist auf: „bis zu einer Stunde wiederverwenden“, „dieses hält ein Jahr“ (technisch eine Angabe namens Cache-Control ── den Namen muss man sich nicht merken). Alles innerhalb der Frist nimmt der Browser direkt aus dem Regal und fragt den Server nicht einmal. Das ist der schnellste Weg.
Die Frist legt die Website fest, Material für Material. Ein Logo, das sich fast nie ändert, bekommt eine lange Frist; ein häufig wechselnder Startseiten-Bauplan (HTML) eine kurze ── das ist die typische Aufteilung.
3-2. Abgelaufen heißt nicht weggeworfen ── die Bestandsanfrage
Wirft der Browser die Ware also weg und holt alles neu, sobald die Frist abläuft? Noch nicht ── es gibt einen weiteren cleveren Schritt: die Bestandsanfrage.
Der Browser fragt den Server schlicht: „Dieser Artikel ── noch brauchbar?“ Hat sich serverseitig nichts geändert, ist die gesamte Antwort eine Zeile: „noch gut, weiterverwenden“ ── die Ware selbst wird nicht verschickt (technisch eine kurze Antwort namens 304). Wie groß die Datei auch ist, die Anfrage selbst dauert einen Augenblick ── auch dieser Weg ist schnell. Nur wenn sich der Artikel wirklich geändert hat, kommt ein neues Paket, frisches Etikett inklusive.
- 1Innerhalb der FristDirekt aus dem Regal. Der Server wird nicht einmal gefragt (am schnellsten).
- 2Abgelaufen → Anfrage → „noch gut“Eine Ein-Zeilen-Antwort erledigt es; keine Ware wird verschickt (immer noch schnell).
- 3Abgelaufen → Anfrage → „hat sich geändert“Ein neues Paket kommt an und ersetzt die Kopie im Regal (wie ein Erstbesuch).
3-3. Die Telefonbuchnotizen tragen dasselbe Etikett
Kommt dir diese Regel ── wiederverwenden bis zur Frist, dann neu holen ── bekannt vor? Es ist exakt die TTL aus unserem DNS-Artikel (die Angabe, wie viele Sekunden eine Telefonbuchnotiz wiederverwendet werden darf). Und die Geschichte, dass „auf die Ausbreitung eines Website-Umzugs warten“ in Wahrheit heißt, auf das Ablaufen der Notizen weltweit zu warten ── man könnte sagen, das war die DNS-Version genau des Vorfalls, den wir gleich in §4 lösen.
4. Die wahre Ursache von „ich habe aktualisiert, aber nichts hat sich geändert“ ── die neuen Dateien müssten doch da sein
4-1. Nichts ist kaputt, und doch bleibt die Seite alt
Jetzt haben wir alle Werkzeuge, um den Vorfall aus der Einleitung zu lösen.
In dem Moment, in dem du deine Website aktualisierst, liegen die neuen Materialien wirklich auf dem Server. Aber im lokalen Lager des Besuchers liegen alte Materialien, deren Haltbarkeitsfristen noch nicht abgelaufen sind. Wie in §3 gesehen, fragt der Browser bei allem innerhalb der Frist den Server nicht einmal ── das heißt, er bekommt nie die Gelegenheit zu bemerken, dass es neue Dateien gibt, und liefert weiter die alten aus.
Was während „ich habe aktualisiert, aber nichts hat sich geändert" passiert
Server lokales Lager Bildschirm
[neue Dateien] ×── [alte Dateien] ──> immer noch die alte Seite
△ innerhalb der Frist
sie existieren „darf noch verwendet nichts ist kaputt
werden", also fragt
niemand nach
Das ist das ganze Rätsel. Kein Bug, kein Defekt ── die alte Seite bleibt bestehen, gerade weil sich alle an die Regeln gehalten haben. Es ist die unvermeidliche Kehrseite der Entscheidung, die das Tempo erkauft: „innerhalb der Frist nicht nachfragen“.
4-2. Warum es bei dir behoben aussieht, bei allen anderen aber nicht
Das ist der Teil, der Website-Betreiber am meisten verwirrt. Auf deinem Bildschirm hat das Cache-Leeren es behoben. Und trotzdem schreiben die Kunden weiter: „bei mir ist immer noch die alte Version.“
Die Erklärung ist einfach: jeder Besucher hat ein eigenes Lager. Was du geleert hast, war dein Lager ── und nur deins; die Lager deiner Kunden behalten ihre alten Materialien, bis die Etiketten ablaufen. Dein eigenes Regal kannst du putzen ── an das der anderen kommst du nicht heran (was die Website selbst tun kann, steht am Ende von §5).
4-3. Es gibt mehr als ein Lager ── wo liegt die veraltete Kopie?
Nun zum Faden aus §2: Zwischen dir und den Materialien kann es mehrere Etagen von Lagern geben. Das Lager deines Browsers, das Gemeinschaftslager deines Firmennetzes, die Lager des Liefernetzes (CDN) und die Telefonbuchnotizen (DNS) ── in welcher Etage die veraltete Kopie liegt, entscheidet, wer es tatsächlich beheben kann. Das einzige, das du kontrollierst, ist dein eigenes.
Bei „ich habe meinen Cache geleert, aber es ist immer noch alt“ liegt die veraltete Kopie meist gar nicht in deinem Lager ── sondern in einem Zwischenlager (dem Gemeinschaftslager deines Büros oder dem des Liefernetzes) oder in den Telefonbuchnotizen (DNS). Das eigene Regal hundertmal zu putzen leert kein Lager auf dem Weg. Direkt nach einem Website-Umzug verdächtige die DNS-Notizen, die auf ihr Ablaufen warten (→ die „Ausbreitungs“-Geschichte in unserem DNS-Artikel).
5. Wie man es behebt und damit lebt ── nicht gleich alles löschen
5-1. Zuerst den leichtesten Handgriff probieren
Wenn eine Seite „nicht aktualisiert“, ist der Sprung direkt zum kompletten Cache-Leeren in Wahrheit der verschwenderische Zug. Die Faustregel sind drei Schritte, vom kleinsten Eingriff zum größten.
| Schritt | Handgriff | Was er tut | Wirkung |
|---|---|---|---|
| 1 | Erzwungenes Neuladen (Windows: Strg+F5 / Mac: Cmd+Shift+R) | Befiehlt das Neuholen unter Missachtung der Etiketten ── nur für die Materialien dieser Seite | Nur diese Seite. Praktisch keine Nebenwirkungen |
| 2 | Die Seite im privaten/Inkognito-Fenster öffnen | Testet mit leerem Lager ── sieht sie dort richtig aus, ist dein Lager als Schuldiger bestätigt | Nur Diagnose. Löscht nichts |
| 3 | Cache leeren | Leert das Lager für sämtliche Websites | Letztes Mittel. Alles lädt eine Weile langsamer |
Schritt 2 ist heimlich der wichtige. Ist die Seite selbst im privaten Fenster noch alt, liegt das Problem nicht in deinem Lager (verdächtige die Zwischenlager aus §4-3 ── oder die Möglichkeit, dass das Update nie wirklich live ging). Erst diagnostizieren ── dann leerst du nie umsonst sämtliche Regale.
5-2. Cache leeren loggt dich nicht aus
Der häufigste Grund zu zögern ist „loggt mich das nicht überall aus?“ ── und hier kannst du aufatmen. Wie in §1-3 gesehen, wohnen Cache (Warenkopien) und Cookies (deine Mitgliedskarten) in getrennten Schubladen. Nur den Cache zu leeren lässt deine Logins unangetastet.
Der Haken: Der Lösch-Dialog des Browsers zeigt meist gleich daneben ein Kästchen „Cookies auch“, und wer das ankreuzt, wird selbstverständlich ausgeloggt. Die Einträge des Dialogs entsprechen drei getrennten Schubladen ── Warenkopien (Cache), Mitgliedskarten (Cookies) und Notizen der besuchten Orte (Verlauf). Sobald du siehst, dass du auswählst, welche Schublade geleert wird, ist daran nichts Beängstigendes mehr (FAQ Q5).
Cache leeren hat genau einen Nachteil: Eine Weile ist jede Website wieder ein „Erstbesuch“ und lädt langsamer. Nichts geht kaputt.
5-3. Ein halber Schritt für Website-Bauer ── Updates ohne Warten ausliefern
Zum Schluss ein halber Schritt auf die Seite der Website-Bauer. Da man nicht herumgehen und die Lager der Besucher leeren kann, benutzen Websites, die Updates zuverlässig ausliefern müssen, diesen Trick: das Material selbst umbenennen und als anderen Artikel verschicken. Mach aus logo.png ein logo-v2.png, und kein Besucherlager hält eine Kopie unter diesem Namen ── das Holen ist garantiert. (Das nennt sich Cache Busting.) Eine Website, die nie unter „mein Update wird nicht angezeigt“ leidet, lässt sich also von vornherein so bauen.
Zusammenfassung ── die Essenz in 4 Zeilen
- Der Cache ist ein lokales Lager: Kopien einmal geholter Materialien werden wiederverwendet, der Botengang entfällt ── genau der Grund für „beim zweiten Mal geht’s schneller“
- Jedes Paket hat ein Haltbarkeitsetikett: Innerhalb der Frist wird der Server nicht einmal gefragt (am schnellsten). Danach die Bestandsanfrage ── ein „noch gut“ erledigt es in einer Zeile
- Der Vorfall ist eine veraltete Kopie innerhalb der Frist: Die neuen Materialien liegen schon auf dem Server, aber ein Lager innerhalb der Frist fragt nie nach ── nichts ist kaputt, und doch bleibt die Seite alt
- Zuerst mit dem leichtesten Handgriff beheben: erzwungenes Neuladen → privates Fenster zur Diagnose → leeren. Leeren loggt dich nicht aus (die Mitgliedskarten wohnen in einer anderen Schublade)
Und damit ist das Set komplett: die Kiste (HTTPS), die Mitgliedskarte (Cookies) und das Lager (Cache). Um vom Gesamtbild einer Anfrage aus noch einmal zu lesen, geht es hier zur Serienübersicht.
FAQ
Q1. Loggt mich das Cache-Leeren aus? Was ist der Unterschied zu Cookies?
A. Nur den Cache zu leeren loggt dich nicht aus. Der Cache sind „Kopien von Materialien (Bilder und Ähnliches), die du schon erhalten hast“; was dich eingeloggt hält, ist das Cookie (deine Mitgliedskarte) ── eine eigene Schublade (→ unser Cookie-Artikel). Ausgeloggt wirst du nur, wenn du im Lösch-Dialog auch die Cookies ankreuzt. Die vollen Kosten des Cache-Leerens sind „Seiten laden eine Weile langsamer“ ── nichts geht kaputt.
Q2. Ich habe den Cache geleert und es ist immer noch alt. Was jetzt?
A. Das ist das Zeichen, dass die veraltete Kopie woanders als in deinem Lager wohnt. Drei Kandidaten: ① ein Gemeinschaftslager deines Büronetzes oder Ähnliches (abwarten oder den Netzwerkadministrator fragen), ② das Lager der Website selbst oder ihres Liefernetzes (CDN) (nur der Website-Betreiber kann es leeren), ③ die Telefonbuchnotizen ── der DNS-Cache (typisch direkt nach einem Website-Umzug; → der Tipp in unserem DNS-Artikel). Zeigt selbst ein privates Fenster noch die alte Seite, ist es fast sicher einer davon. Die Seite über Mobilfunk und über WLAN zu vergleichen hilft, ① von ② zu trennen.
Q3. Sollte ich den Cache regelmäßig leeren?
A. Nein ── das ist unnötig. Das Lager verwaltet sich über die Haltbarkeitsetiketten selbst: Abgelaufene Ware wird von allein ersetzt, und wird der Platz knapp, fliegt das Älteste automatisch heraus. Es nach Zeitplan zu leeren schickt nur jede Website zurück auf „Erstbesuch“ und macht jedes Mal alles langsamer. Heb dir das Leeren für eine Situation auf: die Diagnose eines Anzeigeproblems.
Q4. Passiert auf dem Handy dasselbe?
A. Ja ── der Mechanismus ist identisch, und auch der Browser deines Handys hat ein Lager. Eines lohnt sich zu wissen: Der Browser, der sich innerhalb einer App öffnet (wenn du etwa in einer Social-App einen Link antippst), führt ein vom normalen Browser getrenntes Lager. Das „in Safari ist es repariert, aber aus der App noch alt“ passiert, weil das zwei verschiedene Lager sind.
Q5. Was unterscheidet im Lösch-Dialog „Cache“, „Cookies“ und „Verlauf“?
A. Drei getrennte Schubladen. Der Cache sind Materialkopien (Löschen macht nur eine Weile langsamer); Cookies sind Mitgliedskarten (Löschen loggt dich aus und setzt Website-Einstellungen zurück); der Verlauf sind die Notizen der besuchten Orte (Löschen entfernt vergangene Besuche etwa aus den Vorschlägen der Adressleiste). Wenn „eine Website falsch aussieht“, ist die relevante Schublade praktisch nur der Cache ── die sichere Gewohnheit ist also, nur die Schublade zu leeren, die zum Ziel passt.
Schreibe einen Kommentar