Der Browser-Cache kann schnell zum Feind für Webentwickler und Webseitenbetreiber werden. Denn dieser speichert, ohne viel Kontrolle seitens des Betreibers, den aktuellen Stand einer Webseite im Browser des Besuchers zwischen. Unter Umständen kann es so passieren, dass nach einer kleinen oder großen Design-Anpassung an der eigenen Webseite der Besucher veraltete oder gar fehlerhafte Inhalte sieht. Wie man das Problem umgeht zeigen wir euch in diesem Artikel.

Was ist Cache-Busting?

Beim Cache-Busting handelt es sich um eine Methode, den Browser-Cache etwas auszutricksen. Genau genommen ist es nicht möglich, den Cache eines Benutzers aus der Ferne einfach zu leeren. Das kann der Benutzer nur selber manuell im Browser machen. Allerdings können wir dem Browser sagen, dass er jegliche Assets (also JavaScripts, Stylesheets, Bilder etc.) neu laden soll. Hier gibt es letztlich zwei Möglichkeiten:

  1. Die Assets werden umbenannt
  2. Wir hängen den Assets einen Parameter an

Bei Weg 1 könnte das z.B. so aussehen: Wir haben eine Datei style_1.0.css. Wenn wir nun etwas am CSS-Layout ändern, so nennen wir einfach die Datei um in style_2.0.css. Allerdings müssen wir nun auch alle Verweise auf die Style-Datei anpassen. Sobald aber nun ein Benutzer auf die Seite kommt, nützt ihm seine alte style_1.0.css aus dem eigenen Cache nichts mehr und der Browser lädt automatisch die aktuelle style_2.0.css herunter.

Weg 2 funktioniert nach einem ähnlichen Prinzip, allerdings muss die entsprechende Datei nicht erst mühsam umbenannt werden. Es reicht auch, wenn wir einen Parameter an die Datei anhängen. Das sieht z.B. so aus, vorher wurde die style.css als style.css?v=1.0 ausgegeben, nach einem Update geben wir sie aus als style.css?v=2.0. Auch hier behandelt der Browser die neue Version als komplett neue Stylesheet-Datei und lädt sie erneut herunter und ignoriert die alte Version im Cache. Der Vorteil ist hier außerdem, dass die Datei nicht erst umbenannt werden muss, allerdings muss der Verweis auf die Datei mit dem Parameter ausgestattet werden.

Wie setzt man dies um?

Es gibt verschiedene Varianten dieses Cache-Busting umzusetzen. Man kann dies entweder manuell tun oder man nutzt Tools, die das für einen automatisch übernehmen. Ein paar mögliche Varianten möchten wir euch hier aufzeigen.

Manuelles Cache-Busting

Diesen Vorgang haben wir oben bereits im Ansatz beschrieben. Statt einfach nur eine Datei, z.B. eine CSS-Datei, so wie hier einzubinden:

<link rel="stylesheet" href="style.css">

… kann man auch direkt einen Versionsparameter anhängen:

<link rel="stylesheet" href="style.css?v=1.0">

Das funktioniert natürlich auch analog mit Script-Files oder Bildern:

<script src="script.js?v=1.0">
<img src="image.jpg?v=1.0">

Nutzung von Variablen

Wer es nun zu anstrengend findet, jedes Mal bei einer Änderung den obigen URL-Parameter ändern zu müssen, der kann das ganze auch etwas dynamischer machen. Spätestens wenn man relativ viele Stylesheets, Script-Files und ggf. auch Bilder eingebunden hat, kann das sonst ein sehr langwieriger Prozess werden. Hier könnte man aber – je nach Programmiersprache und System – eine entsprechende Variable nutzen. Unter PHP könnte das z.B. so aussehen:

<?php
$assetVersion = '1.0';
?>
...
<link rel="stylesheet" href="style.css?v=<?php echo $assetVersion; ?>">
<link rel="stylesheet" href="mobile.css?v=<?php echo $assetVersion; ?>">
<link rel="stylesheet" href="more.css?v=<?php echo $assetVersion; ?>">

Bei dieser Variante braucht man also nur noch die obige Variable einmal anpassen und der URL-Parameter wird für alle Assets geändert.

Bei WordPress: Über die Theme-Version

Wer WordPress mit einem Theme verwendet, könnte auch die Version des Themes nutzen. Das Theme hat eine Version in der eigenen style.css definiert. Wenn man dann etwas anpasst, könnte man einfach die Theme-Version erhöhen und dann nutzen alle eingebundenen Stylesheets und Script-Files diese Version als Parameter. Dafür muss man allerdings folgende Funktion in der functions.php einbauen:

function my_scripts() {
    $themeData = wp_get_theme();
    $themeVersion = $themeData->get('Version');
    $wordPressVersion = get_bloginfo( 'version' );
    wp_enqueue_style( 'style', get_stylesheet_uri(), array(), $wordPressVersion . '_' . $themeVersion );
    // ...
}
// ...
add_action( 'wp_enqueue_scripts', 'my_scripts' );

In diesem Fall nutzen wir auch gleich die WordPress-Version mit, damit z.B. auch bei einem WordPress-Update das Cache-Busting greift. Dieses Beispiel kümmert sich um die Stylesheets. Das Gleiche lässt sich aber auch für Script-Files mit dem Hook wp_enqueue_script umsetzen.

Bei WordPress: Nutzung von Plugins

Wer WordPress nutzt, kann zudem auch ein Plugin verwenden, um das Cache Busting automatisch zu nutzen. Hier kommt z.B. auch das Plugin W3 Total Cache in Frage.

In den Einstellungen von W3 Total Cache ist es möglich, im Abschnitt „Browser Cache“ die Option „Prevent caching of objects after settings change“ zu aktivieren. Damit hängt W3 Total Cache automatisch einen neuen generierten String als Parameter an die Assets an. Das Ganze lässt sich auch wunderbar verbinden mit dem integrierten Minifyer:

W3TC Cache Busting Der Cache lässt sich nun entsprechend „busten“ indem man einfach den gesamten W3-Total-Cache-Cache leert. Dann wird jedes Mal ein neuer String erzeugt und an die Assets angehangen. Das geschieht übrigens auch bei Bildern. Hier muss man nur darauf achten, dass man dieses Feature sowohl für CSS & JS als auch Media-Files aktiviert. Weitere hilfreiche Einstellungen für W3 Total Cache, auch was den Browser-Cache angeht, findet ihr übrigens auch bei kinsta.

Natürlich gibt es noch eine ganze Reihe anderer Plugins, die dies unterstützen: „Cache Busting“ bei WordPress.org

Bei Frameworks: Nutzung von Pre-Compilern

Für Nutzer von Frameworks können sog. Pre-Compiler interessant werden. Solche Pre-Compiler kommen z.B. dann zum Einsatz, wenn man eine Sprache wie Typescript, LESS oder SASS verwendet. Diese Pre-Compiler wandeln diese Formate dann um in JavaScript oder CSS. Diese Pre-Compiler kann man dann aber auch mit Cache-Busting kombinieren. So können z.B. die erzeugten JavaScript- und/oder CSS-Files mit jedem Compile-Vorgang umbenannt werden. Natürlich kümmern sich diese auch gleich um die Einbindung dieser Assets mit neuem Namen. Hier können u.a. Tools wie Webpack oder Framework-interne Asset-Manager wie bei Symfony (Backend) oder Angular (Frontend) behilflich sein.


Wir hoffen, dies ist ein guter Einstieg in das Thema Cache-Busting für euch. Habt ihr weitere interessante Ansätze dazu? Oder habt ihr einfach nur Fragen? Dann nehmt doch Kontakt mit uns auf oder schreibt einen Kommentar.