You don't need to rename the files. As of a few months ago, you can configure CloudFront to take query strings into account when caching, so you can simply link to the file as normal but append "?" to the filename. (I actually prefer using the last modified timestamp over a hash.) IMHO, this is better because it requires less magic on the origin server. And even ancient references to a file (a logo someone hotlinked, for example) will still render rather than 404, so long as the name hasn't changed. No need to keep tons of old revisions of files around.
Static Asset Compilation
21–30 of 41 posts
Re: Static Asset Compilation
#22You don't need to rename the files. As of a few months ago, you can configure CloudFront to take query strings into account when caching, so you can simply link to the file as normal but append "? " to the filename. (I actually prefer using the last modified timestamp over a hash.) IMHO, this is better because it requires less magic on the origin server. And even ancient references to a file (a logo someone hotlinked…
This isn't recommended since many browsers and proxies do not cache resources that are referenced using a query string, even if a cache-control or expires header is set appropriately. Google says Squid up to 3.0 will not do so:
https://developers.google.com/speed/docs/best-practices/cach...
Re: Static Asset Compilation
#23You don't need to rename the files. As of a few months ago, you can configure CloudFront to take query strings into account when caching, so you can simply link to the file as normal but append "? " to the filename. (I actually prefer using the last modified timestamp over a hash.) IMHO, this is better because it requires less magic on the origin server. And even ancient references to a file (a logo someone hotlinked…
This isn't recommended since many browsers and proxies do not cache resources that are referenced using a query string, even if a cache-control or expires header is set appropriately. Google says Squid up to 3.0 will not do so: https://developers.google.com/speed/docs/best-practices/cach...
Fair point and thanks for the link -- I've only seen this phrased as a warning against "some proxies" that I've never personally encountered. But I can live with it. If your proxy is broken in this way, you will have to fetch the asset from the CDN rather than benefit from your local proxy.
Re: Static Asset Compilation
#24Is putting hash digests in filenames really easier than sending Last-Modified headers in the response, parsing If-Modified-Since headers and returning 304 when applicable, and/or using ETags?
I would have thought that most web frameworks do all these things for you automatically by now.
Re: Static Asset Compilation
#25Is putting hash digests in filenames really easier than sending Last-Modified headers in the response, parsing If- Modified-Since headers and returning 304 when applicable, and/or using ETags? I would have thought that most web frameworks do all these things for you automatically by now.
Putting the hash in the filename allows the browser to not even make a request that would result in a 304 request. It also works behind badly behaved proxies and caches that don't properly respect cache headers.
Re: Static Asset Compilation
#26Fairly standard stuff. If you're going to have a title with "you're doing it wrong" you should have some unique insight to support your dramatised title.
I felt the same way. I was hoping the article would be about a radically different approach, but it's mostly just best practices.
Re: Static Asset Compilation
#27Why is it safe to include a subset of the SHA1 digest instead of the whole digest? What's the reasoning behind this? Would it make sense to use a shorter hash (e.g. CRC32) instead if your filenames have to be that short?
Re: Static Asset Compilation
#28Is ImageOptim still a good choice to go with? I really like the simplicity of the GUI.
Yes, ImageOptim is a wrapper around pngoptim and several other programs. It tries them all and goes with the one that provides you with the optimal compression for that specific file. It also supports JPEG and GIF files.
Re: Static Asset Compilation
#29Good tips. I've found that http://pngquant.org generates smaller pngs than optipng, but the former is lossy (reduced color palette). I can't tell the difference though.
You can have lossy compression that results in zero difference to the end image on a pixel by pixel basis.
E.g. if the PNG was 32 bit, and had a full color palette but was filled with a single 8 bit color. You could safely, and "loss-ily", convert the PNG to 8 bit and replace the entire color palette with the single entry for the color that is actually used.
That said, PNGQuant uses dithering so there will often be changes apparent if you perform a pixel by pixel comparison in code.
Just like you, I can't visually identify the difference between a PNGQuant image and the 'raw' PNG that was used to create it (at least not on any images that I've seen so far).
Re: Static Asset Compilation
#30Why is it safe to include a subset of the SHA1 digest instead of the whole digest? What's the reasoning behind this? Would it make sense to use a shorter hash (e.g. CRC32) instead if your filenames have to be that short?
Because SHA1 tends to have every byte of the digest change if so much as one byte of the message changes (if you can disprove that, you have a much more important result than "Oops our caching is slightly borked"). Accordingly, 10 hex digits is sufficient to guarantee that a change breaks the old cache (1 - 1 / 2^40) of the time. You wouldn't be at risk of birthday-paradoxing your caches even with billions of files in your site's history.