Is ImageOptim still a good choice to go with? I really like the simplicity of the GUI.
Static Asset Compilation
11–20 of 41 posts
Re: Static Asset Compilation
#12We use the git commit hash of the checkin that is pushed to production as part of the folder structure for our assets. Has worked really well for us.
It does mean we use more space on s3 though, but it guarantees we won't miss re-seeding some of the files.
Re: Static Asset Compilation
#13Fairly 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.
Re: Static Asset Compilation
#14With 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, and js in to one file.
Also you could load jquery from the Google AJAX API endpoint. That way the users has a higher chance of having already loaded jQuery.
Also using the same CSS/JS products across multiple pages would help.
Re: Static Asset Compilation
#15If you're using .net, RequestReduce [1] is an excellent tool for managing your static assets. [1] - https://github.com/mwrock/RequestReduce
Also check out Cassette http://getcassette.net/
Re: Static Asset Compilation
#16With 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 a balance. I'll write another post about warm vs cold cache optimizations soon.
"using the same CSS/JS products across multiple pages would help."
Definitely. Using jQuery on half your site and YUI on the other half is pretty bad from all angles.
"you could load jquery from the Google AJAX API endpoint."
Yeah. Two reasons we don't: 1. I'm in security, and trust no one. 2. HTTPS connection reuse vs negotiation with another host. I have yet another post in the pipe about SSL optimizations.
Re: Static Asset Compilation
#17Can 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.
Re: Static Asset Compilation
#18With 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…
I usually have three "chunks" of CSS/JS per page, one for CSS/JS that's shared across all pages of the whole site, one that's common among a "group" of pages and one that's unique to just that page.
Of course, not all pages get all three chunks, but I find it's a reasonable tradeoff between reducing the number of requests and not just including everything on every page.
Re: Static Asset Compilation
#19We use the git commit hash of the checkin that is pushed to production as part of the folder structure for our assets. Has worked really well for us. It does mean we use more space on s3 though, but it guarantees we won't miss re-seeding some of the files.
The bad part is no file is cached between pushes, right?
Re: Static Asset Compilation
#20You could probably shave a few bytes off your URL's, while achieving the same collision resistance (or alternatively increase the collision resistance in the same number of bytes) if you base64 encoded the hash.