7 ms·

Make your website super fast with Asset Pipeline, Sprites & Cloudfront

71 points by moritzplassnig 14y ago

davedx 14y ago
This is a nice useful blog post, but it does lead me to question to state of Rails -- is it me, or is it incredibly complicated these days to build a production ready Rails site? I still love the simplicity of developing with Rails, but all these things you need to remember to deploy give me cold sweats.
- cmelbye 14y ago
  No, this is not necessary to build a production-ready Rails site. If you want to send your files through a CDN, then you'll need to perform this configuration (which is still easier than writing the logic yourself.)
- danneu 14y ago
  Deploying is easy. Using a CDN, sprites, and other details in this blog post are iterative optimizations, not deployment prerequisites. They certainly aren't more trivial to implement if you aren't using Rails.
- inkel 14y ago
  I agree with you. I'm not doing Rails anymore, I'm working with Cuba + gs + dep + Ohm + mote, and I find it easier and less bloated than what Rails has become. Rails 3.x, though with a couple of good ideas, it's not as easy as it used to be to start developing an app, less say deploying it. Too many helpers and technologies to learn, IMO completely unnecessary.
  - SkyMarshal 14y ago
    >Cuba + gs + dep + Ohm + mote I thought I'd heard of everything, but I haven't heard of a single one of these. Any chance you can write up a blog post about building websites with them and post it?
- matlock 14y ago
  Rails provides great performance and when coupled with Apache/Nginx delivering Assets is not that big of a deal. But as Heroku doesn't provide any proxying it is upon every developer to implement something like this. Though doing it takes probably less than an hour, so compared to earlier times it is incredibly easy. And someone else already mentioned that this is not something you would do from day one. The first deployment (especially with Heroku) is incredibly easy, but there is a lot to build upon once you have that application up and running.
- mrinterweb 14y ago
  None of these features are necessary to build a production-ready Rails site. Before Rails 3, people built and deployed production-ready Rails sites. Production asset optimization was left up to the developers to figure out. Rails 3 makes asset optimization very easy by comparison to what needed to be done before. Rails has not become more complicated to develop for. Rails 3 just has more features than it used to have. If you want to use more features, the features are there for you. If not, you can ignore them.
- tferris 14y ago
  > is it incredibly complicated? Yes it is and frustrating is that you have to read spec over spec to follow all the conventions. You can be very fast with Rails and all its gems but to get there takes time and it's no fun anymore.
hydrorush 14y ago
THIS IS THE MOST USELESS SERVICE I HAVE EVER SEEN. it is the equivilent of the dicks gem for serivices (http://bit.ly/bfQji6 http://bit.ly/bfQji6) but wait no... dicks is funny and this is just sad. like a clown dying. with cancer. of the ass.
- mrinterweb 14y ago
  Comments like these make me wish I had the ability to downvote.
  - deleted 14y ago
    [deleted]
ericcholis 14y ago
It should be noted that while this is written with Rails in mind, the techniques can be applied to any web language.
- matlock 14y ago
  You are absolutely right. Will add this to the Header
sirn 14y ago
May slightly OT: The best naming scheme for page name I've ever seen is to use body#controller.action then put CSS relevant to a single controller in Rails-generated controller_name.css.scss. It helps preventing crashing while keeping file count to minimum. Extra bonus, it also provide ability to reuse certain CSS within same controller. For example: # articles.css.scss body#articles { /* We display title in LARGE RED TEXT in articles controller. */ h2 { font-size: 24px; color: red; } &.index { /* Oh noes we don't really want LARGE RED TEXT here. */ h2 { font-size: 16px; } } } All my projects now started this way. It's very maintainable.
- ruckusing 14y ago
  I love this method and have almost the exact setup. I do the same for JS too. In the footer of every page: $(document).ready(function() { if (V.Views.orders_index) { V.Views.orders_index(); } } Where "V.Views.orders_index" is basically "${controller}_${index}". Thus you just need to actually define that function in an included JS and voila, thats your calling hook and your JS is invoked.
dawie 14y ago
Won't Cloudflare help by caching static stuff and providing the CDN?
- matlock 14y ago
  I haven't looked into Cloudflare a lot, but it looks like it would solve that as well.

This is a nice useful blog post, but it does lead me to question to state of Rails -- is it me, or is it incredibly complicated these days to build a production ready Rails site? I still love the simplicity of developing with Rails, but all these things you need to remember to deploy give me cold sweats.

cmelbye 14y ago
No, this is not necessary to build a production-ready Rails site. If you want to send your files through a CDN, then you'll need to perform this configuration (which is still easier than writing the logic yourself.)
danneu 14y ago
Deploying is easy. Using a CDN, sprites, and other details in this blog post are iterative optimizations, not deployment prerequisites. They certainly aren't more trivial to implement if you aren't using Rails.
inkel 14y ago
I agree with you. I'm not doing Rails anymore, I'm working with Cuba + gs + dep + Ohm + mote, and I find it easier and less bloated than what Rails has become. Rails 3.x, though with a couple of good ideas, it's not as easy as it used to be to start developing an app, less say deploying it. Too many helpers and technologies to learn, IMO completely unnecessary.
- SkyMarshal 14y ago
  >Cuba + gs + dep + Ohm + mote I thought I'd heard of everything, but I haven't heard of a single one of these. Any chance you can write up a blog post about building websites with them and post it?
matlock 14y ago
Rails provides great performance and when coupled with Apache/Nginx delivering Assets is not that big of a deal. But as Heroku doesn't provide any proxying it is upon every developer to implement something like this. Though doing it takes probably less than an hour, so compared to earlier times it is incredibly easy. And someone else already mentioned that this is not something you would do from day one. The first deployment (especially with Heroku) is incredibly easy, but there is a lot to build upon once you have that application up and running.
mrinterweb 14y ago
None of these features are necessary to build a production-ready Rails site. Before Rails 3, people built and deployed production-ready Rails sites. Production asset optimization was left up to the developers to figure out. Rails 3 makes asset optimization very easy by comparison to what needed to be done before. Rails has not become more complicated to develop for. Rails 3 just has more features than it used to have. If you want to use more features, the features are there for you. If not, you can ignore them.
tferris 14y ago
> is it incredibly complicated? Yes it is and frustrating is that you have to read spec over spec to follow all the conventions. You can be very fast with Rails and all its gems but to get there takes time and it's no fun anymore.

hydrorush 14y ago

THIS IS THE MOST USELESS SERVICE I HAVE EVER SEEN. it is the equivilent of the dicks gem for serivices (http://bit.ly/bfQji6 http://bit.ly/bfQji6) but wait no... dicks is funny and this is just sad. like a clown dying. with cancer. of the ass.

mrinterweb 14y ago
Comments like these make me wish I had the ability to downvote.
- deleted 14y ago
  [deleted]

ericcholis 14y ago

It should be noted that while this is written with Rails in mind, the techniques can be applied to any web language.

matlock 14y ago
You are absolutely right. Will add this to the Header

sirn 14y ago

May slightly OT: The best naming scheme for page name I've ever seen is to use body#controller.action then put CSS relevant to a single controller in Rails-generated controller_name.css.scss. It helps preventing crashing while keeping file count to minimum. Extra bonus, it also provide ability to reuse certain CSS within same controller. For example: # articles.css.scss body#articles { /* We display title in LARGE RED TEXT in articles controller. */ h2 { font-size: 24px; color: red; } &.index { /* Oh noes we don't really want LARGE RED TEXT here. */ h2 { font-size: 16px; } } } All my projects now started this way. It's very maintainable.

ruckusing 14y ago
I love this method and have almost the exact setup. I do the same for JS too. In the footer of every page: $(document).ready(function() { if (V.Views.orders_index) { V.Views.orders_index(); } } Where "V.Views.orders_index" is basically "${controller}_${index}". Thus you just need to actually define that function in an included JS and voila, thats your calling hook and your JS is invoked.

dawie 14y ago

Won't Cloudflare help by caching static stuff and providing the CDN?

matlock 14y ago
I haven't looked into Cloudflare a lot, but it looks like it would solve that as well.