When building a website, measuring and improving site performance before go-live is usually fun. After the main bulk of development and testing has been signed off, I usually advise clients to set aside a period of time to ensure the site runs quickly. In the race to go live ASAP, some clients will push back. One client even asked, 'Can't you just make it fast as you write it`. Depending on the size and complexity of the site will determine how much time you need to set aside. On some projects, we have blocked out an entire month just to tweak performance.
Clients obviously do not like delays in launching. Some will want you to go live before you test for performance. This is usually a mistake. From my experience, more often than not, clients who force you to release early usually regret it. On projects that are rushed out the door, either the client or their customers will start complaining that the site is slow. This usually happens within the first week of launching. At this stage, the guy who pays the bills decides that performance is now important and something needs to be done ASAP to make it run fast again. You and your team are now under more pressure to fix something that is impacting the business, classic!
At this point, you'll be expected to be a performance guru as the project is live and needs fixing ASAP. You will likely not be given the time to research and test the site in a controlled and planned way. You need to fix the performance and you need to have fixed it yesterday. If your website's running slowly, or you find yourself in a similar situation, this guide is aimed towards you to help you get up and running quickly 💨💨💨.
Define Your Metrics First
When clients ask me to make their website faster, my first question is usually 'what are you trying to accomplish?' Usually, when people talk about performance you need to improve the time it takes to load a page on a normal day. In terms of page performance, how fast is fast enough?
The go-to guy in terms of usability is someone called Jacob Neilson. Jacobs research recommends having all pages load within 1 second or less to create a good user experience. If we use the 1-second rule as the target for all of our web pages this can save you from going too far down the performance rabbit-hole. You can spend a long time refactoring and tweaking code. When you hit this metric stop and move on. Agreeing on the performance metric with the business before you start improving page speed is really important, as it will define a clear time to stop.
Now we have a goal to aim for. The next thing that I recommend is identifying the bottlenecks/slow areas of the site. At the start of performance tweaking, there is usually a number of big quick wins that will give you the most bang for your buck. Let us cover these big bang techniques then 🔥🔥🔥!
How Can I Make My Webpages Run Faster?
When it comes to improving page speed you have two main options, caching and optimizing the performance of your code:
Caching: Caching is usually the best area for quick wins. Implementing a good caching strategy can dramatically improve page load times. As the global caching layer usually sits on top of the website code, implementing a basic cache is usually pretty quick. This is where you should start.
The theory of caching is easy. When a page is requested for the first time, the page HTML is generated on the server. Before it is returned to the client, the generated HTML is cached for a period. On subsequent calls the HTML is retrieved from the cache rather than being calculated from scratch all over again. Caching can usually be easily implemented on the majority of websites with little work. The types of websites where it won't work, are the sites that need to display real-time data, for example, pricing, graphs, stocks, or, news. When a pages HTML is cached, that is the version everyone will see regardless if the data is out-of-date. If you have real-time information, your best course of action is to consume that data via AJAX. In this architecture, the bits of your page that don't change get cached and the bits that use real-time data are hydrated using Javascript when the page is loaded in the client's browser.
Code Performance: This is the black sheep of the performance discussions. Code performance tweaking is the process of optimizing your code to work as quickly as possible. This is a difficult and time-consuming area to make improvements. To get good performance gains here, you need to identify the slowest areas of the site. This is done using profiling tools to identify the specific areas of code that are performing poorly. When a slow area is identified, the code is refactored and tweaked until it works within an agreed tolerance. This improvement process is usually very trial and error. Make a change, test. Rinse and repeat.
I've worked on high-traffic e-commerce websites where we've needed to do this. When the speed of the website affects sales, businesses are usually happy for a team to focus for months solely on performance. Investing a few months of development time to increase sales by 20% pays for itself. If you're not running an e-commerce site, however, companies are usually more sceptical about investing that amount of developer time. If your project falls into the second category, is it worth the pain of refactoring everything now?
Refactoring a large, old legacy codebase may take months. If you're thinking of upgrading your CMS system within the next year (say for .NET CORE) then you might want to hold off on the work. This is a similar approach a lot of companies made when faced with converting their current websites from a single template into a responsive website. Instead of picking through the mess of the current website and trying to force it to be responsive, they waited until they needed to upgrade their CMS. If you can get away with waiting until a new upgrade. It will definitely be easier to improve new code that has been written to a high standard compared to refactoring old code.
Capacity: Having your site work quickly on a normal day is important. Ensuring the site still works on a busy day is more so. If you've ever tried to buy tickets from Ticketmaster for a popular event, you will understand the dilemma. On a normal day, you may have to deal with 10 transactions a second, but on a certain day, you need to deal with hundreds of transactions for a short period of time. These days are usually the clients main money-making days, so not losing orders is important. The more people that use your website, the more the server has to do. At a certain point, your server will have to work so hard that your web pages will get sluggish and performance degrades throughout the day.
Solving capacity issues is usually fixed with hardware and hosting options. Cloud hosting, load balancers etc.. can be used to help improve your capacity. These types of issues are normally solved with a good IT infrastructure strategy and isn't a code fix. Getting this balance can also be complex.
Caching, code performance and capacity are your three main tools for improving site speed. When people ask you to make a website quicker, first you need to figure out the cause of the issue, is it the website can't operate on a sale day or is the issue occurring during normal traffic. For slow loading pages, as long as you're not dealing with real-time data there are usually a number of 'quick' wins that can be implemented before you need to start changing code. When you consider performance, code changes should be your last resort. From my experience, this is the area that takes the longest and provides the smallest benefit.
My advice when starting or planning a project is to build something first and then measure it to see where the bottlenecks are. Agreeing on how to write quick code can result in heated 'what if' debates around the team. These debates usually do not end productively. Only when you have something to test against and you can quantify things should you take performance seriously. If, like most people, you're starting with the 'quick wins', I would recommend enabling the output cache, using a CDN, minifying CSS and JS, HTML fragment caching, and finally using a NoSQL provider like Redis. Start here and you will be fine... hopefully 🤪.
Happy Coding 🤘
