Cache Busting CSS and Image Changes

Skip to first unread message

Paul McLanahan

Mar 13, 2015, 3:36:15 PM3/13/15
Hi all,

We ran into an interesting bug[0] recently. We pushed out a change to an
image file that was referenced in CSS, but the new CSS file was never used
by the site. Some background information is required for full understanding:

Bedrock uses Django's staticfiles system[1] with all of the options for
hashed file names turned on. This means that in production a file named
"logo.jpg" might be named "logo.d5a4c7d4ef92.jpg". This enables us to set
the cache headers when we serve that file to basically infinite (10 years)
since that new part of the file name is the first 12 characters of the md5
hash of the contents of the file. So that file name will always refer to
the same contents, and if the file contents changes the file name will

That's all well and good, but since the same is true for CSS files it gets
tricky because CSS can refer to other files that will have hashed names
like images, fonts, and even other CSS. Django is fortunately smart enough
to process the CSS and replace references to these files with the new
hashed names. The problem is that the hash that is added to the name of CSS
files is based on the original contents of the CSS file, not the contents
after the images and fonts (etc.) that it refers to have been changed to
these hashed names. So an image may well have changed, and the new image
name is in the CSS, but since the CSS file name didn't change our infinite
cache will never see the new file contents because the name didn't change.

For various reasons this problem is very difficult to fix either in bedrock
or Django[2] itself. The easiest and best solution for now is to simply
make sure that if you need to alter an image or font or any other asset
that is referenced in CSS you also change its name. Since this may result
in more work than you might want due to having to hunt down all references
to said image, the other option is to make a modification to the CSS that
refers to the image. Any modification that will survive less compilation
and minification will result in the CSS being successfully updated (so no
comments unfortunately).

I will continue to try to find a good technical solution to this problem,
but in the interim this is all we've got unfortunately. Feel free contact
me with questions and/or comment in the bug[0] with proposed solutions.


Paul [pmac] McLanahan
Web Developer @ Mozilla
Reply all
Reply to author
0 new messages