Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Static Asset Compilation

autoref.com

Post reply on HN
Print view View original

31–40 of 41 posts

Re: Static Asset Compilation

#31

Post by ludwigvan »

eli wrote: post #21

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…

Another reason this is not recommended is that, if you rename the files, you can send them to the server and then reload your app.

If you don't, there might be a small amount of time before your app is reloaded where your app uses newer resources.

Re: Static Asset Compilation

#32

Post by latchkey »

autoref wrote: post #22
eli wrote: post #21

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…

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...

Squid 3.0 was released in 2007. It can be argued that this is an out of date recommendation. My experience using query strings has been fine.

Re: Static Asset Compilation

#35

Post by ciniglio »

tetravus wrote: post #29
moonboots wrote: post #4

Good 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 c…

To nitpick a little: If your source and final are the same, I don't think you can call it lossy, by definition.

Re: Static Asset Compilation

#36

Post by sirn »

amalag wrote: post #17
nestlequ1k wrote: post #6

Can someone with knowledge of both this and rails 3.1 explain the difference. Seems very similar.

Yes this article is written for people not using Rails & Sprockets. Pretty amazing the best practices that Rails asset pipeline enforces. It will also concatenate the JS & CSS files to reduce HTTP requests and does automatic .gz files on disk. When used with asset_sync gem it can also push these to S3 or your CDN to avoid your web server altogether.

In Python world we have webassets[1] that does something similar (to Jammit, anyway). It is a little bit more complicated to use than Sprockets but I'd argue that it is also a bit more flexible. (Thanks to filters chaining e.g. compile SASS, merge them, add vendor prefixes, optimize, compress then Gzip as a single chain.)

[1] http://elsdoerfer.name/docs/webassets/

Re: Static Asset Compilation

#37

Post by lotyrin »

jmtulloss wrote: post #25
brown9-2 wrote: post #24

Is 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.

It also allows for pages that were generated and cached before changes were made to still have resources, as well as other cases where you might have divergent sets of resources (split tests, rolling deployments, etc.)

Re: Static Asset Compilation

#38

Post by seriocomic »

autoref wrote: post #16
voidfiles wrote: post #14

With such a complicated system I think you are missing out on the most signifcant speed optimization technique; reducing http requests. For reference: http://developer.yahoo.com/blogs/ydn/posts/2007/04/rule_1_ma... It's laudable that you are paying attention to caching, but you don't compile all your files in to one file. It seems like you could pick up a lot ground here by at least concating all css into one file, a…

An excellent point, but you have to consider warm cache vs cold cache optimizations. For a cold cache, it's better to combine assets and reduce HTTP requests. We do that on our homepage. For a warm cache, it's better to split assets up so they are cached in finer chunks. If I added jQuery in to every page JS, there would be few HTTP requests but it would pull jQuery every time, making the payload much larger. There's…

Hmm, i've just left a comment suggesting combining assets. Based on what you've written here you've already answered one of my questions... I look forward to the warm/cold cache post.

Re: Static Asset Compilation

#40

Post by eli »

latchkey wrote: post #32
autoref wrote: post #22

Earlier quoted context omitted.

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...

Squid 3.0 was released in 2007. It can be argued that this is an out of date recommendation. My experience using query strings has been fine.

To be fair, I think it was still the current version up through 2011.

The more important point is that the failure mode is simply that the assets load from the CDN as if there were no squid proxy. This is not ideal, but it's not so bad either.

Post reply on HN