3.x - Cache busting

[adriansuter]

For cache busting see https://css-tricks.com/strategies-for-cache-busting-css/

Personally I made a cache busting twig function that transforms the given path automatically. So if there is a file /public/image.jpg and in the template I write

<img src="{{ cache_busting('image.jpg') }}">

then that would be transformed into

<img src="/base-path/image.1568637951.jpg">

in case the base path is base-path.

Of course the web server needs to be configured such that it redirects those cache busting urls.

What do you think, should we implement that twig function or is this already beyond the slim philosophy?

[ghost]

What would be used as version number ? The file timestamp ?
I don't like the idea to get files info for each request. It would be acceptable for 2-3 files but imagine a website with 20 files needing cache bust.

[adriansuter]

Yes, my personal solution uses the filemtime.

But of course this could be optionally set to any number. What do you suggest to use? Should there be a build-process that can be triggered manually by the developer and that generates either a big lookup table or that modifies the twig templates directly?

[ghost]

I usually use gulp or webpack to compile the assets and generate a json file containing all the hashes.
On some apps i've seen assets compiled and cached on the fly by php. The request for a file is captured by the php routing.

[adriansuter]

So you suggest to use a big lookup table, which means a json file containing a map of file paths to file hashes?

If you have thousands of asset files, but every page uses 15-20 assets only, is this really better than the filemtime method?

Both methods have their pros and cons.

How about writing a twig lexer/parser/compiler that transforms file paths to hashed paths upon template compilation?

[ghost]

You're right. But i think is better a single json than multiple filesystem interactions.
Using the twig cache would be better.

[l0gicgate]

Why not cache bust via query string instead?

<img src="/base-path/image.jpg?cb=<timestamp>">

[adriansuter]

@l0gicgate Because some browsers didn't see a different query string as a different file and there are cache proxies that do not cache files with query strings at all.

I think that the whole cache busting thing should be implemented in another repository (as extension to this one). This wouldn't be base functionality anymore. What do you think?

[adriansuter]

Actually, this is not even Slim specific. It is Twig specific.