At FastRuby.io, we always recommend that clients set up an Application Performance Monitor. It’s not just useful for our Tune Report Service, but good practice for visibility into server health, user experience, and more.

One concern that we sometimes hear is that the application may have really sensitive information about the users and it may not be possible to send the information to a third-party provider, or that a managed service can be too expensive. In this article, we are going to explore some open source solutions that can be self-hosted.

Waiting over an hour for a test suite to finish is a productivity killer.

On a recent project, that was our reality.

Running the full local RSpec suite took almost 2 hours, making it difficult to get quick feedback and confidently iterate on changes. While there are many ways to optimize test performance including fixtures, request stubbing, faster tooling, and more, most of these options require significant effort to implement.

Instead, we explored a simpler approach: bringing parallel test execution to local development. The result was a much faster feedback loop (down to 5 minutes) and a significantly better developer experience.

It’s common for Rails applications to serve massive CSS files filled with unused Bootstrap, Tailwind, or custom utility classes as projects grow. This bloat isn’t just a developer annoyance—it has a real impact on your users. Every unused kilobyte adds milliseconds to page load time. In this post, we’ll explore what PurgeCSS opens a new window is and how your Rails project can benefit from it.

Last month, we finished a big upgrade for a client. The client had 2 main pain points for their app. The first one was that they were using Rails 2.3 LTS with Ruby 2.5. The next big issue was that the test suite took 40 minutes to run, blocking engineers from merging code into the main branch, and also slowing down the whole feedback loop for every code change.

After finishing the upgrade (we got the application to Rails 8.1.1 and Ruby 3.4.7), we focused our attention on improving the test’s speed and we reduced the time it took to run the whole test suite (over 10k tests) from 40 minutes to around 4!

When building a Rails application you will need to think about scaling as you get more and more users and data. One way in which your application may need to scale is at the database level. Rails supports using multiple databases, so you don’t have to store all your data in one place.

Imagine your customers are complaining that a few specific pages in your application take forever to load and you get to work to fix the issues. But there is a problem. You don’t know where to begin. If this journey of seeking truth, I mean answers, interests you, then read the rest of the article.

There has been a lot of conversations on social media about the “NoBuild opens a new window ” approach: using native browser features and plain CSS+JavaScript to avoid a precompilation step for our assets.

In many cases, it’s not easy to move to a “NoBuild” setup (and in some cases it’s not even possible depending on the application’s needs), and we can still aim to make the assets:precompile task as fast as possible if we can’t eliminate it.

In this article we’ll explore some areas for optimization using one of our applications.

In a previous article, we listed down common culprits that led to a sub-optimal performance in Rails applications. One of the culprits was missing or incorrect indexes.

Therefore we thought it would be very useful to have a handy reference to the different kinds of indexes, when you should use them and maybe even when not to use them.

Is your goal to rank first on Google? Have you already tried using the best keywords and strategies to rank higher but none of that has worked? It might be because your LCP, or Largest Contentful Paint, score is high and needs improvement.

When it comes to improving application performance and areas to focus on, I would recommend looking at the APM data, and then deciding which areas to prioritize.

However this article isn’t about where to focus efforts, but rather a compilation of techniques to improve your application’s performance, from tackling common problems like N+1 queries and database indexing to leveraging the jemalloc memory allocator. Let’s look at these performance-boosting strategies designed to fine-tune your application.

Here at FastRuby.io we always try to have our own applications in such a state that they can always be pointed to as models in terms of performance and accessibility.

One of the tools we use to achieve that is our CDN. After all, considering we have clients everywhere from the US to New Zealand, we want anyone perusing our websites to have good loading times for the pages and, especially, the assets.

However, no matter how thorough, one always misses a spot or two.

When we allow users to upload images, they usually upload files without any optimization for the web. It’s up to us to add some measure to prevent those images from slowing down our app. Luckily, the different gems commonly used to handle user uploads also give us solutions for this problem.

This is the second part of the Optimizing Images series. In the first article we talked about the basic concepts and techniques to optimize raster images, and today we’ll talk about techniques to optimize SVG opens a new window files.

Have you ever wondered what the values on the request queue graph in the APM tool meant or whether a certain value indicated good or poor performance?

The fundamentals of request queue, factors that contribute to longer request queues, and other topics will be covered in this post.

Imagine this scenario: you open a website on your phone, you see an image loading really really slowly, you wonder what’s going on and download the image to see more details… turns out the image is 3000x3000px with a size of 1.5Mb!

So, let’s talk about different ways to optimize images, common problems, and ways to find these issues early.

Upon integrating any performance monitoring tool for your application, you must be observing p95, p99 response times on the dashboards. If you are wondering what do these terms and their values mean, you have come to the right place.

I’m seeing a lot of disappointment about the speed of Ruby 3 out there. I think there are a lot of reasons for that, and I think they’re worth looking at.

So: why wasn’t Ruby 3 faster? Did it break its promise? (Spoiler: I don’t think so opens a new window , but I understand why some people do.)

If you’ve been following me awhile, you know that I was hired by AppFolio opens a new window years ago to measure Ruby 3’s performance, especially on Rails. This has been a long trip. And that very first project is finally over: Ruby 3 exists and I can check its final, released Rails performance.

If you have been following along, the numbers in this post won’t surprise you. But it’s important to do the final measurement. If you haven’t been following, this will bring you up to date.

Ruby 3x3 is coming in about a month. One of its new concurrency primitives is Ractors opens a new window , which used to be called “Guilds.” (The other new concurrency primitive is Autofibers opens a new window .)

Ruby has a Global VM Lock (GVL) opens a new window , also called the Global Interpreter Lock (GIL), that prevents running Ruby code in more than one thread at once. So Ruby threads are great for I/O like waiting on files or databases. And they’re great for cases where a C extension can keep calculating in a background thread while a foreground thread runs Ruby. But you can’t do calculations in Ruby in more than one thread at once within the same process.

At least not until Ruby 3 and not without Ractors.

Great! Now how fast is the current implementation of Ractors?

Do you ever look at the list of Amazon EC2 instance types? opens a new window . Those are sizes of virtual machine you can rent to run your code on. Well, okay, they’re groups of sizes, since each one of those headings has a bunch of different sizes of VM…

So what type of EC2 instances should you run your Rails app on?

The answer is simpler than it looks.

Do you love numbers? I love numbers. Do you hate numbers? Skip to the bottom, there’s a nice summary paragraph. Do you really really love numbers? There are raw data dumps opens a new window including all my intermediate results.

The new Ruby 3.0 preview opens a new window is out! Woo-hoo!

If you’ve heard of me, you know performance is kinda my thing opens a new window , especially Rails performance on large apps opens a new window . I do other stuff too, but I got paid to do that for years (thanks, AppFolio!), so I’ve written a lot about it.

How does the new preview’s performance stack up on Rails? And how reliable are these numbers?

Here we continue with the series of articles where we talk about how minor adjustments in the code can lead to major performance improvements.

In this article we’ll focus on the use of ActiveRecord::Batches#find_each opens a new window when it comes to iterations across a large number of records.

Some time ago we wrote a couple of Tips for Writing Fast Rails. It was about time we wrote part two so here it is!

Transcript:

Hello and welcome to the first OmbuCast by OmbuLabs. In this screencast we’ll be taking a look at the derailed_benchmarks opens a new window gem, and how you can use it to benchmark your Rails application and find, and hopefully fix bottlenecks in your code.

Rails opens a new window is a powerful framework. You can write a lot of features in a short period of time. In the process you can easily write code that performs poorly.

At OmbuLabs opens a new window we like to maintain Ruby on Rails applications opens a new window . In the process of maintaining them, adding features and fixing bugs, we like to improve the code and its performance (because we are good boy scouts opens a new window !)

Here are some tips based on our experience.

Prefer where instead of select

When you are performing a lot of calculations, you should load as little as possible into memory. Always prefer a SQL query vs. an object’s method call.