Ruby on Rails - Page Speed Optimisation (Part I)
Introduction
To measure the growth rate of any online business, we always consider conversion rate as the main key.
Conversion Rate is a rate at which visitors to your online stores gets converted into a customer (who made an order).
One factor that plays an important role in a higher conversion rate is - Page Speed Optimization. As per research, Google stated that 53% of people leave a mobile page if it takes longer than 3 seconds.
I believe it's difficult to achieve 3 3-second page load time for mobile, but at the same time, I think it's not impossible. So in this blog, I will cover all the major problems that I faced for application performance when working on ruby on rails app.
Check Your Page Speed Score
The first thing is we need to check the current page speed score of our application using any of the below tools -
Page speed performance monitoring tool -
- PageSpeed
- WebPage Speed
- GMetrix
- Pingdom
- Lighthouse - Google Developer Tool
I have used all of them and analyzed areas of improvement.
Problems We Faced
There are several problems we may face when working on page speed optimization for any application. Below, I listed some of them -
Usage of Stylesheet & JavaScript as one bundle
In the Rails application, following the legacy with the Rails asset pipeline, we ended up creating one bundle file that includes all CSS or js. This application bundles js and CSS are render blocking.
Render Blocking means the resources that are blocking you page from the initial rendering of the page. JavaScript and CSS both are render blocking resources
When you search for the solution to this, it will say to - load your JavaScript and Style Sheets resources asynchronously. This solution will break your application code.
A possible solution for this problem is to load - Page-specific JS/CSS resources.
External Third-Party Scripts
Another problem we generally face in Rails applications is the usage of external scripts and libraries. When it comes to extending the application code for features, we unintentionally ended up usage of lots of scripts and style sheets. From our page speed score and areas of improvement, we can easily know what are those external libraries.
The disadvantage of this is, that it breaks several other Google recommendations related to page speed. Here I listed some of them -
- Leads To Leverage Browser Caching
- Increase Internal Redirects
- Leads To Increase in Resources Size (No Compression)
This is a situation, where we cannot do anything to fix those. If we remove the libraries, it will break the application code.
A possible solution would be this - Minimise the usage of external resources
No Static Asset Hosting
In the rails application, by default assets are served from the server itself, from where all application codes are also served. So, it keeps the server busy all the time for serving assets and resources.
This might slow down the server response time also which is one of the factors recommended by Google for page speed slowdown.
Server response time is the amount of time it takes for a web server to respond to a request from a browser.
Possible Solution - Use asset hosting service - S3, Cloudnary, etc.
Heavy Sized Images
A general rails application served many resources including images and scripts, out of which images are the most commonly used asset that impacts the page speed.
The more the size of the images, the more bandwidth it requires which leads to slowing down the page speed. We want to keep the image size smaller without losing image quality.
We want to choose the correct image type according to the need.
Possible solution - Image compression, New generation Image Format, Image type.
Looking to solve these problems?
The problems list can be long, but we consider the most common one that occurs in every rails application at some point in time.
The solutions for all these are explained in detail in my next blog with results.
Ruby on Rails - Page Speed Optimisation (Part II)
