Optimizing A New (Rails) Heroku App

Having recently sent my very first Heroku app live (queue shameless plug), www.raoulkoopman.com, the lack of speed was the first thing I took issue with. Here are a few things I’ve learned along the way so that you can too give your new Heroku app a bit more oomph!

Some things like utilizing the usefulness of caching, monitoring N+1 queries, and sorting out RAM usage can be applied regardless of what service you choose to host you application. Here are some of the things I did to help my website resemble Mo Farah (famous marathoner) more, and not so much a Netflix marathoner.

To kick things off, my site is a personal blog site. It has a few features that I hadn’t played with prior to building it (contact form that connects a form to my email, a rich text editor for blog posts, and making use of Rails sessions for an admin login) but for the most part it’s a pretty straight forward web application.

A big factor to consider when trying to speed up any application is how much memory it’s using. Nate Berkopec does a wonderful job explaining that (https://www.speedshop.co/2015/07/22/secrets-to-speedy-ruby-apps-on-heroku.html), so I don’t want to get into it.

“Most Unix systems use something called swap space when they run out of RAM. This is essentially the operating system using the file system as RAM. However, the filesystem is a lot slower than RAM — 10–50x slower, in fact.” -Nate Berkopec

When setting up a new application on Heroku I pretty much followed their guide verbatim. As recommended, I’m using Puma as a worker-based multi-process web server to run the application. Being that it’s a light application with low traffic it’s absolutely fine.

The first place I looked was the Gemfile. Just because you may not have a lot of code in your application itself that doesn’t mean that it’s not using more. For example, has_secure_password, mail_form, and trix are three of my application using code other libraries for specific features. The Gemfile is in some cases a big culprit of excess memory usage. Every time a process is carried out, each gem gets called.

A new Rails app is great and wonderful in that it gives you so many tools right out of the box. But know to take out any unused gem, especially once it comes to production.

Next I worked on my CSS. I went through a bootcamp where we were trained as full-stack developers. However, various aspects of front-end development were omitted in favor of back-end engineering. I regret nothing but my HTML/CSS was a mess. Instead of styling HTML elements with an id="foo" or a class="doo"; I had a bunch of CSS selectors that served a single purpose. When building the application I didn’t know that convention was to have a class or id and styled via a single corresponding selector.

After getting the style sheets and selectors sorted out I used a CSS compression tool (http://www.cssdrive.com/index.php/main/csscompressor/) to compress the content in the CSS files to they’d load faster.