Kundenmissverständnisse ausräumen leicht gemacht!

„Haben Sie es schon mal mit F5 probiert?“ ist das “Have you tried turning in off and on again?” für Webdesigner – ich weiß nicht mehr, wie oft ich diesen Satz in den letzten 15 Jahren gesagt habe. Jetzt ist damit Schluss, und ich hätte viel früher darauf kommen sollen, wie man das sauber löst. Wir wollen

a) auf Live-Websites den Browsercache für CSS- und JavaScript-Dateien nutzen
b) die Browser dazu zwingen, eine geänderte CSS- oder JS-Datei nicht aus dem Cache zu nehmen, sondern neu zu laden, um diese dann aber wiederum solange zu cachen, bis wir eine erneut geänderte Version anbieten.

Die simple Methode mit dem URL-Parameter (screen.css?v=42) ist offenbar nicht wirklich zuverlässig, sondern führt bisweilen dazu, dass gar nicht mehr gecacht wird. Von daher unser Vorschlag: Wir verwenden eine echte Dateinamenänderung, die mit einem Timestamp versehen ist, und nutzen die Power von .htaccess, um das für die Browser transparent zu gestalten. So geht’s:

Dateinamen dynamisch anreichern. Zum Beispiel mit PHP:

<link rel="stylesheet" href="/css/screen.<?= date('YmdHi', filemtime('/var/htdocs/screen.css')) ?>.css">

daraus resultiert ein Dateiname mit einem eingebauten Datum/Zeitangaben vom last modified der physischen CSS-Datei:

<link rel="stylesheet" href="/css/screen.201609301654.css">

Nun noch ein paar Eintragungen ganz oben in der .htaccess-Datei, und wir sind fertig:

RewriteCond %{REQUEST_FILENAME} (css/screen\.(.*)\.css)
RewriteRule ^(.*)$ /css/screen.css [L]

Das gleiche natürlich mit der print.css und der all.js, und alle können beruhigter ihre Websites deployen und sicher sein, dass sich Änderungen direkt im Kundenbrowser auswirken.

4 Kommentare

Steffen Weber

Kleiner Tipp: Lass’ den “date”-Aufruf weg, dann ist der Zeitstempel sogar sekundengenau. :)

Eine Alternative zum Zeitstempel wäre ein Hash des Dateiinhalts, sodass sich bei erneutem Deployment die URL der Asset-Datei auch wirklich nur dann ändert, wenn sich deren Inhalt geändert hat. Zum Beispiel:

$hash = substr(hash_file(‘sha256’, $asset_file), 0, 8);

Da der Hash aber deutlich CPU- und Disk-intensiver zu berechnen ist als das einfache Auslesen der Modification Time, erscheint dann ein Caching des Hashs sinnvoll (z.B. in APCu). Insofern hat die Einfachheit der mtime-Variante defintiv ihren Charme.

fwolf

Und nicht vergessen: Die PHP-Kurzform funktioniert nicht überall ;)
Hatte das letztens erst – alle rätselten, warum da ein Fehler bzw. “White Screen of Death” auftrat .. und dann lags tatsächlich an “<?” statt normalen “<?php” ;)

cu, w0lf.

Yannick Albert

Die PHP-Kurzform funktioniert nicht überall […]
und dann lags tatsächlich an “<?” statt normalen “<?php”
fwolf

<?php is nich gleich <?= is nich gleich <%= is nich gleich <%
…und schon gar nicht gleich <script language=“php”>.

Seit PHP54 ist <?= übrigens immer verfügbar (auch ohne short_open_tag).

Für PHP 7 gibt es dazu auch einen passenden Vorschlag zur Entfernung der ASP- und script-tags. Dieser RFC ist jetzt seit fast genau 2 Jahren schon beschlossene Sache wiki.php.net/rfc/remove_alternative_php_tags.

» Cheers, Yannick ♥

Roman Klein

Die simple Methode mit dem URL-Parameter (screen.css?v=42) ist offenbar nicht wirklich zuverlässig, sondern führt bisweilen dazu, dass gar nicht mehr gecacht wird.

Es würde mich interessieren welche Informationen bzw. Erkenntnisse sich hinter dem “offenbar” verbergen – hast du dazu aktuelle Quellen parat oder beruht diese Einschätzung auf eigenen Erfahrungen?

Ich hatte mich vor kurzem auch mal wieder mit dem Thema beschäfigt und hatte den Eindruck, daß sich so ziemlich jedes pauschale Statement gegen den Einsatz von URL-query-parametern im Caching-Kontext in irgendeiner Form auf diesen einen Artikel von Steve Souders aus dem Jahre 2008 bezieht. Die dort angesprochene Problematik im Zusammenspiel mit Proxy-Servern scheint allerdings heutzutage kein konkretes Problem mehr darzustellen – nicht zuletzt aus Sicht des Autors.

Ich habe deshalb entschieden weiterhin auf die (so simple wie einleuchtende) Param-Variante zu vertrauen, wäre aber dennoch dankbar für konkrete & überzeugende Hinweise, die mich davon abbringen könnten ;)

Kommentar verfassen