Don’t repeat yourself. Don’t repeat yourself. Yea I agree that article is a little cursory. Each one of those 10 bullet points could be an entire blog post itself. Also it doesn’t even mention avoiding n+1 queries, which I think is absolutely essential for ever new Rails dev to learn up-front.
I agree that some up-front stuff is important, like: CDNs, properly using the asset pipeline (compressing & Gzipping, moving to a CDN, etc), indexes on the fields you search against. However, in a company with a high-traffic website and investors who want a return on their money, it’s all about cost-benefit. So you need to think about the payoff for some of your efforts. For example, in my experience spriting your images actually costs a lot of developer time with very little payoff when it comes to browser performance. (I’m thinking in the scenario where you might have fewer than 10 images on any given page. If you have hundreds of 25x25 images spriting makes a lot more sense.) If you do the essentials up-front (listed above), the best strategy for optimization is to use a tool like New Relic to identify your bottlenecks and then optimize anything slow bit-by-bit. It’s tedious but you get a better result in the long run. -Jason > On Dec 11, 2014, at 10:20 AM, Josh Jordan <josh.jor...@gmail.com> wrote: > > While some of the advice here is good, it represents a very confused view of > performance optimization. For instance, #2 is just plain bad advice for > performance (but good for modularity) - partial rendering has a ton of > overhead in Rails. #3 doesn't speak to performance at all. DRY (#4) is not a > performance principle. I stopped when the author repeated #4. > > On Wednesday, December 10, 2014 3:51:02 PM UTC-5, Colin Law wrote: > On 10 December 2014 at 17:43, Dante Elrik <li...@ruby-forum.com > <javascript:>> wrote: > > Mehreen wrote in post #1163991: > >> Hello guys! > >> > >> I found a guideline which will help to boost up performance of your Ruby > >> on > >> Rails application > >> > > <http://www.nascenia.com/10-tips-to-boost-up-performance-of-your-ruby-on-rails-application/ > > > > <http://www.nascenia.com/10-tips-to-boost-up-performance-of-your-ruby-on-rails-application/>>. > > > >> You should check this out. > > > > I'd like to! Link is dead. > > It works for me. Some of the suggestions are way out of date though, > being written in 2011! > > Colin > > -- > You received this message because you are subscribed to the Google Groups > "Ruby on Rails: Talk" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to rubyonrails-talk+unsubscr...@googlegroups.com > <mailto:rubyonrails-talk+unsubscr...@googlegroups.com>. > To post to this group, send email to rubyonrails-talk@googlegroups.com > <mailto:rubyonrails-talk@googlegroups.com>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/rubyonrails-talk/5261a95e-ff88-42f2-a020-f443932d1a9f%40googlegroups.com > > <https://groups.google.com/d/msgid/rubyonrails-talk/5261a95e-ff88-42f2-a020-f443932d1a9f%40googlegroups.com?utm_medium=email&utm_source=footer>. > For more options, visit https://groups.google.com/d/optout > <https://groups.google.com/d/optout>. ---- Jason Fleetwood-Boldt t...@datatravels.com http://www.jasonfleetwoodboldt.com/writing All material © Jason Fleetwood-Boldt 2014. Public conversations may be turned into blog posts (original poster information will be made anonymous). Email ja...@datatravels.com with questions/concerns about this. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-talk+unsubscr...@googlegroups.com. To post to this group, send email to rubyonrails-talk@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/61584F9A-64C8-406E-9A17-8D9BB6D19B66%40datatravels.com. For more options, visit https://groups.google.com/d/optout.
