Recently I was working on performance improvement on my blog post. It all started when I was writing the article Mobile-first Google Indexing - Are you ready with your website for this change. During the Lighthouse scan one thing which was glaring to me was the size of the JavaScript file. And, that’s when I realized that I have made such a silly mistake. In this article, I am going to talk you through some of the important changes that I made to my blog. And, how they had a significant impact on the performance of my blog.
We all know performance is a very important thing when it comes to your website’s acceptance to the end user. Tons of research has confirmed that you get only a few seconds of the user before they move away from your website. I recently did a Page Speed audit of my website, and I was alarmed by the low score that I got for the mobile version. The desktop was around 91 which is great. But, the score on mobile was only 31. Can you imagine? The same URL on two different devices had such a huge difference. I had to do something about it.
Page speed and it’s recommendations
The Page speed report is a great starting point to work on the improvements. It’s always a good idea to look for the line items which are easy to fix and give you a good increase in the percentage. And, you know what I could see was one of the items in red was a JavaScript file size issue. It was a shocker for me as my blog has hardly any JavaScript behaviour. The only thing I recently added was the scroll indicator.
Digging a little deeper I understood the blunder that I had made. For getting the document ready event, I used the jQuery document ready event. And, that meant I was loading the entire jQuery library. And, that contributed to the huge file size. So, this was the first item which I had to fix. Upon Googling around, I could find a small NPM package “document ready” which would give me the same event. As I was very particular about the file size, I even went into the source code of the plugin and saw it will add a few lines of code only. This is why I decided to use it instead of writing my own.
After making this change, the app.js file size reduced from around 251 KB to less than 2 KB. And, this is why I said that I made a silly mistake. But anyways, the learning is that it’s very important to have a strong checklist while deploying your code to production.
Reducing first byte time using Redis Cache
After the file size improvement, I was looking for some way to reduce the first byte time. This is one of the most important aspects in reducing the waiting time for the user. This hardly took me an hour to implement across all the pages on my blog. But, it gave me a much better score on Page Speed and Web page test.
Redis is an in memory cache. To explain in simple terms, you are storing information in RAM of your server as a cached object. And, because RAM is much faster than hard disk IO speed, your data retrieval time reduces by a huge margin . I have a 2 GB server and I configured Redis to take up to 200 MB of RAM. Now, I know my entire website data won’t even take 20 to 30 MB. I have around 80 articles and that amount of text doesn’t eat up too much space right.
And, the implementation of the caching on Laravel is just a piece of cake. Whatever is your query result should be cached. And, before fetching the data from the database you just need to confirm whether you have that data in your cache or not. This means, now on page loads I am not at all hitting the database. The data is being served from in-memory cache which is way faster than establishing a connection to the database, query and getting the results. Below is a screenshot of the code which I have on the home page to fetch posts.
And the difference between non cached page vs cached page can be seen in the screenshot below:
Conclusion
So, from these above screenshots you can see that having a strong checklist is important. Along with that you should have a good tool set which you can use to get useful insights. With a quick deployment process, it is very easy to miss out on these aspects. Hence, a checklist is a good way to ensure that we are not making any big mistakes with the new code update (for example my jQuery file size issue). If I had checked the file size after the code update, I would have caught this.
Let me know what you think about having a checklist? Do you already have one, if yes how do you use it? You can get in touch with me through Twitter @amitavroy7 .
Banner image from Unsplash
Top comments (0)